Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain, my name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. Smart contract wallets are gaining traction amongst devs because they offer several advantages over traditional EOA accounts. ERC-4337, the Account Abstraction EIP, proposes a standard for creating smart contract accounts that can have interchangeable signers and authentication schemes, allow for gas to be paid by third parties, and creates a new mempool of transactions that can be bundled and put on-chain by motivated third parties. My guests today are Will Hennessey and Noam Hurwitz, who work on Alchemy's Account Abstraction team. In this episode, Will and Noam walk me through the ins and outs of account abstraction. We discuss the actors in the lifecycle of an AA transaction, how different signing schemes like MagicLink and on-chain R1 verification fit in, and how AA wallets will connect to dApps. We also dive into Alchemy's latest offering, AccountKit, which provides a suite of options for building smart contract accounts. It was fantastic getting to talk to Will and Noam, who are knowledgeable builders making quality implementations at a crucial software frontier. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice, or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research and making your own decisions. Hey, Will. How's it going?

Will Hennessy: Good. How are you, Nicholas?

Nicholas: It's awesome to finally be in touch. Thanks for coming on the show.

Will Hennessy: Oh, it's my pleasure. Thanks for inviting me.

Nicholas: Absolutely. Hey, Noam. How's it going?

Will Hennessy: Hey, hey.

Noam Hurwitz: Thanks for having us, Nicholas.

Nicholas: Absolutely. It's awesome to have you guys both here. I'm really excited to talk about what Alchemy's doing with AA stuff. So the plan for today, I think, is that I'd like to start off with a little bit about your backgrounds, how we got here, then we can jump into AA architecture, what is account abstraction, what's important to know about it,

Noam Hurwitz: and then

Nicholas: we can round it out with what Alchemy is doing to make that easier for devs to integrate. Maybe Will, do you want to start off? How did you get here? How did you end up working on the AA stuff at Alchemy?

Noam Hurwitz: Yeah.

Will Hennessy: So I work at Alchemy on our account abstraction products, along with Noam. I got here by joining Crypto about three years ago. At the time, I was working at Google, and DeFi Summer was taking off, so I started building a project with Gnosis Multisigs for payroll for DAOs. And in a way, that was sort of the earliest form of account abstraction, because Gnosis is safe for smart contract accounts, and so they let you abstract away many of the parts of a wallet, like seed phrases and even gas, by relaying transactions. So I built that product on the side with my roommate, and then I ended up joining the Uniswap Labs team, where we built out the Uniswap wallet, we explored smart contract wallet solutions, ended up shipping an amazing EOA wallet, but that ultimately wasn't leveraging account abstraction yet. And so earlier this year, I joined the Alchemy team to work on what I think are some of the most important core problems in the wallet space, going deep down the stack to build ERC-4337 infrastructure that can really start to abstract away all of the speed bumps that are tripping up users as they try to onboard into Web3 through wallets. And so that's how I got here and I'm excited to tell you more today about how we're doing that with our 4337 infrastructure and smart contract accounts.

Nicholas: And Noam, you want to go next?

Will Hennessy: Yeah.

Noam Hurwitz: A lot of similarities with Will's journey, I actually joined also in around DeFi summer, early 2021 is when I joined Alchemy. Before that, I was also doing the big tech circuit at Google and then tried to start up a thing called Quibi, if you guys have heard about it. But I started playing around with DeFi that summer and got really intrigued by the possibilities that it enables and got introed, at the time Alchemy was a little bit smaller, got introed to Jonah Keel and was working at Alchemy about two weeks later. So it was a very quick fall down the rabbit hole. And while at Alchemy, we've been paying attention to a lot of trends. And one thing that we had increasingly high conviction on is that smart contract accounts are going to be required to get a billion people on chain. EOAs simply don't pass what we call a mom test. And so we've been kind of keeping tabs on what's going on in smart contract accounts and account abstraction over the years. And a few inflection points made us pay more attention to it earnestly. And those were one, ERC 4337. So a lot of work done by the Ethereum Foundation and the folks behind that ERC in order to standardize infrastructure to support account abstraction. And two, is the rising usage of layer twos versus layer ones, where it's becoming more economically feasible to have these more gas intensive operations on chain. So the combination of those two made us take a serious look at the space. And then we started building out this team late Q4, early Q1 of this year.

Nicholas: I have to ask about Quibi. That's the short form video.

Noam Hurwitz: Yeah, exactly.

Nicholas: Awesome. I remember. I remember. In a way, correct. But not exactly right timing or something. But interesting background.

Noam Hurwitz: You can't buy a product market fit is the big takeaway on that one.

Nicholas: Okay. A good lesson for everybody. I'm sure. You have this great explain like I'm five thread explaining AA wallets. And I thought first we could just jump into what is like the AA architecture. So maybe, do you want to give like a, I figured we could go through like what is the AA architecture? Like what are user operations, bundlers, entry points, et cetera. But maybe first, do you want to give like a high level? What is account abstraction all about?

Will Hennessy: Yeah, I can start there. I'd be happy to give sort of the user facing explanation about like why this matters and what problems we're solving. And then I can hand off to Noam for a more technical walkthrough on how it all works. Perfect. I mean, I think the reason that we're building account abstraction at Alchemy in the first place is because it's too hard for people to get into Web3. We've talked about this time and time again, but wallets are complicated. Seed phrases are very confusing and intimidating for people. And even if you find a really cool app that you want to try, so many people hit this wall of gas, right? They're so excited to try an app to mint an NFT and it says, "Oh, you need 0.013 Ether in order to take this action.". And so, you know, our thesis is if we want Web3 to really go mainstream, we need to make all of those parts of the wallet stack and the user experience invisible. And that's really what account abstraction promises to do. Account abstraction is a very technical term, but what it really means is abstracting away all of those pain points that Wallet UX brings today. And it has a long history from Vitalik and the Ethereum Foundation of like trying to bake account abstraction into the Ethereum blockchain and the other EBM chains to solve some of these problems. And it does. 4337 is the latest version of this. It's a consensus standard that the community has aligned on to implement account abstraction wallets. It basically lets a new user on board. You can sign up with a social login. You can use any kind of wallet service that you'd like today, like Privy or Magic Link or Turnkey to create an account with just an email, with just a password or with a passkey or even with a self-custodial wallet, if you want to have self-custody. And then you can submit transactions or we call them user operations, as you mentioned Nicholas, and submit those to a Bundler where the Bundler is able to batch together transactions for the user, sponsor gas so that the user doesn't have to pay gas and you can let them get started using the app without jumping through all the hoops of a fiat on-ramp or KYC. And so we're starting to see already a few apps start to use account abstraction, like CyberConnect or Beam, the payments app, to build some really amazing user onboarding experiences that you can hardly even tell are Web3 because they've hidden layers and made it super simple.

Nicholas: Awesome. That's a great overview. So basically simplifying onboarding, simplifying key management with different kinds of authentication that are more like web-to-native, familiar to kind of regular folks new to crypto, and overall just like smoothing the whole experience by making things like gas and all the other aspects of participating on-chain easier for users. So maybe, Noam, do you want to run through, I guess we could start off, you tell me if this makes sense, but what's a user operation? Maybe that's the best starting point.

