Native Account Abstraction #1

Transcript

Lightclient (Matt Garnett): Hello.

Bobby | Ambire: Hello, guys.

Marc Garreau: Appeal, how we doing?

Lightclient (Matt Garnett): Good. Ready for a fun call?

Marc Garreau: Should be fine. If anything, the agenda is overly ambitious, but we'll do what we can.

Hey everyone, we'll get started at, 3 past the hour. Just give enough people a chance to trickle in.

All right, welcome everyone. I will post in the agenda in the chat, and then we'll kick this thing off. So welcome to Native Account Abstraction Breakout Number 1. Today is April 22nd, 2026. The agenda is a big one, so, Let's… let's get through what we can, and Find out how much is left over for the next chat. The context for this new series is that EIP8141, that's Frame Transactions, was recently proposed as a headliner for HEGOTA, the Ethereum upgrade after Glamsterdam. It garnered support from a variety of stakeholders in the ecosystem and was CFI'd, meaning considered for inclusion in that upgrade. But ultimately was not selected as the headliner by client teams, and the reasons given varied

And they are hopefully well represented in today's agenda. But in short, if I may summarize, client teams wanted more time to understand the implications on the mempool, stateless efforts, privacy preservation, and the post-quantum roadmap, among other design decisions. More broadly, though, the proposal generated Well, it feels like real momentum for shipping native account abstraction in the Hegota fork. So there's been a flurry of other proposals, both alternatives to 8141, and those complementary or compatible with it. So now seems exactly the right time to start to converge on a version of this feature set that we can all live with. The sooner we have rough consensus on an approach, the sooner client teams can begin pipelining the work, and the sooner the broader ecosystem can begin the long road to adoption.

Last logistics note, breakout calls like this one cannot change the inclusion stage or the headliner status of an EIP. That can only be done by rough consensus within an all-core devs call. So I would suggest that a good use of time here is to improve our collective understanding of the trade-offs we need to make, to refine the existing proposals, steal good ideas, and identify whatever the next steps are to move forward with confidence. So that's sort of the preamble. Before we jump into hearing from proposal authors on recent updates, the first feedback I've heard that I would like to at least briefly acknowledge is the sentiment that we… should be sure we're clear on goals and what we're solving for here. It's true that account abstraction means different things to different people.

And much has been written on that topic. For example, Vitalik has outlined core and stretch goals in his full account abstraction doc that you can find in the agenda. I've heard Matt and Felix and others describe their motivations on all CoreDev's calls, but I wanted to leave at least a little space here. So the prompt is, would anybody like a minute or two to communicate what you think is most important for a native account abstraction proposal to accomplish? Those I've mentioned already are welcome to come up and reiterate any points. Maybe this is a good opportunity for other ecosystem stakeholders to chime in, so just raise a hand if you'd like to Say a few words?

Ivo Georgiev: I can give you a few thoughts from the point of view of a wallet developer. So… There's a couple of things, and they're all related to the practical efficiency of existing account abstraction solutions. So, one of them is… really, 7702 and all solutions before 7702, which were just proprietary solutions, what they managed to achieve, a lot of things, but without actual upgrade paths for existing EOAs and existing accounts, the adoption really stalled. 7702 kind of solved it, but the issue with this is that it still requires an authorization, and most hardware wallets still don't support this feature, so they still, like, either rely on a very narrow, whitelist. or they don't support it at all. So, in practice, the current account… the current state of account abstraction is that you cannot use account abstraction features in many EOA accounts. So, this is something that frame transactions solve.

So that's fantastic. And then the second thing is, 4337 really is kind of a bit clunky. Some would even say bloated, and that's also another point of, point of view that, frame transactions solve. So this is, like, the practical implications.

Marc Garreau: Thank you. Agus, if I'm pronouncing it anywhere close to right.

Agusx1211 (Polygon): Yeah, I think so. In our perspective, we are a polygon, we are X-sequence, we are also Smart Control Wallet. Our point of view of account abstraction, really, or in the context that we are discussing this, is that this is what, in the old times, was called every layer, like, this is an alternative to have a proper solution to be able to execute the smart contract transactions on-chain. And our point of view is not really about migration from old accounts or anything like that. We are working mostly with new accounts. But what we want to preserve is the flexibility to develop new functionalities on smart contract wallets. And what we want to gain is not having to maintain and develop around custom, like, vertical layer that is not a great, like.

not a great participant in the whole stack. It's not decentralized, etc. M… So… From our perspective. any solution, we are big supporters of frame transactions as they are, mostly because they do allow for a full spectrum of development of new functionalities and things like that. If we go into something more constrained. what will likely happen for us is that we will just not use it, and we will keep, like, working on some of the previous standards. But… Frame transactions as they are is something that, like, will be very useful for our team.