Noam Hurwitz: Yeah, maybe even a higher level starting point before I dive into that is the term itself, account abstraction. Yeah. I think it causes a lot of confusion. I think one thing we're great at in Web3 is naming things. We are on a great track record of having really intuitive, ergonomic names that everyone quickly and easily understands what's going on, and I say that slightly conceitously. But account abstraction actually refers to the protocol level, like interpretation of an account, and that I think most people are familiar with this, but the way that you use the Ethereum blockchain and other Ethereum blockchain today is through an account like MetaMask. Today, when you use MetaMask, it's called an externally owned account, meaning it's a private key. That private key effectively is your account. When you sign transactions, there are some validations done to make sure that, hey, the signature is from your key and that the NOPS is correct and you have enough balance in your account to pay for gas and whatever else. And that's the only kind of account that Ethereum natively supports. And ERC-4237 leverages off-chain infrastructure to support a second kind of account called a smart contract account. And for the whole list that we'll just enumerate it, there's a bunch of reasons why we want smart contract accounts, but Ethereum doesn't natively support them. And so account abstraction actually abstracts away from Ethereum's perspective the ability to support this second account from a protocol perspective, so that from the virtual machine's perspective, an account is an account. And the underlying technological wiring of how transactions are processed are abstracted away from the protocol. So it's a bit of an arcane name. I think it's not become super intuitive. We've been kind of just leaning into smart accounts or smart contract accounts when we're discussing it because high-level account abstraction enables smart contract accounts on Ethereum.

Nicholas: So the source of the word abstraction in the name then is that it's abstract from the kind of traditional EOA signing architecture. That's what makes it abstract.

Noam Hurwitz: The concept of the account is abstracted away from the protocol itself so that it can support not just EOAs, but also contract accounts.

Nicholas: So traditionally, like EOA equals account. And now we have like a notion of an account that is not directly tied to the EOA.

Noam Hurwitz: Exactly.

Nicholas: Makes sense. And it is kind of confusing. I definitely see people saying more like smart accounts, or I see in the Alchemy docs like accounts or account contracts, or smart contract wallets, or smart wallets, lots of different terms. One reason that I keep sticking with AA or specifically mentioning 4337 is because I feel like, you know, smart wallet can almost mean anything. It's like a little bit vague, even though I think it is probably the right term for most people. And AA is pretty specific about what we're actually talking about.

Noam Hurwitz: Yeah, I agree with that. I think if over a broad enough timeframe, all accounts become contract accounts, and then it becomes a little bit more intuitive that, hey, honestly, like, I think. back to Will's point, the idea here is to make crypto much more accessible and ergonomic for the everyday user. And so the more that we can load shed terms like AA or smart contract, I think the easier that onboarding becomes. So at the end of the day, the idea here is this is their just digital account or their like internet native identity. And there's probably better terms to define what that intent is. But we're moving away from, hey, there's a smart contract or, hey, we're on the EVM or hey, this is the kind of tracking to try to make this more acceptable for the masses.

Nicholas: Right. And I think we'll get to this in a little bit. But, you know, I think with some of these application specific embedded wallets examples that we're seeing like Frentech and others, not Frentech, not AA yet, but in any case, these kind of embedded experiences, you know, you don't think about your Facebook account as whatever, some kind of security or infrastructure or technology. You just think about it as your Facebook account. So I suspect we're probably going to be moving long term towards people not worrying so much about what this like wallet paradigm is, and instead sort of just concerned with what the applications are that they're interested in interacting with. So, OK, so what is a user operation? Is that is that a good starting point here?

Noam Hurwitz: Yeah, let's do it. So a user operation, simply put, is a meta transaction object. So it's effectively can be a bit like an Ethereum transaction with a few other fields to support the smart password account. And the big one to call out for the course of this conversation is a field called Paymaster and Data, which is the means ERC-4327 uses to extract away gas from the end user experience. And so users sign and send user operations instead of raw transactions. They send them to an entity called a bundler, and a bundler can bundle several user operations and post a single raw transaction to the underlying network, whether that's Ethereum or Arbitrum or Optimism. So it's like a meta transaction made in a bundler, and the bundler then converts them back into these core Ethereum transaction objects.

Nicholas: Can we think of user operations like a sort of intent or off-chain order book, like for anyone who's done a trade on 0x or made a listing on OpenSea? Are user operations kind of similar to that?

Noam Hurwitz: Yeah, I think we're starting to encroach on intent centric architectures as we're using the terminology. I think there's some interesting places we can take that conversation, especially around ERC-6900, if you've heard of that. But at a high level, you can think of the user op as an intent and the higher level abstraction it's providing versus transaction is that the user is trusting an entity called a paymaster within confines of what the user enables the paymaster to do, which in this case is either sponsor gas or let them pay for gas with other tokens. And that entirely abstracts away the concept of gas from the user experience.

Nicholas: So the user operation defines what I want to do, and it's separate from how I'm going to be paying for gas, or it actually maybe includes how I anticipate paying for gas if I'm going to do so with my own ERC-20s.

Noam Hurwitz: So, yeah, the user operation contains a field called paymaster and data, which specifies the address on chain of a paymaster entity that should be used in processing the user operation. The paymaster entity can implement its own arbitrary rules. So there are things like sponsoring paymasters, where if called and verified, we'll pay gas for the user operation instead of the funds coming from the user's wallet. Alternatively, there are like token paymasters, which enables the user to pay for gas with things like stablecoins with the paymaster acting as the intermediary. So accepting the stablecoins and then paying for gas with the native token like ETH.

Nicholas: OK, so I could have a wallet that only has, let's say, USDC or DAI in it, and I could pay gas with that thanks to the paymaster who will do like a swap for ETH to pay the gas and take a little fee at the same time. Or I could say incentivize or I should say subsidize user interactions. in my dApp, let's say, if I want people to be able to mint something for free, I could just have a paymaster. that as long as they're minting against the right contract and they belong to some list of people, an allow list, for example, then I'm just going to cover their gas. Those are two ways I could use paymasters.

Noam Hurwitz: Yes, exactly.

Nicholas: OK, and you mentioned it in the course of talking about that bundler. So what is a bundler?

Noam Hurwitz: So circling back to the previous point, every transaction on Ethereum today has to be initiated by what's called an EOA. That's the only account type that Ethereum natively recognizes. And so a bundler is a piece of infrastructure that, along with a lot of other complex logic, accepts user operations, converts them into transactions, and then uses its own EOA to send those transactions to your smart contract account on Ethereum. So effectively, it's this middleman that uses its account to initiate your transactions on your behalf so that you don't need to have an EOA at all. You can just have your smart contract account.

Nicholas: So is this kind of what some of the documentation talks about, like replicating the functionality of the transaction mempool in a higher level system? Is that what the bundler's role is?

Will Hennessy: Yeah, that's exactly right. You know, they're going to be a network of bundlers. Today, there are a couple of companies that run centralized bundlers, and we're starting to work together on a peer-to-peer mempool spec. So in the future, the steady state that's envisioned by EOC 4337 design is a peer-to-peer network of bundlers that talk to each other and gossip user ops across the network to form what is effectively, yes, a meta mempool on top of the base chain mempool.

Nicholas: So we're talking about mempools. I have to ask, are there MEV implications here, or do we need to think about censorship? How do we think about having an entirely separate mempool?

Will Hennessy: It's a great question, because especially in 4337, there may even be more than one mempool. And the answer is yes, we've already seen MEV occur on one, two, three, four, six, polygon, multiple instances of it happening already. And you're right. And there are even a few new forms of MEV in the bundler, because traditionally, when you're a block builder and you mine transactions on chain, that block builder could execute MEV by ordering the transactions, right? But now in a bundle, there's actually two dimensions to this, where there's first, what is the order of the user ops inside of the bundle? And then there's the second question of in what order do the bundles land? And so for MEV searchers and extractives, there is a.

Nicholas: So is a single bundle only the user ops from a specific smart wallet, or does a bundle include user ops across multiple wallets or multiple accounts, I should say? So a bundler is then like maybe could you explain a little bit a glimpse of how a bundler works when it's looking at this mempool?

Noam Hurwitz: Yeah, it's effectively you can think of it as like an aggregator, so it doesn't need to bundle anything. Historically, these have been called just metatransaction relays, where I, the user, send it my metatransaction, it processes my metatransaction using its EOA and sends it to my smart contract account on chain. Because it's able to do this for many individual wallets in parallel, there is just an efficiency mechanism implemented to bundle many of these metatransactions into a single Ethereum raw transaction that's in on chain. And that is primarily just for efficiency. So there's some gas savings on bundles.