Marc Garreau: Thanks, Matt.

Lightclient (Matt Garnett): Hey guys. Just wanted to share a little bit of my perspective. I've shared it in… you know, many different contexts over the past few months, but if I could try to address one point that's been coming up a bit around the post-quantum side of AA and the frames transaction. You know, when we originally started with frames, we had a… A lot of conversations, like, what are we trying to achieve? And… there's a doc that I shared by Vitalik that, you know, kind of goes over many of the core goals that we had in mind with accounts abstraction. And at that time, you know. And even today, I feel like post-quantum is becoming something that everybody's realizing we need to start thinking about and focusing on.

And I felt that… focusing AA and frame transactions a bit in this direction of post-quantum was good, because, you know, broadly, everybody feels this is a direction that we should be working towards and focusing on. And we know, as, you know, people who have been working on the protocol for a very long time, and people who have, you know, been working on account abstraction in different ways for, you know, 6, 7, 8 years, you know, we know all of the downstream effects that AA would provide, and it's very difficult to… You know, have these breakout rooms, have these, you know, long. running discussions about what the protocol should and shouldn't do, and, you know, how should they deliver accounts abstraction, how should they not? You know, we're all kind of seeing how difficult it is to define what accounts abstraction even is. You know, it's different for every single person, and it just depends on, like, where in the stack you're sitting.

And so I felt like, you know, focusing a bit on post-quantum was a good rallying point for people, where we could say, look, it's not that we don't care about UX, it's not that we don't care about these other things, it's just that, like, we need to solve post-quantum, and we have this really good technology that does tons of other things at the same time that we've been working on for a long time. And, I don't know, maybe that was, like, kind of, like, the wrong initial approach. And some people have, like, you know, pushed back and said, do we really want to tie, you know, post-quantum to count abstraction? And it, you know, it's a question. I still think that, like.

you know, broadly, this is the right direction for us. It's not the easy path to solving post-quantum, but it's a path that we understand pretty well at this point, and we just need to, you know, put in the work to achieve it, and to define the exact feature set that we're trying to, you know, achieve. And so, you know, through all these conversations, I've also kind of, like, realized that there's one, you know, other piece that's kind of in this original Vitalik doc, but, like, maybe wasn't, you know, communicated as clearly from the beginning with 8141. And that's something that I… you know, this is something that I think that most other proposals, you know, also don't really support. And the frames and the native AA proposals are basically the only ones that support it. And that's that, you know, we're trying to reduce

the centralization around transaction flow in Ethereum. And we're trying to allow all users of Ethereum, you know, both ELA and smart accounts, to make use of new, you know, hardening functionality in the protocol, like FOCIL. And that's, like, you know, maybe something that we haven't highlighted quite as much in the past, but I think, like, going forward, it's something that we should be keeping in mind. Like, yes, we need to have batching, yes, we need to support key rotation, this is all, like, critical for accounts abstraction, but we need to make sure that we're doing this in a way that, you know, supports post-quantum. Supports post-quantum aggregation types of techniques. And reduces the reliance on centralized relayers.

And so I think, like, this combination is kind of how we've come up to, you know, presenting the frame transaction. And, you know, some of the decisions of the frame transaction may not always be the most obvious of why these decisions are getting made. But all of this… all of these decisions are coming from, like, many years of experience across, like, you know, Felix Vitalik and I from the protocol, Derek from the wallet side, and then interacting with, like, you know, tons of people in the wallet community and the application developer community on understanding, like, what their needs are. So, that's kind of, yeah, how we've ended up, you know, from our perspective on the solution that we have.

Marc Garreau: Thanks. Ben?

Ben Adams: Yeah, so, I appreciate the flexibility of frame transactions, but, from my perspective on approaching it more pragmatically, and, what's practical in terms of… so, for instance, a frame transaction, you could, in theory, do a, like, a post-quantum signature, and then… Validate that. In… in that, but at the moment, we don't have a way in the EVM of Efficiently running that. So, you know, like, Falcon would be, like, 2 million gas. Dilithium would be about 8 million gas transactions. So these, these are, like, heavy. I mean, even EDSA is… I don't know, it's like 100,000 gas or something? Versus… as… in protocol, as a precompile or native, then it becomes, you know, 3,000 gas. So it's orders of magnitude different.

If it's running as… current EVM bike code. I know there were… proposals, which I'm not sure are currently active to do, like, EVM Max and FIMD to do efficient crypto… Cryptographic, processing. But I don't think they are active at the moment. I could be wrong. So I… my… my concern is that we would… Deliver something that, in theory, can Meet lots of needs, but in practice, would fall down. If you see what I mean. So if your… if your transaction, just to verify the signature is costing 2 million gas, you can only have 30 in the mempool. And you… that's the size of a block, just verifying those signatures. So for instance, scheme transactions would say, alright, well, we accept that we need currently, native.

Processing for these, signatures. Rather than… you know, write it as raw EVM bike code when That would be extremely expensive to process. Yeah, it's more about practicality. Will it deliver? On the expectations in a practical way.

Marc Garreau: Thank you, Ben. Mustav?

Mislav Javor: Yeah, hi everyone. On my end, I just wanted to basically reiterate, support, from my end for the frame transactions. Though the critiques are certainly valid, and by any means I'm not an expert in post-quantum cryptography. I think for what we've seen in the cases of existing AA teams and the use cases that we have been serving for the last 2 or 3 years. Frame transactions luckily capture all of them in a very elegant manner. Even Derek made a proposal yesterday to access, like, some bits of, non-self state without hurting the mempool, etc. So I feel, as far as the coordination is going on the account abstraction teams, we can do a lot, and standardize a lot, through the frame transaction,

through the frame transaction, proposal as it is right now, maybe with a few minor changes, and that's, yeah, that's definitely something I would… give it as a big plus, because, you know, like, it's always been notoriously difficult to coordinate in the AA community, and yeah, frames have actually managed to achieve that in quite a significant way, so I think that's a very big plus.

Marc Garreau: Thank you. Press switch.

James Prestwich: The things I think are most important for native AA to accomplish are transaction batching and permanent key invalidation. You need to be able to permanently invalidate the credentials of an account. And replace them. Frame transactions accomplish these in… reasonable, but fairly complex ways. They require an awful lot of wallet rollover. and… you know, I think that simplifying implementation is the other main thing native AI should accomplish. I don't think that… Future compatibility for unspecified aggregation systems, or for… Other unspecified future cryptographic systems is important.

Marc Garreau: I appreciate that. We're gonna wrap up here, but Chris, are you able to… Speak quickly on this topic?

Chris Hunter: Yeah, I can go… try to go super quick, but, like, I think, you know, in summary, I think, you know. Teams have different kind of opinions on, like. What's important based on, you know, if their wallet, if they've run protocols, etc, like, and… frame transactions, like, you know, I think speak to the ethos of Ethereum, like, being uncensorable. And compatibility with FOCIL, like, that's all… You know, super powerful and whatnot, but… I do think, like, I hear a lot of feedback from, you know, wallet teams, it's like, well. again, I think the only feature they do want is, like. So the ERC20 gas payment, and then a few signature types. key rotation. And that, you know, that seems to be, like, you know, roughly it. So, I think there's,

a bit of overhead being paid and, like, the complexity of frame transactions for, like, maybe future features that we may not necessarily use. And that's the, you know, I'm just trying to, like, aggregate some of the feedback, that I've gotten as well, just on, you know, why teams aren't… don't want to do, 8141. I think, like, everything else has kind of been said. And then, like, in general, 8130 is, like, just trying to address some of the performance issues while still being general, but more… defined in certain sense, so it's not quite as flexible, like, the frame ordering is… Sorry, the ordering of, like, what you can do and what you can call is explicit to try to make, things easier for protocol and denial of service risks and whatnot.

But all those, like, things have to be considered as… Like, obviously 8141, and, like, AA in general touches, you know, pretty much the entire stack, from protocol, right, to wallets, to, like, UX to everything, right? So… Yeah, just to add that.

Marc Garreau: Great, thank you, and that's, maybe a good transition as well. maybe my parting thought on this topic is that I don't think it's reasonable to expect consensus on this topic. Yet, it is very valuable to hear what's important and what's at stake for different users of Ethereum. Let's transition here to the, proposal updates section. So, for each, proposal, I welcome the authors to catch up… catch us up on developments from, let's say, the past month or so, because it was, maybe three-ish weeks ago, where the last debate of account abstraction or These… this set of proposals occurred. And I know there's been a lot of activity since then. I'll leave the floor open, does anyone,

Does anyone want to step up to… Provide some updates for the proposal they are an author for.

Derek Chiang: Oh, I think I can probably, like… give some updates on the firm's side. So… I think based on what everyone has said, it's clear that there are two competing… I guess, goals of AA that, I guess are pushing some of the Yazis, you know, EIPs in different directions, right? So, one thing that people want, is flexibility, right? You know, people want to, for example, be able to. originates transactions from privacy protocols, right? So that will save users of privacy protocols from having to rely on centralized relayers. So that's, like, one example of the larger goal of Flexible validation logic. But then on the other hand, you also hear people who want to have. essentially predictable performance when it comes to the mempool, right? So people want to be able to validate transactions very cheaply, without necessarily having to chase through a very large transaction, right? And that's also true for L2s, right? You know, so that's why Chris from Base