Nicholas: So you're just saving on the initial 21k gas or something on the transaction?

Noam Hurwitz: Yeah, like if you're. there's just various warm up costs and like transaction overheads of posting multiple individual transactions, and you can reduce that overhead by aggregating them into bundles and posting them on chain.

Nicholas: And bundlers get compensated for doing this activity?

Noam Hurwitz: Exactly. So there is a priority fee concept for the bundler as well. So a priority fee is kind of the amount you tip the validator or sequencer or now bundler in like a 1559 mechanism, which is the EIP for fee markets on Ethereum. And effectively, the bundler takes the user operation at a certain priority fee, posts the transaction at a slightly different priority fee, and is rewarded for doing its work by taking the spread of those two fee prices.

Nicholas: Got it. So as a user, I have some desire, some intent, I sign with maybe a modular authentication scheme, maybe it's a passkey, maybe it's an EOA, maybe something else. Then my user op is propagated to this bundler mempool where there are multiple actors playing and ideally not censoring my transactions, not doing anything too nefarious MEV wise to my disadvantage. Then they're going to verify that my user op makes sense, that it's a valid transaction. Maybe they're going to, in the process of executing it against my smart account, the smart account is going to call out to a paymaster that's going to pay for the gas. Or how does that relationship between bundlers and paymasters work?

Will Hennessy: Yeah, there's actually one more component in there we haven't talked about yet, and that's called the entry point contract. And so when the bundler submits a bundle on chain, it's actually not sending it directly to your smart account address because, as you said, Nicholas, it contains a bundle of multiple user ops from different smart contract accounts. And so the bundler actually submits the bundle to the entry point contract. And the entry point is a canonical smart contract account written by the Ethereum Foundation with the intention of being the one sole account entry point on a given blockchain. And so there may be more, but you can generally think about it as having one entry point on, say, Ethereum and all bundlers will submit all their user ops to that entry point contract. And now the entry point has a very special job to play, where it will take that bundle that the bundler has sent and the entry point will go and validate each user op in that bundle to make sure that it's a valid bundle. And it'll run through, say, all 10 user ops and call out to the smart contract account that it's intending to invoke and call a validate function to ensure that that user op is valid and will execute. And if it's not valid, it'll throw out that that user op and continue on with the others. And then when they're all valid, it will start to execute. And at that point, it will call out to each smart contract account to execute each of the user operations.

Nicholas: So the entry point is defined in the 4337 spec?

Will Hennessy: Yeah, that's right. And it was then implemented by the Ethereum Foundation and some other community contributors.

Nicholas: And so it's able to act as a kind of maybe registry is the wrong word, but it can essentially point the bundlers transaction against the entry point can be. the entry point will direct it to the appropriate smart account, regardless of the implementation.

Noam Hurwitz: Yeah, that's right. So, yeah, the smart account address is actually specified in the user operation. Everything well said, yeah, the entry point does a lot of validation. The core responsibility of the entry point, though, is, again, circling back to what we said earlier, Ethereum only supports EOAs. We're using the bundler and it's using its EOA to send transactions on your behalf because the person using the EOA pays for gas in this mechanism. The bundler ends up paying gas fees for every user operation submitted to it. And so the core responsibility of the entry point is actually to reimburse the bundler back for gas fees used in execution. So it'll do a bunch of validation on the user operation, make sure that there's sufficient balances in executing the user operation, whether from the user's account or from the paymaster, and then reimburse back the bundler the fees it was used that it used to execute the transaction on chain.

Nicholas: So is the bundler checking that it's going to be reimbursed in transaction time or even before sending the user up to the entry point?

Noam Hurwitz: It'll check that before. So there's a lot of very strict validation rules defined in 457, all designed to protect the bundler from incidents where it would be paying for gas and not get reimbursed. So those can include things like there's not sufficient balance in the account, but it could also include situations where a transaction may revert on chain. And because it reverts on chain, the entry point callback to reimburse the bundler never materializes. And so the bundler is left high and dry with the funds it used to pay for that on-chain reversion. So everything, there's a lot of pretty restrictive, one might say, validation rules defined in 457, and they're all designed with that intent of how to protect the bundler.

Nicholas: So this is a pretty complicated system. we've got going here. We touched on paymasters and maybe we've covered it sufficiently. I don't know if there's anything you wanted to add on paymasters. Before we move on, if not, I also was seeing aggregators. Do those fit into this mix somewhere?

Noam Hurwitz: Yeah, I can take this one. So our readers here refer to signature aggregators. And as far as I know, there aren't actually any live in production. But the idea here is you can actually get further kinds of scale by aggregating signatures with things like DLS signature schemes, where this is going to be a little bit technical. So bear with me. Today on Ethereum, transactions are signed using an elliptic curve called ICCP-236-K1. This is the same curve used in Bitcoin. And all transactions are signed with a signature using that scheme. Account abstraction enables signing with other signature schemes. So we talked about passkeys before. And passkeys, the way they work is they store the private key on the hardware of your device. That hardware doesn't actually support this K1 curve. And so using smart contract accounts, we can overwrite validation to process what's called ICCP-236-R1 curve, which is hardware supported and can store passkeys. So we're using a different cryptographic scheme for passkeys than we are for normal EOAs. Another cryptographic scheme is called a BLS signature. And for BLS, an interesting component of it is you can aggregate multiple signatures. So if we take 15 signatures from different users, we can aggregate those into a single signature on-chain. And the advantage of doing that is you get data-ability savings. So you're actually posting much less data on-chain if you're able to aggregate 15 to 100 to 200 signatures to a single signature. And that can therefore downstream materialize in savings for every user because you're paying less for each operation. So signature aggregation is, again, like an economies-of-scale mechanism to push down the cost of user operations.

Nicholas: So in BLS, you're essentially doing like off-chain aggregation, but that can be validated on-chain in a single or at least less operations than if you were to validate each signature separately. Very cool. Would that be considered MPC or is it something else?

Noam Hurwitz: That is not considered MPC. That would be something else. So it is a good question, though. I think it's a common point of confusion of where in the stack AA sits. And to me, like in the signer stack, there are three core components. There's the contract account and that's programmable access rules, programmable execution rules, programmable recovery rules. Like you can define what it is the account should be doing. Then there's this cryptographic scheme and that's what we just talked about. So you can use the K1 curve, you can use the R1 curve, you can use BLS signature aggregation. If and when you need to, you can use things like post-quantum secure signing schemes. And then there's the actual signer itself. And the signer is just a private key on the scheme defined like K1 or R1, etc. And that key needs to live somewhere. And so when people talk about MPC, they're usually talking about the construction of that private key used to sign either transactions or user operations on these blockchains.

Nicholas: Got it. So we kind of talked about it a little bit in passing here, but there is also this modular authentication piece. Maybe you could explain how that works under 4337.

Noam Hurwitz: Yeah, happy to. So again, like high level transactions on here today are dotted with a handful of hard-coded rules. And that is, again, signature on the K1 curve, nonce check, balance check. And that's about it. With contract accounts, you can validate these in any which way you want. So you can use whatever cryptographic scheme you want. You can enforce invariance like, hey, this is below my spending limits or this only interacts with assets that this signer has permission for or whatever else you can think of. You can kind of program on chain. And so that's a core component of smart contract accounts in general is that validation is entirely programmable and you can update it across any number of keys to create the model that works best for your account. Part of this actually gets extended in ERC 6900, which is an ERC that we've been working on for a couple of quarters. And recently, the Ethereum Foundation actually also joined on as co-authors to define extensible interfaces for smart contract account for components we call plugins. And plugins can contain like validation plugins. They can contain execution plugins and they can also contain what we call hooks, which are logical statements that fire before and after execution of a transaction.