mentioned that, some L2s, they, you know, they also want that, right? So one update, you know, so, and by the way, like, that's actually been the top priority, within, kind of like, the firm's author group, which is to adjust this dichotomy, right? You know, like, the, kind of like the tension between flexibility and performance. So, one solution that we, worked on, I actually posted a PI in… the AA Mafia, you know, yesterday. Basically. It's this idea of allowing, friends to be structured such that the payment, the payment frame. can come before the sender validation frame. So, normally for every transaction, obviously, like, no one pays gas unless the sender signature is valid, right? Because if the sender signature is invalid, then obviously this transaction should not be authorized, and therefore no one pays gas, right?

But since frames kind of, like, decouples the authorization from the ordering, right, you know, because you can order firms in any way, we're actually able to allow, I guess, people to approve the payment of a transaction before the validation of the sender signature. So what this does is that, if a member pool sees a friend's transaction where the payment is authorized first, then they actually do not have to check they do not have to validate the sender logic. So what this means is that, for example, today, if you want to send a, a privacy, you know, a transaction originated by a privacy protocol. that may be hard to propagate through the public manpool, because the privacy protocol validation might take a lot of guess, right? But with this change, as long as you can find another sponsor for your transaction, which can also, by the way, be one of your other wallets.

Then the mempool just has to validate the payer signature. The mempool doesn't have to validate the sender signature. So that's essentially one way for us to achieve very predictable performance in the mempool. wire still allowing arbitrary, sender validation logic. So, I think that's, like, a really, sort of, like, noteworthy update that is currently being worked on for friends. Yeah, not sure if there are any questions, or if maybe Matt or Vitalik want to add anything.

Marc Garreau: Okay, thank you. Ben?

Ben Adams: Yeah, so I added, I tightened up the spec for frame transactions a little bit, and that's been merged. But also… So they, added two more EIPs, which are, Contact contract payer transaction. And the idea… so… You'd have something… Else that would handle, Changing the cryptographic keys in terms of what you're signing with, which would be schemed, but I think there's a number of other EIPs for that. And so if we divorce that, from… From the system, then the idea with The contact payer transaction is… it would be, like, one-to-one, so a contract would say, I accept.

I am the… I am the… I am owned by this signer, so your, your… the EOA effectively becomes a signer. And… the Memple could go, okay, does this contract have enough ETH to pay for the transaction? And it becomes a very light way to verify it. Rather than having to invoke the, EVM. And then… Also, there was the counterfactual transaction. Which is a similar thing. But you can validate that a privacy pool could pay for the transaction. What's being withdrawn… you prove that what's being withdrawn from the privacy pool can cover the transaction gas, so those are the two others. But it's, So the combination of the EIPs is more unbundling than Frame, which is a different kind of layering.

That's this. I… I'd highlight a difference in the sponsorship, So the contact payer transaction is essentially one signer to one vault. The signer can have, like, many assets, many contracts that approve them. So you could, you could sign, you know, you could say, I'm using this smart contract. You'd essentially do two, and the… the smart contract, because it's a smart contract, can do batching and all that sort of stuff, so that's… that's fine. But it wouldn't do what Frame Transactions does, where you could have a difference between… I could be sponsored by somebody completely different, you know, that could be disconnected. It would be like. You… you can be sponsored by your assets, which are in a different account, not…

Some third party can do it. If that makes sense. Buddy, you can… Through that, you can achieve key rotation and all that. Stuff as well, because you change who the signer key is for… For that vault. And then the assets are now at a different address. And the identity would be associated with the smart contract, because that's the thing that contains everything. So that would have your… You know, you're… ENS names, your positions on Aave, or… or whatever. So it just sort of inverts everything.

Marc Garreau: Cool, thank you, Ben. If we've got time for it, there are sub-bullet points for privacy and adoption strategy. Some of this is, good debate to occur there as well. The… last EIP on my radar. I know Frederick was interested in saying a couple words about, 7906, which is… Compatible with, frame transactions? Frederick, do you want to jump in?

Fredrik Svantes: Yeah, yeah, sure. Yeah, to give you a bit of a background, so during the outreach of the trillion dollar security project, we asked basically hundreds of people and entities for feedback on areas, that they felt we should focus on to help onboard the next billion users. And… There was one thing that was always brought up as one of the most problematic factors for mass adaptation, and that was the amount of hacks that people fell victim to, primarily to things like drainers and phishing attacks and other things. It's obviously a problem here when someone do lose their funds, on, like, in its own. But then, this is amplified by quite a lot, when, you know, they will naturally tell their friends, their family, colleagues, etc, about what happened. And that kind of creates this negative spiral.

So… We have been looking into ways to fix this, and there's no, like, silver bullet to fix this, but, you know, there are projects such as Clear signing being worked on that would help people more easily understand what they're signing. There are verifiable frontends that help provide the ability to wallets to display warnings if a front end that people are interacting with has been compromised in any way. And then there's transaction assertions, which is, yeah, I guess the topic here. So, you know, today, if you use a wallet, normally what it will do is simulate what you're about to sign, and you can see that it looks like this is gonna happen. But a simulation is…

Just a simulation, so it's not, you know, binding. And the real issue is not… Like, if the intended action happens, but… I mean, that's not the only issue, it's also if any extra side effects happen that the user never approved. And that can be, for example, you know, you think that you're gonna get a NFT by doing this transaction, which you might get, but you also approve a spender… a malicious spender address on your USDC, for example. And then, so transaction assertions, they basically solved this by letting the user approve. what could be called an envelope of effects. Basically, execute this specific thing, but then revert your transaction if the actual outcome goes outside of this policy.

We've been discussing many ways of doing this, But I think this fits very naturally into frame transactions, because frames already separate the execution into stages, so, you know, frames can give us the structure, and then assertion can give us the safety policy at the end. we've been thinking about different ways of doing this. It's been, I guess, discussed in various forms for, like, a year or so, maybe even more. We had a big… a fairly big breakout at DevConnect about this as well, discussing the pros and cons of For example, one idea was to have a new transaction type, Which was then, kind of, shelved after discussions. And then, basically the… the best approach seems to be to have an opcode. So, there's an EIP for this, 7906, which basically helps fix this.

The next step here is basically to create a proof of concept that this works, some kind of a demo playground that shows, you know. With… without, 7906, This is what would happen during a malicious transaction with 7906. This is, you know, how it would be stopped, basically. And then, create some tests and such, so we can hopefully be included in a future hard fork. Yeah, I guess, Something I did want to bring up is that I saw that eTrex made this, cool them implementation of transactions, and yeah, perhaps… We can chat later about doing something similar to this to show, basically, how 7906 ties together with the frame transactions and provide the ability to prevent these kind of attacks from happening.

Alex is the author of 7906. I think he's in the call. I think I saw him, at least, at one point. I don't know if he wants to say something.

Alex Forshtat: Yeah, hi, everyone. Thank you very much for, the interest, and yeah, I would, love to cooperate with Ethrex on the demo, like, thought, about it for… quite some time, and, yeah, it's, it's a very strong primitive to be able to provide, the, like, negative, assertions, like, and negative conditions for… per transaction, it plays very well with frame transaction, doesn't necessarily require frame transaction as an opcode. You can… done in… In parallel, yeah, I guess that's it, I, If anyone has any questions, I'd also be happy to answer.

Marc Garreau: Thank you both. Tomas has a hand up.

Tomás Arjovsky: Hey, no, just a quick clarification from the Ethrex team. Aside from the demo, we have also implemented a small DevNet. It's running on one server, so it's nothing to prove on low tests or high scale, but if you want to try, give some RPC requests to some running nodes, we already have them. We can send you the links if you want. And there's also a faucet, and there's a couple of contracts for a Paymaster example, and a gas sponsor example that can be used to test, how frame transactions work. So yeah, let us know if that's something that you'd be interested in testing.

Marc Garreau: Excellent, thank you. So I see we've got plenty of follow-up questions in chat. I think that's a good thing. I will acknowledge we will not be able to go down each of those rabbit holes here. We've got about 20 minutes remaining in the call, so I'll suggest we move to the the next section, which is… there are many more rabbit holes here as well. We're definitely not going to be able to get very deep into any of them, but hopefully we can make enough progress to identify For example, next steps, or whatever open questions exist that need to get answering… are answered before we can move forward. So, next section is compatibility discussions, or these are just a series of considerations. I've heard the most noise about people wanting the most clarity, or asking for the most clarity about

For any of these given, proposals. there's… at the risk of, choosing the wrong thing to focus on first, I'm… gonna take the order that exists there. The first one is adoption strategy, so… quick context is, this is one of the categories of concern for any Native AAA proposal I've heard, is essentially how do we ensure adoption reaches critical mass in a timely manner? There's a lot to dig in here, like how opinionated are patterns within the proposal, how much work and risk is there for wallets or app developers. Would anybody like to… to… Try to describe the state of… of… of how you're thinking about your proposal and Rolling it out effectively to the world, or what questions you have that maybe some others on this call can help answer.

David's got a hand up.