Nicholas: That sounds very powerful, maybe a little bit dangerous if not dealt with carefully. But that sounds like adding a lot of functionality to what maybe people who are familiar with an EOA might think of as a like a wallet.

Will Hennessy: Totally. One like really powerful example we're excited about in smart contract accounts and plugins is our pull payments. With an EOA, you always need the EOA account to assign a transaction and initiate it on chain in order to push money out of the account to a recipient. But with an execution plugin, like Noam mentioned, you could actually allow for pull payments to allow, say, Netflix to withdraw $16 from my wallet exactly once a month.

Nicholas: And that would be not by adding Netflix as a signer on my smart wallet, but instead adding a plugin that allows them to take some limited quantity of token from my account.

Will Hennessy: It's a good question, actually. Noam, I'd love your thoughts on that. And one way to do it would be to create what would be a signer, maybe called an app key, that gives Netflix permission to initiate that transaction on their side.

Noam Hurwitz: Yeah, I think we're kind of circling back to intent-centric architectures again, where exactly you would give Netflix a key to your account, but that key only really has permission to move $16 once per month. Anything else it tries, the transaction will revert. So you're guaranteed that even if someone steals your Netflix key or Netflix decides to go rogue, the most they can take from you is $16 in a month. And you can extrapolate this to more powerful models. So it might be interesting to try to define intents later. But one example of an intent architecture here is you have a key that only has permissions to do active management on your Uniswap v3 position. And so you can give this key to an external entity, and they're responsible for managing your Uniswap v3 position according to the rules programmed to this key. And they're not allowed to go sell your NFTs or transfer your USDC. And maybe the worst thing they can do is withdraw all your money from the decision into your account, but it's still in your account. And in exchange for doing this, they get compensated 2% of profits over a period of time. And so now you can give someone a key, they can actively do work for you on your behalf on your account in a trustless way that you've agreed to, and they can get rewarded for doing that work. And so you're outsourcing execution of a relatively complex topic by constraining the system and having another actor, often called a searcher, solve the problem for you instead.

Nicholas: Very interesting. So basically mobilizing MEV and other kinds of incentives for other people to pay the gas to execute transactions on your behalf with like limited permission signers for specific applications.

Noam Hurwitz: Yeah, exactly. Turns out it's always MEV all the way down.

Nicholas: You mentioned a little bit the R1 curve, and we talked about that. If people are interested, there's a bunch of prior episodes talking about passkeys of this show that you can check out, particularly the EIP 7212 show might be interesting, or the interview with Jose Aguinaga about passkeys. So the R1 curve, so passkeys are this FIDO2 standard, replacing usernames and passwords with private keys that are generated on devices that live inside the secure enclave on devices that have such things and that are authenticated and got access to via biometrics on devices that have such things. But they are signing using this other elliptic curve, the R1 curve, versus the K1 that's native to Bitcoin and Ethereum. A lot of solutions in the sort of smart wallet stack are taking the approach of using either, well, I've seen a few different options. That EIP 7212 is a precompiled version of essentially a contract that Ledger wrote and that already is out there in the wild that will cost 70,000 gas to verify an R1 signature on chain in the space of a transaction. There's this 7212 proposal to do essentially the same thing, but reduce the gas cost to 3,450 gas, which is approximately the same as EC Recover, the K1 verification. There's also a lot of people who are using MPC, things like Lit Protocol or Turnkey or other solutions to essentially do a distributed key generation in between the passkey signing and the AA wallet. What that distributed key generation lets you do is create a kind of synthetic EOA where the private key ideally lives in memory on no computer in the network, but you're nevertheless able to sign with a regular K1 EOA, which the AA wallet can can verify easily with this typical EC Recover. I'm curious, do you guys have thoughts on MPC or what the right solution is for getting these R1 passkey signatures on chain?

Will Hennessy: Yeah, we absolutely have thoughts because as we've been bringing a smart contract account to market, we've been talking with a lot of these teams about how to design and integrate a really seamless onboarding experience for users. And as you mentioned here, Nicholas, the tradeoff space is really wide and deep and interesting. I like to think about the goal here as trying to design an ergonomic version of self-custody, right? I think a lot of people appreciate Web3 because it's self-custodial and you don't have to trust intermediaries to custody your keys. But the problem is that's very in ergonomic today, right? You need a seed phrase, you need a private key. And that's the magic with passkeys. It actually creates a much more ergonomic way to have self-custody. And you can kind of see that a bunch of different implementations of this spanning the spectrum or perhaps evolving towards an end state, starting with maybe the more hosted type of providers like MagicLink and Turnkey, for example, store the key material in a very secure server. And then they authenticate users into that server using the WebAuthn protocol to validate a passkey and authenticate access into the private key store in the server and use that to sign the signature off-chain and then use infrastructure like a bundler, for example, to submit that signed transaction or user op on-chain. And so that's sort of the first category of, I'd say, like off-chain passkey validation and signing. And the second, and that, by the way, doesn't use the new, I mix up my curves, but that doesn't use the passkey curve. that uses just the native EOA curve because at the end of the day, it's signed with just a traditional EOA private key. The next step forward from that, I think, is the decentralized networks, like you mentioned, like Lit Protocol is doing some really great work here, which improves upon that server-side key storage design by decentralizing the job of storing keys and validating users. And so there, Lit Protocol is building out a network of, I believe it's over 30 nodes at this time, that are operating and storing a shard of the key so that no node ever has a single piece of the key. And again, that's a traditional EOA signing key. And it has been split up into a bunch of different pieces using a distributed key generation algorithm. So that's decentralized NPC network.

Nicholas: And I believe you need two thirds of the nodes to agree and be online.

Will Hennessy: Yeah, that's exactly right. And that's trying to balance security considerations with liveness assumptions, because if you needed 100% of nodes and then a single node goes down or turns off the light switch, you'd be in big trouble. So two thirds was the split that they landed on it for consensus. And so where do PASKs come into play with Lit Protocol? Because Lit actually supports all manner of validation. You can use Google Auth, you can use social logins and different types. And they support programmable, they call them actions, sorry I'm forgetting the name, but you can basically program. Yeah, thank you. And you can program different authentication methods using either PASK or social login or OAuth. And so, again, with Lit Protocol, this is going to be using WebAuthn to authenticate with a PASK in order to initiate a signature. That's, again, not on-chain PASK validation. It's still off-chain. And so the holy grail is, like you talked about, getting to on-chain PASK validation where we can use the, I'm going to need Noam to remind me, the R1 of the K1 curve to actually sign a transaction with a PASK and then validate that signature on-chain.

Nicholas: So I guess the advantage of Lit is that you get this really clean, gas-efficient solution. The disadvantage is that you're introducing a new dependency, this other network that is not a blockchain network. It's an NPC network with separate software and other constraints that you're introducing into your system. But you get access right away today to any type of authentication and regular old K1 EOA signing for your AA wallet.

Will Hennessy: Yeah, exactly.

Nicholas: So there's a couple of things to dig into here. Do you think, well, actually, how does the Web2, I know people talk about how AA wallets, you could even use something like a magic link or like, which is to say a really traditional Web2 authentication. You don't even need something as sophisticated or novel as PASK keys in order to sign directly on an AA, to directly sign a user op with a signer on an AA wallet. So how does that work? How would someone sign directly without using NPC with something like magic link?

Noam Hurwitz: Yeah, great question. Again, so there's the concept of the account, and that really is an on-chain smart contract with a bunch of rules programmed around what keys have permission to send transactions to the account and what permissions do they have. And then there's actual keys themselves and those have to live somewhere. And you could have an account that has like one key for one thing that's PASK key, one thing for another thing that's a magic link and a third key for whatever else in Metamask, for example. That's a totally viable combination, but there is no real coupling between what's defined in the account and where that key can live, regardless of magic or PASK key or something like fully custodial if you do need that.