david: Yeah, it's David from Trust Wallet. Actually, some of the arguments that I have been, seeing regarding, like, 8141 was The low adoption of 7702. And I think, like, from a wallet developer perspective, it actually does take a lot of effort, too. have, like, some of these fundamental level shifts as a wallet. Like, we need to audit our SPAR contract, like, and then, like, our front-end layer, how we have, like, the bundler, paymaster, or, like, the relayer systems. So, from a wallet perspective, having these types of updates actually do take a bit of time. However, if we have a look into the data today, there is, like, nearly, like, 100 million weekly 7702 transactions, actually not there, but close to. And trustwall also have been seeing, like, meaningful traffic, leveraging these.

And also a lot of wallets, use these techniques to somehow make it more automated. So, I believe that it will be somehow in line with a one-for-one. Like, in my personal opinion, it wouldn't be, like, extremely drastic as soon as things get merged. But wallets actually look into the opportunities of how we can, like, really automate or make wallets smarter, and then they work on these, and then by the time they're, like, confident enough through multiple rounds of security audits and development, it actually gradually gets rolled out to the users. So, from that perspective, having these foundations, I actually, believe will be a big plus. And ultimately, like, a way that, like, the consumer wallets potentially would be willing to go.

But there will need to be a bit of time buffer, because there needs to be a lot of preparation for those. And also, one of the reasons why I think this 8141, this needs to be merged, or potentially something that could do these merged in a timely manner, is because, like, wallets also are transitioning from more of a passive helper. into a more automated solution at an ecosystem level. And then if we actually do not have some things to support these. at the protocol level, each wallet or each solutions will come up with their own ways, like, basically their own private, really, networks to just automate their wallet experience. And actually having something like a 8141 will…

create a more, on-chain, verifiable way of how wallets actually end up building your automation solutions. So, yeah, those are just my two cents as a wallet developer.

Marc Garreau: Thanks, David. Carlos, is this, maybe I'm confused by your question in chat. Is this related to adoption concerns?

CPerezz: No, not adoption.

Marc Garreau: Okay, if it were stateless or mempool, or… Something else, those… those we can tackle next? Thanks, Dirt.

Derek Chiang: Oh, yeah, sorry, I just wanted to speak, kind of like… I just wanted to comment on what David said. You know, I think, really, really, really truly agree with what David said. I mean, honestly, TrustWallet's obviously one of the top adopters of AA, right? You know, they adopted 7702-4337, you know, so I trust their experience a lot. You know, so I think, like, our experience at Zero Dev has been very similar in that, the three core adoption… sort of, like, roadblocks to AA, in my opinion, are, one, you have to audit smart contracts, right? Two, you have to rely on relayers, right? You know, like, if you want to take advantage of the gas abstraction features. And the third one is that smart accounts do not work as reliably across chains

as EOAs do, right? So I think, like, David mentioned point 1 and 2, and I just want to emphasize 3 as well, right? And so that's why, like, for firm transactions, we're actually trying really hard to adjust all three core adoption barriers. So for, the need to audit smart accounts. We are solving this in two ways. So one is that firm transaction just natively supports EOAs. Like, EOAs just work. You don't have to, like, order new smart contracts for it to work, right? Like, EOAs will be treated as if they have… are running a default smart accounts. Which is obviously, you know, guaranteed by the protocol in terms of security. And, you know, so even EOAs can start doing things like batching, you know, getting guests sponsored, paying guests in yes-20 tokens and whatnot, right?

So that, so this one. The second way we are addressing this, which, you know, we are still working on, is basically defining a set of, what we call, canonical verifiers. So these are basically smart contracts, like, very minimal smart contracts, that wrap existing precompiliers, such as, you know, EC Recover and P256 Verify. So these are essentially smart contracts you can use. you can compose with your smart accounts to, to leverage new signature algorithms, right? You know, so, so again, you know, we hope that we can take away the burden of auditing the most obvious, sort of, like, authentication path. from the wallet developers, right? And then on the second point of, relayers, you know, NativeA, of course, solves that problem, because with NativeA, you don't need relayers, you know, that's kind of, like, the whole point.

And then on the third point of. compatibility across chains. That's actually, like, the trickiest part that's, we are trying to solve right now, because, again, you know. from talking to L2s today, including base, Arbitrum, and whatnot, there are definitely, like, some concerns over, kind of like, with native AA, how they can achieve predictable performance and cost when it comes to validating transactions. So, yeah, you know, so I think that's, to me, like, the largest outstanding unknown here, you know, which is basically, like, whether we can convince, all the L2s, at least all the leading L2s, to support some kind of native AA, right? You know, so I think that's the… yeah, that's my view on, you know, on this topic.

Marc Garreau: Thanks. Follow-up question, is there… What is progress on those discussions already? Has that begun?

Derek Chiang: You mean the discussions with, L2s?

Marc Garreau: Yes.

Derek Chiang: Yes, yes, we are actually… you know, group chat with, base and Arbitrum. Obviously, if there's OP folks in here, please join as well. And yeah, you know, so I would say the discussion's ongoing, you know, but I wouldn't say that any consensus has been reached, but I don't know if Chris wants to speak from his perspective.

Chris Hunter: Yeah, I wouldn't say consensus has been reached, I think, yeah, things are still in flux in development and whatnot.

Marc Garreau: Okay, are there any clear next steps that can be spelled out here?

Derek Chiang: I think, from my perspective, yeah, just, like, keep working towards the consensus, with the L tools, seeing if there's, like, we can get firms to a specs where they feel very comfortable supporting. That's what I'm hoping we can get to, you know.

Marc Garreau: Okay. Keeping an eye on the clock. There's only 12 minutes here left, so we are definitely not making it all the way through. Are there any of these other, bullet points that can be tackled quickly, whether it be the current state of thinking on mempool implications, statelessness, compatibility, or privacy? Ben, go for it.

Ben Adams: Yeah, so I have a concern of any transaction type that needs to In fact, the EVM, in terms of… First… If it's pushing the cost… the base cost of a transaction up to, you know, 10 times what it normally is. Then… that might not be practical. And also, if, If they all have to be run in the mempool, that again is a problem, so… Essentially, the mempool is going to be processing you know, like… A hundred times the number… the amount of gas that would go in a block. It seems like now we're… we're in a situation where we wanna… we wanna put more transactions through the block, but we're… Forcing the validators into, spending all their, all their CPU on, processing transactions that aren't paying for anything.

And so that's some of my concerns.

Marc Garreau: Before we go to Carlos, would anybody like to quickly respond to Ben's point?

Ben Adams: I mean, it… To… to be very specific, if… if… all the transactions now cost 10X on their… on their base, then we've, like, drop the… What can be included in that quite significantly, also.

Lightclient (Matt Garnett): I guess I don't really understand fully the issue here.

Ben Adams: If you're validating signatures in the, in the… In the block and mempool. Using EVM instructions.

Lightclient (Matt Garnett): Right, but why is this such an issue? Like, we already expend compute. It's just a different type of compute to validate the transaction.

Ben Adams: Is that the evening.

Lightclient (Matt Garnett): Apparently inefficient about these things?

Ben Adams: Well, because the… at the moment, we use the EC Recover precompile. Which is… If you write EC Recover in EVM bike code, it is significantly more expensive. Brazile.

Lightclient (Matt Garnett): Oh, well, we're not proposing people do that, though. Like, people will use the precompiles for… Most of their cryptographic needs, and it's just a matter of some… You know, interpreter functions to push and pop data to get in the correct form to submit to the cryptographic precompile.

Ben Adams: Okay, so then you'd have to introduce… The signing schemes as, that's pre-compiled. Is that correct?

Lightclient (Matt Garnett): I mean, did we ever say that we would not be? Introducing… Designing schemes discrete precompiles?

Ben Adams: I think so from that document, Jared, it's like the walk-away test, it could be automatically upgraded without Or devastating anything. So that would… imply that… Oh, we've got a new… quantum signature we want to do, so we'll… someday can write a contract that verifies that… for that. Will be a massive expense.

Vitalik Buterin: Yeah, so, like, one example is that any, hash-based signature algorithm, like, that definitely can be done without any precompiles, because the, like, the acceleration that matters is, already done in the existing hash precompile, right? And, you know, there is overhead in the sense of needing to, like, take a hash output and put it back into a hash input, but if you, like, kind of do the EVM math, it's, like, less than, like, 1.3x or something, right? I guess, like, two other big categories of examples of this that count. One of them is that, you know, with this, possible vectorization precompile, you will, be able to do, handle a large volume of, different lattice-based schemes that have different, different nuances and, different parameters, and there again, basically, yeah, what's going on is that the expensive object is being wrapped in a precompile, but, not the, sort of…

customizable glue around it. And then probably a third example is, like, even if you do have a precomp… like, even if we do have to have a precompile for each individual algorithm, like, that's… still better than, having it be a, an account type, and, one of the big reasons why is because it's composable, right? Because, like, if it's in the form of a precompile, you can combine it together in a multisig, you can combine different schemes, you can have hierarchical multisigs, you can, mix and match things in whatever… in whatever format, that you want. So I would say, like, those are the… Big… big situa… Situations in which it's, an in… like, there's an actual improvement available over having, like, types for each individual thing you want to do.

Marc Garreau: In the interest of time, we've got 5 minutes left here, I'll suggest we have… Carlos, Tomas, and Presswich. Carlos, you've been waiting patiently, so the floor's yours.