Nicholas: So if I were to use a magic link, then when I, you know, beat the challenge in my email inbox, then essentially magic is the one who holds a PK that they're then going to grant access to for signing?

Noam Hurwitz: Exactly. And so I think the high level takeaway in all of this is identifying which points of trust you're placing in the system at what times. And so in the example of NPC or a scheme like magic link, you're placing different points of trust versus something like a PASK key where the entire cryptographic scheme is controlled, owned and operated by you on your device.

Nicholas: Right. To me, it seems like for true self custody, I really want to be able to sign transactions offline. I don't really want to have connection to anything, an RPC or some intermediary network, even though it may be useful in some setups.

Noam Hurwitz: Yeah, I totally agree with that. I think there's even like deeper points of trust than just liveness at times on some of these setups. So it's good to be aware of that. We do think the probable long term endgame here is going to use device hardware to manage private keys. It's entirely unfishable. But the issue there is recovery. So if you only have one PASK key and you lose your phone, then you lose access to your account. And so how you set up enough redundancy across all of your devices and all your various signers so that there is no one single point of failure.

Nicholas: So you're looking for solutions beyond iCloud Keychain, which, in my opinion, is sort of best in class for, I think DWR was saying it the other day, you know, 99.9% of users. Maybe it's a little high, but for most users, it feels like iCloud Keychain is the most well thought out PASK key management solution. But you're looking for solutions that are more cross platform and even redundant beyond that.

Noam Hurwitz: So this is a bit technical also, but the way the iCloud Keychain works is not by copying PASK keys. Again, once you have a PASK key on a hardware module, it's unfishable, unremovable from that hardware module. So you can't actually copy PASK keys between devices. The way this works for the iCloud Keychain is it'll register a new key on a new device and also update the server to accept that new key is valid using a handshake with the old key. So you're essentially like signing with an old key to add a new key on another device. The way that manifests on something like Ethereum is you actually have to update the smart contract account to also be aware of this new key. So you can use Keychain, but it needs to be coupled with some combination of a transaction to update the program rules for your account to be aware of and validate signatures from this new key. Or you need a scheme to otherwise replicate keys across various devices.

Nicholas: Now we get to this sort of spicy part that Jose and I were talking about, which is you have this real problem where if you want to change, for example, like add a signer, you want to add, I don't know, let's say you started on an iPhone and then want to add an Android device. So you need a new PASK key that's going to live in the secure enclave equivalent on your Android device. You now need to update the state of your smart account. But if you update the state only on a single chain, the sort of multi-chain reality, what did I hear? There's like a thousand EVM chains right now. You don't get that state change, permission state change propagated to all of the chains. Have you guys thought about that at all?

Noam Hurwitz: Yes, definitely an issue. I think the average user probably uses far less than a thousand chains. There's probably a power law in this region, I hope. We'll see. There is a proliferation of app chains and we'll see how that winds up. I think Vitalik actually wrote a pretty interesting piece here around what he calls a keystore chain, which is an L2 that authoritatively manages all of your account's configurations and we think can also be extended to authoritatively manage things like ERC-6900 plugin manifests over time. And then all other networks sync state from that chain to understand what the configuration for an account is. So you define your keys and permissions once and then every other chain reads from that authoritative data source.

Nicholas: I recall him proposing something about L1 being that place, but it seems not really realistic. Is that his proposal or an app-specific chain?

Noam Hurwitz: His more recent proposal is an app-specific ZK rollup. The ZK component is required for finality, although there are some levers you can tweak around. Optimistic rollups that provide tighter finality bounds too. But there is a lot of, I forget what the moon math I believe is the common term, around. supporting these state syncs across L2 to L1 back to L2 is the trustless way to do it. And so, yeah, we're quite far away from having a working solution on that front. You could also have something on L1. It actually does simplify the trust assumptions for L2s, but the tradeoff being it's more expensive.

Nicholas: Will, you mentioned that you think the like the long term goal is to do something like 7212. First off, do you think 7212 is viable? Do you think it'll get finalized?

Will Hennessy: Yeah, I think so. I think it's a good approach just to reduce gas costs on these L2s in particular for the signatures. and then longer term, I'd like to see that come to layer one as well. It's just would be such a big unlock for users. But I love Gnome's take on that EIP in particular. What do you think, Gnome?

Noam Hurwitz: It's a great question. I think it's hard to say how things are going to go now. I am a strong advocate of L2s taking the freedom to experiment with EIPs before L1 does. And I know a lot of them have been focused on staying easy and equivalent. But as these things develop, there's more and more of a need for testing out some of these EIPs and iterating on them before we try them in L1 consensus. Metallic actually very timely had a new post on enshrinement in L1 this week as well. that I think is excellent. But the way I see this playing out is L2s will start adopting things like the R1 precompile and then potentially even bigger things like data to kind of extraction. And over time, we can iterate on these models, find something that works well, and then decide to pull that back down into L1 Ethereum.

Nicholas: What is the difference really if AA were to be enshrined rather than an ERC? What would it change?

Noam Hurwitz: Yeah, it's a good question. So there are some networks that have native account tracking today, notably StarkNet and zk-sync. And what that means is that that core requirement that all transactions have to initiate from an EOA is not true on those networks. All users by default have a smart contract account. And this bundler entity is effectively built into the execution layer node so that you can just send "user operations" to your account without relying on an off-chain piece of infrastructure like a bundler. It's all natively part of the network and node clients.

Nicholas: So does that just reduce gas or it just changes? sort of what your assumptions are when writing contracts against the network?

Noam Hurwitz: Yeah, both. So it does have the gas reduction overhead. I think the other piece that we talked about is, like I said earlier, 1437 has a lot of restrictions in place to protect the bundler. In large part, this is because the bundler cannot guarantee that transactions it sends on-chain will not revert on-chain because it is not the block builder entity. And so what you get with native account abstraction is that the block builder and the bundler actually merge roles. And the bundler, now block builder, can definitively see, "Hey, if I process this block, this transaction will revert on-chain. Let's not include this transaction.". And so the amount of restrictions on what you can do on account-abstracted meta-transactions get decreased.

Nicholas: OK, so that would be something like base sequencer, just like rejecting transactions that will revert rather than including them and letting them revert in-chain.

Noam Hurwitz: Yeah. And this is a lot of what people use Flashbots for today. Ethereum is for making sure that transactions don't revert on-chain.

Nicholas: I'm a little slightly off topic, but I'm a little confused about what the situation is with things like Flashbots on L2s or sequencer censorship. I guess it sort of depends on which chain. But I don't know if you have any comments on that while we're here.

Noam Hurwitz: It's a deep dive, old man. Yeah, it is a good question. So there is no mempool on L2. An interesting takeaway from 4z7 is that this is going to be the first introduction of a mempool to L2, which will have some interesting side effects. The sequencer right now effectively processes all transactions. Most networks have this backdoor that lets you post your transactions straight to the L1 smart contract and have it be included after a 24-hour delay. But no one really knows how to use that. There's effectively a live miss issue if the sequencer goes down. That does pose a persistent issue. A lot of open questions on how that evolves over time. But right now, NED, because of that, is also, I would say, less of a problem on L2 than L1 because there's no P2P mempool and they generally enforce some sort of "fair ordering" at the sequencer level to avoid any of these stealth shenanigans that we see on L1.

Nicholas: Yes, I've heard people say that the centralized sequencing doesn't matter as much because of the trapdoor on L1. But that argument seems to depend upon the amount, sort of the cost of the unfair ordering on L2 being higher than the cost of forcing inclusion on L1, which for many L2 assets is not going to be the case. You know, you can imagine someone doing MEV around your Frentech key buys and sells and it not being worth it for you to go through the whole trapdoor system on L1, if it's even in place on the given chain.

Noam Hurwitz: Yeah, and that's like all theoretically true. I think, practically speaking, I would struggle with finding out how to send a transaction in this backdoor. And that generally implies like, if our end goal here is to onboard the masses to crypto in a way that's safe for them and self-sovereign, then that effectively is a lightness issue for the entire population.

Nicholas: But Will, I wanted to ask a follow-up question about the permissions. So you'd think that ultimately the permissions should live in the account implementation for the given user rather than in MPC in like the long arc of the history of the adoption of this technology?

Will Hennessy: Yeah, absolutely. Because it's the whole point of making smart accounts programmable is to enforce these restrictions that you as the user want to set on-chain, right? The only way to really try to set restrictions or rules on an MPC wallet would be by trusting the MPC provider to enforce those rules. And they might not, right? And so that's the power of using a smart account, is you can actually program these restrictions on-chain and have complete confidence that, say, going back to the Netflix example, if you set the limit to $16 per month, there is no way that they would ever be able to spend more than $16 per month, even in the worst case attack scenario. Whereas if you had delegated that spending limit to an MPC provider, there's probably a scenario where the MPC provider gets compromised somehow.

Nicholas: So this brings us to this question about having, you know, sort of the fracturing of wallets, maybe app-specific wallets, things like Privy and Frentech are an example of having a wallet that's embedded directly into the app. It's not AA exactly, but you could easily sort of wave your hands and imagine it. Do you think that we're going to end up with a ton of different wallets or, you know, originating in different apps? Is that going to be a temporary thing or are we ultimately going to end up back in a similar kind of place to maybe the UX of hot wallets, like a Metamask?

Will Hennessy: Yeah, that trend has been gaining a lot of steam. I personally think as someone who joined Web3 because of composability and interoperability, that that remains the endgame. I think the pendulum swings as these kind of new technologies develop, but it will swing back to interoperable and people will start building and using abstraction wallets that can help them use and manage their assets and items across all sorts of different apps. Because at the end of the day, like we learned this even in Web2, right? People like to have everything in one place. It's just a lot easier than managing so many different accounts. That said, I think it's interesting to talk about the reason why so many of these apps are choosing embedded accounts today. And the reason is because they're able to remove all sorts of cruft and friction from the onboarding experience when they build an embedded account. Because when the account is embedded, the web app basically has control over the account and can send or sign generally any transactions that the web app wants to, as long as the user is signed in. And that lets the web app do things in the background without pop up windows, without a separate tab, without a browser extension, certainly. And so these embedded accounts are choosing that tradeoff to get even more invisible and remove all of the friction, but at the sacrifice, at the cost of losing interoperability.

Nicholas: Yeah. So we talked about a lot of different advantages of A, we have like arbitrary verification logic, we have multi-factor, multi-sig kind of experiences, both on-chain and off-chain via MPC. We have batched transactions. we, I think, touched on very briefly, but, you know, people maybe are familiar with this example of swapping, doing the approval on the swap transaction in one transaction, thanks to Smart Wallet. There's also account-based permissions and sponsored transactions, lots of different advantages here. So tell me, what is Alchemy building in this space? What, I mean, a lot of complicated things going on. I guess there's a lot of stuff to be simplified for developers.

Will Hennessy: Yeah, indeed. There is a lot. And, you know, that's our mission here at Alchemy. We're like the leading Web3 developer platform, and our goal is to make, help make every company on the planet a crypto company, just as every company today has now become an Internet company. And so our whole goal is to build developer tools that make that really easy. We think that one of the biggest problems developers face today are building good wallets, invisible wallet flows and onboarding users. And so we're building up an account extraction stack that started about nine months ago. We built out the bundler and the gas manager API. And these are hosted services that let you land operations on chain and sponsor gas with just a few lines of code. So our bundler, we run it alongside our fleet of nodes. It's ultra reliable, super scalable. It's powering many of the leading account abstraction teams in the space today. And just like all Alchemy products, it has amazing documentation and a clean API interface to land users on chain. And it pairs very nicely with the gas manager API we've built, which is a form of Paymaster. We currently provide sponsoring gas manager services where you can really simply send your user up to the Alchemy bundler and Alchemy will just pay the ETH when we submit that bundle on chain and then put the USD cost of that ETH on your Alchemy bill at the end of the month. And so it completely hides gas and Ethereum from the user experience and also from your kind of billing mechanics at your startup. And so that covers the infrastructure layer. Yeah. We also have a new product that we'll be announcing later this week called Account Kit that moves up the stack one layer there. Because if you want to use this infrastructure like we talked about, you actually need a smart contract account in the first place. And so later this week, we'll be launching Account Kit with a smart contract account that is fully 4337 compliant and able to execute user operations on chain and sponsor gas. We're also working with many of the signers and NPC services that we've talked about here. They will all be compatible with Account Kit so that as a developer, you can ship an account abstraction smart account using your signer of choice. It can be NPC, it could be hosted wallet, you can use pass keys. All of these things are going to be at your fingertips with Account Kit and they'll all be really easy to integrate using the AASDK that we've developed here at Alchemy to tie together accounts, bundler and gas minute. Easy.

Nicholas: That's great. So I have a couple of questions on this. So from the docs, the docs mentioned this complete solution that from Alchemy you're providing. Maybe it's now considered Account Kit, but really a complete solution that implements a EIP 1193 provider, gas estimation, transaction signing and paymaster fetching data, etc. So there's like a lot of different moving parts here. Maybe could you just explain how does one actually connect to ADAPT if it's not like embedded directly into the app? Why is this like 1193 provider important? And how does one connect into an app with an account abstraction wallet?

Will Hennessy: Great question. Today, most of it and also our Account Kit product is designed for a single app. And so the way that it works is a developer would embed the AASDK in the application and AASDK exposes functions to create an account or connect to an account. And 1193 is basically a JavaScript client interface for web apps to send requests to a wallet. And so you can think about it. as traditionally 1193 is sort of the bridge between the web app and a browser extension like MetaMask. In that case, the wallet lives outside of the web app and in the extension. In this case, the sort of wallet entity can be thought of more as living inside of the web app with Account Kit. And it's inside of the AASDK. And so the web app can send requests to connect to a wallet or to sign a transaction to the AASDK, which is embedded in their web app. And then AASDK will execute the appropriate backend logic to complete that request. So if it's, for example, if the app is requesting to sign a transaction or sign a user app on their smart account, the AASDK would handle all of the logic to call out to your chosen signer provider, like say Privy or Turnkey. The AASDK would call out to their API with the authentication credentials that the user had used to log into your app, like a Passkey or Google. It would then receive the signed transaction and then send it off to the Alchemy Bundler to bundle up that signed user.

Nicholas: So there's nothing equivalent to like a wallet connect experience or injection. 1193 kind of covers that and assumes that the signer is in the same context as the SDK.

Will Hennessy: That's right. Yeah. But again, back to your earlier question, this is all in the domain of an embedded account that works with a single app. And I think your question is a very good one. I think as an ecosystem today, we're kind of missing that interoperability. fiber, right, to connect an account abstraction wallet to a bunch of different apps. There needs to be a sort of a vessel or a bridge, right? Like a browser extension does that job where it's an interface that you can use to connect to many different apps. And that doesn't really exist yet for account abstraction, although I know there are some teams.

Nicholas: Something to look forward to.

Noam Hurwitz: I guess just to jump in there, too, I think there's nothing that is interoperable and embedded. I think there are interoperable contract accounts. So a good example is SolWallet, which has been building for a few quarters now as well to make a Chrome extension, recoverable smart contract wallet, excellent team there. And there actually is like WalletConnect style interfaces. So again, the point of account abstraction is to abstract away the cost of the account from all this infrastructure. At the end of the day, an account is an account and it can adhere to the same standards. So you can use things like WalletConnect for contract accounts. I think another team that does that is called Handbuyer Wallet. But I will say a limiting reagent here that I will plug for the audience is ERC-1271, which is signature support for contract accounts and that any dApp that requires a signature from the end user. So I'm going to sign up with Ethereum or even like OpenSea's permissioning for asset transfer requires 1271 support. And so that's not necessarily the de facto building mode for dApps today. And it's something that is getting added to SDKs and tooling over time, but it's something for dApp developers to be aware of so that their application does support contract accounts.