CPerezz: Thank you. I'll try to be quick. So, we have discussed a lot, like. AA, and the flavors of AA, and the different ideas, and all that stuff, but I think that's another big discussion, which, I mean, I'm not sure to which extent wallets and LTOS want to actually give input, or really have any interest, I don't know, whatever, but certainly, we are putting a lot of effort in on other areas of the protocol, like, having CK validation and statelessness and stuff like that. And we have already seen that this is quite conflicting, depending on the flavor and the strategy that we go for in frames. So, at the beginning, Frames was set to go for Strategy 2, which, that basically translates into you only can have sponsorships of ETH,

but not ERC20s. But seeing what wallets and Ltos say they want, it's clear that this is not gonna be enough. So that basically only gives two options. One is we force every single node to hold all ERC20s. Or the other one is we have a whitelist of VRC20s, which to me sounds crazy, but whatever. I mean, it can be done, of course. And… I'm not sure if there's any kind of preference or idea, or wallets care about that or not, but that's certainly, from a protocol perspective, having this whitelist, although I don't like it, would be for sure the best trade-off. Because otherwise, what we're saying is, every single node is gonna be forced to hold mostly two-thirds of the state already.

So once EKBM or any sort of statelessness lands, and people drop the state, that's gonna be a huge requirement, and therefore, we will lose a lot of member pool health, if not all of it. So, my question to the authors, is basically, what kind of strategy are we going for? Because it clearly seems that we are not going strat 2. And if… what's the approach gonna look like? Meaning, are we going for everything that wallets ask for, and then cutting down, based on how crazy or hard, or the consequences on other parts of the protocol we observe, or are we going minimal to start, and then adding features as long as we agree on the trade-offs? Like, what is the approach, and how do we discuss that with wallets and stakeholders? Because it's not clear to me at all.

Marc Garreau: Thanks, Carlos. Tomas.

Tomás Arjovsky: Hey, so a couple of things. I mostly wanted to answer a couple of comments by both Ben and Carlos. So, Ben mentioned a couple of minutes ago the problem with precompiles. I don't think that the frame transactions idea is inherently against precompiles. I think that it just opens the way to either use them or not, and in the future, you can just add a new precompile if you really require it, and that wouldn't be an issue, because you just don't need to have a new transaction type for that. That on the one hand, and if you don't, then it's even more seamless. Regarding Carlos, I won't be able to answer the part regarding statelessness. I think that's an interesting topic of discussion, but regarding the strategies, I'm not familiar with the numbers of the strategies.

But I think that you can have a ERC20 sponsorship without necessarily having that either centralized or pre-whitelisted. I think that we can have different paymasters, and paymasters can have their own list of supported ERC20s. And if you have something like that, you don't have to have anything protocol level, but you still can have some level of control by each of the paymasters, on what are the ERC20s that they trust. So I think that that is something that In itself could be in the direction to solve this issue.

Marc Garreau: Great. Press switch, and then I'll close this out.

James Prestwich: So, through the call, we've talked about a bundle of features that Frame should provide. transaction batching, ERC20 paymasters, gas abstraction, etc, post-quantum. But it seems like a lot of those are… unfinished. Like, we've been talking about, just now, ideation on how to handle ERC20s safely. So, that feedback frame provides, we're not confident it provides it yet. And in chat, we've been talking about post-quantum. Frames don't provide that. We need follow-on EIPs for precompiles for specific signature schemes, we need follow-on EIPs for what ECE Recover does. afterwards… You know, frames don't provide some of the things that they are supposed to provide… yet.

Do we want to do this if we're still in ideation on a lot of the benefits?

Marc Garreau: Nico. And then we're… we're done here.

Nicolas Consigny: Yeah, on the… Post quantum stuff, I think the question… are, like, the two options are basically hash-based or lattice. Hash-based, we don't need to pre-compile, and Lattice, we will probably find a way to have the generic precompile that Vitalik described. So, like, this part is done. EC DSA deactivation and EC recover is kind of independent from Frame. Like, if you take this in any scenario, we would have to do it. So yeah, the only remaining question, I feel, is the stateless part, and I think it's, Like, probably something that… Can be where, like… Defined in the next few weeks? And we have almost, 3 quarters until we actually ship this. So, yeah, I think it's kind of fine.

But yeah, the post-quantum stuff, and the ACDSA deactivation, and… AC recovery modification, I feel like, yeah, it's… it's… Either independent or, done anyway.

Marc Garreau: Okay, thank you, everybody, for, for coming, participating. And, going deep in the chat. Hopefully this is… helpful for at least illuminating what important next questions need answering. And, I'll work to get this up on Forkcast, but I encourage others to, don't wait for for that to happen before, figuring out next steps for yourselves. We don't have a date for the next one yet, but we'll announce, if and when we do. So, Until then. Catch you in the usual channels. Thanks for coming, everyone.

Lightclient (Matt Garnett): Thanks, Mark.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.