Nicholas: And that would be something that would be integrated into the dApp. Is that more like when you sign in to sort of sign the terms of service going into OpenSea? Is that 1271 or could it be?

Noam Hurwitz: I can't remember that exact flow, but the one I'm thinking of is like when I list assets, it's actually not listed on chain. Like I send them a signature that gives them permission to move assets. And so that signature itself is generated by my account. With an EOA, that's just, you know, I'm signing something with my private key. With contract accounts, you need the contract account itself to produce a signature. And so that's what's defined in ERC-1271 so that you can produce a valid signature on behalf of a contract account.

Nicholas: I think, don't quote me, but I think I have encountered this with trying to use OpenSea as a Gnosis safe.

Noam Hurwitz: It's very possible, yeah.

Nicholas: So yeah, that's right. Essentially, you want to be able to sign messages, either just to sort of prove ownership of something or to sign something like an intent. And 1271 lets you do that with smart contract accounts.

Noam Hurwitz: Totally. And the other big reason to sign that we're excited about is to sign with Ethereum and authenticate into actual servers using, it's effectively a passkey at that point, right? You're using your private cryptographic key to prove that you are the actor you say you are by signing into a restricted resource like a server.

Nicholas: And is 1271 something that needs to be integrated into the smart contract account? or it comes for free with 4337?

Noam Hurwitz: So it is something that needs to be integrated in the smart contract account. That's one key thing that is in the account get released. It's predicated off a very light account called Light Account that takes the example released by the Ethereum Foundation called Simple Account and adds a few key pieces. So one is 1271 support for signatures. One is ownership transfer that it's for compatible. You can rotate owners to new signers. And the last piece is namespace storage so that if and when you upgrade the implementation, you're avoiding any possible future collisions.

Nicholas: OK, awesome. For the account kit product, this kind of leads me to a question I was going to ask, which is, you know, there's different implementations of 4337. What are the major tradeoffs? So like, why would someone choose one or the other? And what are the defaults that you're providing in account kit?

Will Hennessy: I can take a stab. No, but it's a good question. I think there are different layers in the stack and the whole stack is fairly modular and the layers are actually all the pieces we've talked about so far. So you have the bundler, the gas manager, the smart contract account and the signer. Those are kind of the four key components that a developer can choose from. And our account kit is offering kind of the alchemy default for all four of those kind of out of the box. Right. So we provide our best in class bundler that's super reliable and scalable and low cost. We provide our gas manager API to sponsor gas for you on any of the major EVM chains. And like Noam was just talking about, we offer the light account, which is a secure smart contract account that's been gas optimized and offers nice features like ERP 1271 signatures, as well as like ownership transfers. So if you want to change your signer from one NPC provider to a different one, you'll be able to do that at the contract level. So those are sort of the core default offerings in the account kit out of the box. But it's also completely customizable where you can plug in, you can plug in different providers for any of these layers in the stack.

Nicholas: OK, and then for the implementations of AA, is there like just some shelling point around these contracts? Because they'll all be open source, presumably. Will people just use something like the Alchemy Lite implementation or are there other advantages, reasons why people might choose specific other implementation contracts?

Noam Hurwitz: I can take this one. So we view Lite account as a bit more of a stepping stone. In parallel, as I mentioned earlier, we've been working on ERC 6900 now for about three quarters and more recently with the Ethereum Foundation. And the idea between ERC 6900 is to define the standardized interface between the account and any number of plugins. And so this has a number of benefits. One is that any account becomes compatible with any set of plugins. So you minimize any sort of lock-in to specific account implementations on-chain. You can upgrade your accounts to a different account type and still utilize the same set of plugins. On the other hand, developers now, the idea is DApp developers today become plugin developers tomorrow. You might have some sort of execution plugin or validation plugin that you need in the context of your application. You can write that on-chain and get compatibility with any account implementation. And so what this leads to is a concept of minimizing rewrites and maximizing reuse, where you have this high degree of on-chain modularity. You get security because hardened implementations get promoted and reused and used more broadly and examined more broadly. And you get a compounding velocity of execution because not everyone needs to rewrite the same components just for their account implementation. If there's a component that you like to see on your account, you can just go find a plugin and install it.

Nicholas: So I guess with the 6900 and ultimately where AccountKit is headed in integrating it is, don't require people to change their whole smart account just to get some new feature, but instead just swap out the plugins.

Noam Hurwitz: Right, exactly. And it could even be not just swapping in and out plugins, you could swap in and out plugins to specific signers to be like, hey, this plugin only applies to this signer. I want to either remove this signer or update the signer to have more restrictive permissions. Let me change the plugin settings on this one key.

Nicholas: And I guess that'll be essential to sort of the follow up to the current meta, which will be sort of using these smart accounts across multiple apps. It'll be important to have different signers with different permissions. Do you have any thoughts on how these permissions might be presented to the user? Like, I've been thinking a little bit about, say, Frentech, let's say Frentech was a shared wallet that you already had. And when you sign into Frentech, you just add a signer. that's specific to Frentech. I'm not sure exactly what kind of permissions I would want to give, because let's say I want to buy or sell, I don't know, Racer's Key and Racer's Key has gone to 8 ETH. If I just had some like limited signer permission with that embedded privy wallet to say only move, I don't know, maximum one ETH, then suddenly the permission would like not be sufficient and I'd have to go to some other location where the like main signing key is to update the permissions. Do you have any like thoughts on what the patterns for permissioning will be?

Noam Hurwitz: Yeah, I think it's super flexible. So there's a lot of ways you can take this. One element is you can restrict execution to just a set of contracts and even function selectors. So it'd be like this key really only has permission to interact with Frentech contracts. I think a second component is multi-factor authentication. So it'd be like, hey, anything below 8 ETH just requires my one signature. Anything above 8 ETH requires MFA from two signatures on my account. And you can kind of mix and match all sorts of perimeters around spending limits, temporal limits, multi-factor authentication, contract restrictions, etc. to create the right restrictive set of permissions for any given key.

Nicholas: Very cool. So you could imagine having, say, a signer that is maybe lives inside of the interface app or surreal or Mint.fun app or something like this, and just give it permission to call mint functions, you know, or whatever whatever set of restrictions Mint.fun applies to only be able to like mint something and not really compromise, maybe not even move more than, I don't know, 0.1 ETH and just have kind of a safe experience, but have the fluidity of like a one-click checkout experience inside a variety of apps using your same shared account.

Will Hennessy: Exactly.

Nicholas: Very cool. OK, is there anything about AccountKit that we haven't discussed that that we should definitely get to?

Noam Hurwitz: Maybe not AccountKit, but another plug. is that this bundler that we've been talking about. So we've been benchmarking it a lot. It's been under development for about three quarters. We've clocked it using... TPS is kind of a bad metric for blockchains, but we clocked it at roughly seven and a half million gas per second on Polygon, which is half of all gas available on the Polygon network. It has roughly unlimited throughput on the read path, which is really the limiting reagent. there is fan out requests to the underlying node. But we actually open sourced this last week under a permissive LGPL license. Anyone's free to take it, run it, fork it, update it, contribute to it. We love any and all ideas and contributions. And the reason we initially set out in building this bundler is we view constant accounts as just a core tenant of getting and going people on chain. And we think it needs a production grade, enterprise ready, like alchemy vetted quality set of infrastructure supporting that. And so we're really excited to contribute this back to the ecosystem and to have more folks starting to build on it and contribute to it.

Nicholas: That's very cool. If people want to look into that, I guess just bundler alchemy on Google, something like that.

Noam Hurwitz: Yeah. We called it, again, circling back to the first point we made about naming it Web3, we called it Rundler, which is Rust Bundler. But yeah, you guys can find it on github.com/alchemyplatform/rundler. Or if you just look up alchemy bundler, I'm sure you'll find it pretty quickly, too.

Nicholas: Awesome. I had a few questions from Alexander Chopin, accountless.eth, anyone who knows. Three questions. We kind of touched on these, but I'll just throw them out there in case you have anything additional to say. Alexander wanted to know, modules, how's that going? When will it be ready?

Will Hennessy: Great question. And I'm glad Alex is following along with modules. So that's referring to EIP-6900, our standard for plugins and modules. We just posted a new update on ETH Magicians on Friday of last week with the fourth and hopefully final revision to get us to a stable spec as a community. So we'd love anyone listening to go check that out. on ETH Magicians, share your feedback in the comments. You know, like Noam said, our goal here is to get to a standard interface for app developers around the world to build plugins for the new wave of 4337 smart accounts that are taking off. So feedback is really valued and the goal is to move that spec to a stable state sometime in the next few weeks or month, depending on feedback from the community. And from that, then we'll publish a reference implementation of a 6900 account as a sort of an example of how you might go about building your own plugin or 6900 account. And the goal is for that to kick off a wave of module development. And we're really excited to see what kinds of use cases people build from, you know, DeFi managing positions to pull subscription payments to things like account recovery and backup methods.

Nicholas: Great. Second question from Alex is registries. What do you think of them and will there be many or what will the impact be? Do we have any leads on where this is going in the near term?

Noam Hurwitz: I can take a stab at this one. I will say this is probably not an area of our expertise, but what he means by registry, he's asking about like, where can I find the set of plugins available to me as a user to install or remove? And how do I know that those plugins are secure to be added to my account? So 6900 defines this plugin manifest that effectively tells the account how to install a plugin, what it needs to know about the plugin in order to execute it and how to uninstall a plugin. And then this other component is registry, which contains a set of plugins that are available for installation. The long term idea that we've seen kind of talked about in teams like Safe and Rhinestone is having an on-chain attestation system to enable users to indicate trusted plugins or audited plugins or any other criteria they want to on-chain. It's going to be pretty interesting to see how this space shakes out. I'm clear there's going to be many registries, one registry, like vertical specific registries or any other kind of breakdown of how this might play.

Nicholas: Yes, I was talking to the Safe team a little bit about that at ETH Global NYC. And yes, they're definitely working on that. I'm curious to see if the model that they're going after is what's truly successful. Last question sort of on the topic of Alex's interest, if not directly a question from Alex. Sessions. Do you have any thoughts on the experience of being like logged into a session in an embedded app and not having to sign every single time? Do you think people should be face ID'ing every transaction or do you think face ID once when you get into the app and that's good enough?

Will Hennessy: I think it depends a lot on the application. And so we're going to see different people design different approaches to this. You know, even if you think about the Web 2.0 analog, when I buy $50 of groceries at the store, I need to use face ID with my Apple Pay. But when I scan into the subway for $2.75, I don't have to face ID at all. And so there's definitely a boundary of convenience versus security. So if you think about something like a game on Polygon where they're spending pennies per transaction, you should absolutely design a session based approach where the game can spend up to some amount of money for the next couple of hours without even. But if you're doing something like trading large sums of money on the decks, you may not want that approach. You might want to have a much tighter control over how you're investing your life savings.

Nicholas: Definitely. So I guess the point is that the flexibility of adding multiple signers and having permissions either at the NPC layer or in the AA wallet itself just lets you have a whole spectrum of access that makes UX better overall.

Will Hennessy: Yeah, exactly. You know, if 4337 gives us smart accounts, then our current generation of EOAs are dumb accounts. The whole job of a wallet is to permission the spending of your assets only when you want to do so. Right. And so the smart account lets you do that programmably so that you don't have to get prompted every time by your wallet to sign a transaction. You can actually start to delegate some of your own decision making and logic to the smart account by programming your thought process and your preference into the account itself with a plugin.

Nicholas: Awesome. There is one last nerdy topic I just wanted to mention because it sort of came up in our conversation. But have you seen DC Posh's proposal for this precompile shadowing with Create 2? I think that's so cool.

Noam Hurwitz: I have not. What's the high level takeaway there?

Nicholas: High level is do R1 verification on chain with like the ledger or whatever most optimized R1 verification contracts are. And then trustlessly transition to 7212 precompile so long as the contract doesn't change, of course, by sort of having it built in, programmed in, that you'll be transitioning to that if it ever is finalized as a precompile.

Noam Hurwitz: Yeah, that is super cool. Another interesting take we've seen on R1 today, by the way, is if you're familiar with Arbitrum Stylus, I think that also gives you a nice ramp up to experiment with it today before migrating to a precompile later.

Nicholas: Because they are just bundling in the precompile into Stylus?

Noam Hurwitz: So Stylus execution costs are up to several orders of magnitude cheaper than standard EVM. They call it EVM Plus. So you can write this R1 verification logic in Rust and call into it from your Solidity contract and use their Wasm execution engine, run that code at a cheaper cost and fewer resource utilization, which gets passed on as gas savings. So they benchmarked it on a few different compute intensive operations and it gets anywhere from like 10x to 500x cheaper using Stylus instead of Solidity.

Nicholas: Very interesting. I'm curious to see if developers are down to do chain specific optimizations or I mean, if you plan on living entirely on Stylus, why not?

Noam Hurwitz: Totally, yeah. So this will be native for the whole Arbitrum ecosystem. I think we already touched on. there's a lot of threads that need to converge here over a period of time, but one of these is the interoperability component. And so the experiences that we've seen really leaning in hard right now are things that might need slightly less like cross-chain interoperability. So things like games, which might be deployed on Arbitrum Nova and they can take advantage of these primitives while being isolated to a single chain.

Nicholas: Awesome. Will, Noam, this was a wonderful conversation. If people want to check out more about the Alchemy AA solutions and account kit, where should they go and where should they go to find both of you also?

Will Hennessy: They should visit alchemy.com. We have an account abstraction page there. that will give you a nice overview of all the products that we're building. If you guys are listening live, check out, follow our Twitter account on Alchemy. You'll be the first to hear about the account kit launch this week. And if you're listening on podcast, you should already have it live on the website. So we'd love for you to go check out the developer docs, give us some feedback and feel free to DM me on Twitter. My DMs are always open to talk about account abstraction. You can find me here @willhennessy_ on Twitter.

Noam Hurwitz: Yeah, everything Will said. We're also starting to lean a little bit more into the open source nature of this work. So ERC6900, Rundler, we're open source combined account, we've open sourced AA SDK. If you have any questions or are interested in getting up to speed on those codebases and/or forking them or contributing them, we'd love to chat. Also be able to talk about this stuff. You can find me @ProbablyNoam on Twitter.

Nicholas: Awesome.

Will Hennessy: And last shout out is, you know, I imagine we have a lot of developers listening in. We'll be at DevConnect in Istanbul in November later this year. That's going to be another awesome Ethereum conference. So we'd love to chat to people there. And in particular, we're organizing an account abstraction day with the Ethereum Foundation and a number of other teams building in the space. So if you're really interested in account abstraction, reach out to us or come find us there. And we'd love to have you.

Nicholas: Awesome. I'll be there too. So looking forward to see you. All right. Everybody, thank you so much for coming through to listen. Will, Noam, thank you for coming and sharing all this great knowledge and a little bit of alpha for an announcement later this week. If you enjoyed this episode, please do give it a review or give the show a review on Spotify or Apple Podcasts. It really does help. Thank you both. And see you in Istanbul.

Will Hennessy: Thanks, Nicholas.

Nicholas: See ya. Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter @Nicholas with four leading ins. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at Web3GalaxyBrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5 p.m. Eastern Time, 2200 UTC on Twitter Spaces. I look forward to seeing you there.