# Kill The Private Key: Road to Full AA from 7702

- Channel: [Dappcon](https://streameth.org/dappcon)
- Date: 2025-06-19
- Duration: 38:47
- Watch: https://streameth.org/watch/6853eb1d90bd41297ba90cc7

## Description

with  Francesco Andreoli, Kristof Gazso, Richard Meissner and Hsiao-Wei Wang

## Transcript

Thank you everyone for joining and thank you to the panelists for coming here. I'm going to do a short round of introductions to keep the introductions short. I'm Richard. I'm one of the co-founders of SAFE, but more importantly, we have Christoph, who is one of the founders of Pimlico here. We have Dror from EF, who is part of one of the authors from 4327, heavily involved in both of the standardizations around account abstraction and the theorem, Francesco from Metamask, and yeah, I think the exciting part for me here is we have a nice distribution between the facts. We have Christoph more on the deb side, Francesco more on the wallet side, and then on the protocol side, Dror from EF, right? So why did I do the intros? Because actually the first question that I want to ask to all of you is, like the introduction warm-up round, why is account abstraction and or 7702 important for you? Why does it play a role in your day-to-day life? And we start with Metamask. I'm Double Mike. I don't know if something's not working, but yeah, I mean, I'm leading developer relation at Consistency, so the mother company. Metamask is one of the products, super excited also about Linear, the ZKVM. But let's go back to the question. I think like obviously we need more US components. We need to actually like facing the reality that this world is not just about protocol developers, but it's also about dApp developers. So we want to actually build an environment, CLIs, actually allowing dApp developers to build good front-ends and good onboarding for the users. So I'm definitely very excited about, I think, one of the first big wave of innovation around getting better kind of like usability. And I think 7702 is definitely like a pioneer of this and bringing a lot of like new kind of functionality. Obviously now it's all about best transaction, but we see already dApps that care about UX adopting it. So I think it's super exciting and we're evolving in the right direction. Okay. Actually, I don't have much to add except that, yes, it is a usability feature. What we are looking is how to do it at the protocol level to keep the system decentralized of course, everything you can do with a centralized service. So we try to make sure to add into the core protocols, the usability features, 437 for account abstraction and 7702 is a way to add some, most of those features even to plain UA accounts. Your original question was, you know, why are smart accounts, why is account abstraction important? And then 7702. The most concise way I've practiced of explaining this is that before smart accounts, you basically had a choice of, do you care about self-sovereignty? Do you care about owning your private key completely or do you care about user experience? Right? If you care about self-sovereignty, you save your private key somewhere, you save your key phrase and you have to guard that and obviously, you know, unlock it every time and go through all that trouble. If you want the actual user experience, you go to a centralized exchange. With smart accounts, you get both the self-sovereignty and the usability together. With 7702, this is important even more because this EIP in a practical sense, makes it very easy for existing wallet users to upgrade, to get a lot of the functionality, the user experience benefits of smart accounts, which is not possible before. So this is how I would sort of do it in a concise way, yeah. So if it's so important and if we are so excited about it, why does it take so long? Like we started 4.3.3.7, I mean, it has been a while since we started this and even 7702, why everybody says it's a 15-minute thing from Vitalik, right? Like it actually was 3074 before that took, I think, four years to really come to a point. Why does it take so long? Why is it so important? Everybody is excited. Why doesn't it move faster? Because the bottleneck is not on the on-chain level. These on-chain things, whether you're using a, you know, what kind of account you're using, is it using this specific critical change or not? That was like, obviously that needs to be solved, but the real difficulty getting people to adopt smart accounts is more on the tooling level side of things. So for instance, I want to drop in an EIP, which I think we'll be talking a bit more about here as well, which is this EIP called 5792, right? This has EIP at the start, but it's actually more of a standard. It's more like kind of like an ERC-ish. And this defines a new way of allowing dApps to communicate their intent of what they want the wall to do. And this is something that's been really missing. So before, for instance, dApps had no way of asking walls to do a batch transaction unless they controlled the wall itself. There's no way of suggesting really, in a very standardized way, that they wanted to use a sponsorship mechanism to actually pay for the gas of the user. There was obviously ways like, you know, Safe came up with ways of like embedding the app into like the Safe UI to do this to some extent, but there was no widespread way. So I would say without that, it doesn't matter if your user's account is a smart account or not, if it's a 3074 account or a 7702 account, because no matter what functionality it had, there was no real way of the dApps being able to use that to benefit the user. Okay. I think, on the contrary, the problem was, account abstraction was something that Ethereum wanted from the beginning. From the early start, Vitalik simply had to publish something before he could get it done. And there were several EIPs, try 86, I believe, and 7074. The problem is that all of them had serious security problems. There was denial-of-service vectors. The reason we opposed 3074 was not because of all the good things it did. It did a lot of things, actually, everything that eventually was done with 7702. The problem with 3074 was it caused, it opened a denial-of-service attack on the network. Block builders could not protect themselves. They could be easily attacked. Not easily, okay, but they could be attacked, like a massive denial-of-service on the network. This is the reason we had to compromise, we had to try until we found something, until Vitalik came with 7702, which is, it can be used for denial-of-service, but the app can be mitigated. With 3074, you can't mitigate these issues. Yes, you do need an interface, an RPC call, like 5792, and yes, the work on that accelerated when 4357 and 7702 were on the way, there was no need for this RPC call before there was an infrastructure to handle it. So, yes, it was completely required, and it was good it was done, but the reason it took so many years was denial-of-service attacks. It took us time to hash out all the issues, how to prevent them. But, I mean, there were smart accounts before 4357 even, before, there was, like, RPCs. Smart accounts, no. Safe. It's not an account. When I say an account, an account is something that, on-chain, doesn't depend on any external entity, like a relayer, to submit its transaction. It is a sponsor itself, it can delegate its payment to another entity, but it is not required to. And 4357, because it's not a core protocol, it's not really doing, you might say that Bungler is a kind of a relayer, but Bungler are built in a way that they can be in a mempool, just like nodes. So in that sense, it is a decentralized protocol and not locked to a specific server. Any other protocol, like Safe, Safe had a relay for a very long time, but it is not an account in that you do need an account with GAS to pay for your, or a relayer, to submit your transaction. Later it upgraded it, now it is an account once you add a decentralized module, like 4357. So 7702, by the way, by itself, is not a new account. The account is EOA. If you want to delegate the payment to another mechanism, you need a protocol like 4357. Richard, I think you remind me now of the Gilder Night in Tokyo that we had about the spiciness. It is an interesting one, and there is a lot of topics, and I think we can see how we define accounts, how different it is. Still coming back to the original, why is it complicated? I mean, this is an indicator why it is complicated. We saw from the dev side, even protocol side, from the wallet side. Why only now? Why not earlier? I think it is quite complicated because there are also different stakeholders in the game, right? I think also we don't want to upgrade to smart accounts without forcing behaviors and needs for users. I think the two things, and we touched on it a bit, like do we need private keys? I mean, that is the title, right? Killing private keys. I think those two things are not mutual exclusive, right? We want to make sure that we are not forcing people to just upgrade their smart account, but at the same time, making sure that people have the ability of new, interesting features. I think you see already dApps adopting or getting later in the game, but it is just very interesting to see because when I see all the different stakeholders, there are a lot of people who also criticize things about delegation rights to do things. There is more entry point to be hacked. It is also interesting. Also, there are new debates. I don't know. I am not deep into these sub-accounts kind of things. I just saw Pedro speaking about now the behavior around that we should actually go with a third option, sub-accounts. I am not sure about flexibility and if it is fitting about this panel narrative. I think we are getting there, but at the same time, there is a lot of different debates and a lot of stakeholders. We want to make sure we are shipping something that is kind of reliable and is not forcing customer decision rights. You are actually mentioning an interesting topic where we see change coming from this. You talk to a lot of teams when it comes to Simlico that wants to build on top of, let it be 4.3.7, but probably also 7.7.2. Do you already see different questions coming from the developers that have dApps or integrated wallets or is it still all the same? Have they already embraced 7.7.2 and see this as a better way towards full account abstraction? Some of my time nowadays is actually going towards debunking this quite common misconception I would say that 7.7.2 is somehow competing with 4.3.7. So 7.7.2, just to clarify, it turns your existing account and gives it smart account features. 4.3.7 is a standard for smart accounts that lets them plug into a very diverse, widespread ecosystem of relayers and paymasters and gas monitoring modules. I have had people ask me, should I use 4.3.7 or 7.7.2? Very likely, in most cases, the answer is you can just use both if you really want to. One of the main benefits that I've seen from this whole wave of 7.7.2 adoption and the texture going live is just this renewed meme of smart accounts perpetuating. We've seen this when 4.3.7 was taken off where, yes, people were integrating the actual standard itself, but even more, people were just really excited about the value of smart accounts. We were seeing a lot more projects, say, like hackathon projects building with it. We were seeing a lot more people sponsor gas, regardless if it was 4.3.7 or not. I'm seeing the same thing with this, with 7.7.2, where people are adopting the necessary standards that actually, I think, are limiting smart account adoption right now, like 5.7.9.2, as opposed to more people turning their accounts into 7.7.2. We've seen adoption in that space, I would say. Obviously, most recent, I think, has been Uniswap, who's now enabled 5.7.9.2, which is, again, the prerequisite to them being able to get the features from these new 7.7.2 accounts. I think Relay has also enabled it. Marsha has enabled it. Overbook.cache and a couple of other ones have enabled it. Obviously, there's a lot more to go. This is just the tip of the iceberg. But it seems like it might be enough to actually trigger a larger cascade and actually pressure everyone else to get going with it, too. Yeah, definitely can see this. Also, I mean, it's one of the things that I'd say if we fought for a long time, probably less successful ways, like how can we get devs to really embrace the advantage of smart accounts and see a really 7.7.2. It seems to be a little bit of a tipping point, which is nice to see. You mentioned the synergies between 4.37 and 7.7.2, and here I want to come back to also your point, Dror, because when it came to 3.7.4 and even 7.7.2, when I joined all core dev calls, that seemed like a fight sometimes. I can remember last... No, there was a fight. Everything he said about the synergy between them, I agree. The fight was not against it. The fight was... We never fought, neither 7.7.2, we fought 3.7.4 not because of 4.37, because by itself it was insecure for the network. It was impossible to secure a block builder. With 7.7.2, it is possible. We never argued against it. And they are not fighting each other. 7.7.2 taken EOA added a lot of the features of account abstraction. It has an account, it has batching, it supports gas limit, it can support fast keys and session keys, and many, many features. But it will always stay an EOA behind the scenes. There will always be a master signature that can work, which means you cannot increase the security of your EOA. Like if you put a multi-sig, even a safe or whatever, on top of your EOA, there will always be a single key of a multi-sig that can do whatever it likes. You cannot lock resources. You can block it on a different chain. But it will always work, whether there is a 7.7.2 installation on that or not. So it is an amazing feature-wise. It gives you all the usability features, but the security features up to some extent. You can have the cover of your pass keys or whatever, but there is always this EOA behind the scenes. So for new accounts, we recommend use an SCA. A normal account, 7.7.2 will give you a slightly cheaper installation of a new account. That's also true. But after that initial installation, it is an account with an EOA in the background, which is a good thing. You can keep it and always recover your account, but it also means that anyone who gets access to your private key can recover and take over your account. You cannot get away with that. On Metamask side, I mean, also there, for me, lots of questions how Metamask will use 7.7.2. Maybe starting out with, will Metamask use 7.7.2 to support 4.3.7? I mean, we are kind of supporting already on Snap side, right? There are different kind of features. And I also want to mention, I'm super grateful for like, you know, like devs when they can start like revoking accesses, you know, BigShelter to exactly those apps, right? Like RevokeCache, even Uniswap now. There is a lot of like different teams. I also want to mention the fact that for user specific, right, people obviously want to kind of like add their ownership, but in the same time supercharge like with different function. And there are different needs that we're already seeing, right? Like we're already shipping that kind of stuff. Like obviously best transaction, but also like revoke accesses. Fine graining delegation is something that is asked more and more, right? Creating like light wallet for actually like, you know, family and friends. So, yeah, I think like we are definitely on the way, but in the same time is a bit kind of like a careful situation. We want to kind of like have both of the words kind of like satisfied because people want to have full control of what they're doing. But in the same time, you have also like obviously new user and different user kind of like needs around new kind of like supercharger features. But even like gaslight transaction, you know, was something that we were not able to do that before. And I think it's great to accomplish that. And I think the space is also moving forward on that direction. I mean, I'm always excited about embedded wallets in general. I know it's another kind of like topic, but the fact that now we have Web3Auth in our family, there is a lot of like kind of like a journey that we are able to satisfy. This is not just about delegating rights to do things, but it's the entire onboarding journey, right? Doing like SSO logins or social login is a big thing for onboarding kind of like new user in the space. You mentioned, I do agree, but like a lot of features that are super interesting and that everyone wants to bring. Coming back to my little bit provocative question, for the relaying feature, will you rather use that? I mean, I know some products inside the consensus family that can do relaying, right? Will you fall back to these, or do you fall back to 4.3.7 when it comes to the sponsor transaction and so on? Or do you not know yet? So, I mean, one thing I can say is that, for example, Ryan and the team around Delegation Toolkit is doing an amazing job. They are also like, you know, there is a lot of discussion around enabling the 4.3.7 specific kind of like features through snaps. A lot of also like dApps are actually like coming with these requests. But I think like fine-grained permission is definitely one feature that is asked and is something that we care about. The question is also like we are also reviewing how we can position Delegation Toolkit that is much more accessible for people to understand. Yeah, so there is a lot of work being done on the Delegation Toolkit side. Okay. What do you think, in a timeframe-wise, where you say now every MetaMask account is actually delegated and uses advanced features? Do you say this is a foreseeable future in crypto terms, please? Yeah, I mean, this is a good question, right? And it's going back on the titles. I don't think like we want to force people, and I think it was mentioned before, right? We don't want to force people upgrading their accounts. I think we want to make sure that people have still full control on their access, but also like being kind of like supercharged of this feature, right? So there is no kind of like forcing. I think it will come on kind of like on a time. I don't know how long it will take, but also like we are looking how we can leverage like Delegation Toolkit for MetaMask specific, right? Not just providing the framework. And I think the same path that happens with Snap, we will start seeing also like native integration and native adoption, right? Like the Solana Snap has been around for a long time before we were shipping the Solana native integration, right? A couple of weeks ago. Maybe also a similar question towards you. Actually, to get everybody to upgrade to a 7702 account, we would need that to be available across all the chains. And I know that Pimlico obviously interacts with a couple of chains to provide bundlers. Do you have any estimate how, like when will there be 7702 on all chains? I mean, I think the most important thing to look at for this is to see which chain stacks actually supports them. Because at this point, most of the chains that we see and interact with use one of like a couple chain stacks. So we've seen, for instance, I think the first two chains, the main net chains that I saw adopt 7702 were Binance Smart Chain and Gnosis Chain. Next obviously was Ethereum Mainnet. And then quite soon after, we saw the Superchain ecosystem, the Optimism Superchain ecosystem adopted. So obviously, you know, Base, Inc., Optimism, Zora, and a lot more of those chains. And actually just today, I just saw the announcement for Arbitrum upgrading to Pectra as well, right? So I think like with these chain stacks out of the way and actually like adopting 7702, there's not really much else, right? I'm assuming it's going to be like a long tail that's going to take a little while, but at the end of the day, we've got I think the majority of the TBL in Ethereum already adopting it. So we're perfectly set up, 7702 adoption will come on its own or anything, would you say? I think there's some chains which are still in the London hard fork that we support at Temlico. And I think there's some even before London, right? So ones which don't support like EIP-1559, which is like, I don't know how long ago that was, right? So I imagine there's definitely going to be, you know, ones where you can't just rely on 7702 being live on all chains. But at this point, it's like a good assumption to make for most. Yes. What can we do to convince them to upgrade? Probably talk to their core developers and help them upgrade, help them change the node software, right? Usually when it comes to these issues, it's because they say like, you know, many years ago, they did a fork of Geth or some other core software, and they have been having trouble basically maintaining it. And they don't want to like cause a big disruption and get a lot of engineering months spent on like making these changes. So I would say any support there for them might be quite significant. We've talked a lot about adoption, half time, more or less, right? Like, I want to talk a little bit about when we say it's about the future, right? Like, where do we go next? And I think 7702 is already a good step. It's in the right direction. We want to get people to use more account abstraction features, more smart features. When we look at the protocol level, what has to happen next? In terms of 7702 or something else? I mean, in terms of account abstraction, right? Like we say that 7702 and also 437 before, but if we look at the protocol level, 7702 was the first real change on a protocol level that is attributed towards account abstraction, right? So 437 was more ERC level, so more application level. So what is next? What is the next EIP that we need to push? The next EIP is a native account abstraction, 7701, that we are now pushing. It still has some work to be done there. The structure and security, which is basically taking all the features you can get from 437 and add them at the network level. So it reduces the gas consumption because 437 has its gas consumption on top of a native transaction, and it had some security features that it adds, but usability-wise, it's the Like, if you create an application on top of a 437, whether it is 7702 or not, switching to a 7701, yes, it will require a contract upgrade, but that's all. Feature-wise, it should be equivalent. I'm not the moderator here, but I was going to ask a question about that, which is, I remember a big sell for 7701 was that it was going to be built on top of EOS, right? And now, it seems like, I'm not sure how, it's not completely decided, I guess, but like, the future for EOS doesn't seem super bright. No, no, no. It's not irrelevant. It's unrelated. We built it on top of EOS because EOS looked like the future. We built it now on top of, without EOS, directly. So technically, it requires us to add one more opcode than when we thought to do it. It's a bit differently at the EVM level, but functionality-wise, it's just a thing. So how is that different then from the old native kind of trashing proposal? Because I remember there was one quite a while ago, which was then replaced by a 7701 because of the EOS possibilities there. We're getting technicalities. We did have one that is based on the ADI that requires dependency on solid interfaces, but this is something that the core devs found out because they don't want to enshrine any ABIs, which is called 7560. So we understand it is a good way to start. We started it in RIP, like for L2s, not for L1s. And still, it's working. We are working with some teams to support it. But the future for L1 is not in that direction. So 7701 was the way to take the account model we defined with 4.27, like separation, validation, and execution. Validation can be constrained in several features in order to be able to support mempools and decentralization. Account supports validation and separately execution. So we need to add opcodes in order to do that, like the validation function. And then after that, you can pay for the transaction. So we had to define this function. It cannot be a method sig. So this is one we defined using opcodes. Again, we're getting very deep. I'm not sure that we need to go that deep. Yeah, we don't have to go to all of them. In terms of low-level technical features, there are people who think that the next thing for Because 7702 right now is always controlled by an EOA, and it can always change its implementation or switch back into an EOA if it likes. And there are people who want to do this full upgrade of an account, like an EOA to stop being an EOA and start to be an SEA. We believe this is a bad thing to do. It will not increase your security. You are left behind with a lot of permits that you created off-chain. It will create problems with different chains. So we believe that 7702 is a great feature for people with EOA to get some of the SEA functionalities. But if you really want security and if you want the adoption of the next billion people, they should not start with an EOA. They should start with an SEA. Just to provide context, I mean, I hope everybody here has a full smart account. SEA refers to smart contract account, right? But also, maybe forwarding this question a little bit, right? Like, how should we upgrade? There is a lot of discussion, right? Like, should it be a permanent upgrade or should we just migrate everybody? Theoretically, we can use 7702 to batch migrate everybody to a new SEA account. Does MetaMask have a vision? Yeah. I think, like I kind of mentioned before, I think we will never force anyone on MetaMask to upgrade or force upgrades. You will have always option to remain as kind of like EOA functionality. And if people want to kind of like benefit on top of some of the transaction, I think those are two known mutually exclusive kind of like perspective. I think multiple people will have probably like different accounts, upgraded or not, with different kind of like use case. And we see already around kind of like risk portfolio management, right? Like people are going with different kind of like use case and behavior on different kind of like needs. But I obviously like I'm a big fan of I would love to have, you know, stuff like account recovery. I want to definitely best transaction when I'm playing like a kind of like game. I want to definitely delegate action to people to do specific things, especially in governance or kind of like specific voting rights. I think like we definitely need to go in this direction. And I think, yeah, that's the only way to go if you want to kind of have a minimal behavioral product. If you're even considering how Web2 is behaved around the app today, right? Even best transaction is something that is kind of like always be natural. But the fact that we're coming here now is also showing that there is a lot of like energy for new features. And that's why I'm excited about all the embedded wallet kind of use case, right? Only the fact that we don't provide still a, you know, SSO login or social logins for like newcomers in the space. It's still hard to understand, right? And I'm excited right now that we can propose that with the Web 3.0 solution. And on the dev side, the entire kind of like SDK suite. Yeah. Many related questions because you said there are different use cases that we can go for and theoretically or that you want to optimize for. And theoretically, to optimize for different use cases, we could say we have different contracts that we delegate for. I think I talked with Christoph earlier today that it's like, oh, Uniswap is bringing their own delegator account. And then Aave brings their own delegator account. And in my talk earlier, I was asked, do I think users are smart enough to understand where they should delegate to, right? Like, which is the best account to get it to, which I personally answered like, you know, we should have the paradigm. Users are stupid. Sorry to say this. How do you see this as Metamask? Will there be a time where the users can completely freely choose which account to upgrade to or where even the dev could say, hey, delegate to this account because this would give you the perfect user experience when you integrate with our dev? I think we need to be super transparent on what the upgrading means and what functionality you will gain from it. But I think you will have options to do that. Right. And I think you want to have option actually to going back to be any way or at least like having possibility to. But forcing, I don't think is the solution. A lot of people believe, you know, self custody is extremely important. And you also don't want to open up kind of like attack vector. And, you know, there is still a lot of debate. The fact that we're here on the panel debating this is also like giving us a lot of like insight that, you know, not everyone is kind of like ready to delegate, find permissions because of like different kind of like, yeah, question. And even like security. I'm not deep into that, but I also like wonder if you guys see ETF or in general, even a safe like, you know, like the fact that people are opening up delegating accounts is opening up new account vectors. It's also like something that I don't know. It scares me a little bit. Because, as you say, users have all different needs. Yeah. Yes. I think if you go deep into the technical discussions, our last five minutes would not be enough for this. So actually, maybe related to this and speaking of personal experience, like that, I'm interested also like who uses 7702. And that's why my last question to all of you will be, and I will answer also first myself, like, are you using 7702? And I'm a smart account maxi. So actually, I don't use 7702 because I have a smart account. All of my accounts are safe. And the only thing where I use EOS is to sign for a safe. I don't need 7702 for this. Besides, it's a test account. Also, there are very little 7702. So that's why I personally don't see myself using 7702. I'm a smart account maxi. But how about you? Did you upgrade your personal EOAs to 7702? I'm similar to you where I already have the vast majority of my funds on smart accounts. Now, there's different tiers of smart accounts. There's the ones which I treat more as like easy to use spending accounts where it's just secured by POSKEY. One where it's like more of a multi-sig, which obviously I want to store more funds there. But I don't really use EOAs that much day to day. So no, I have none either. What about you? Just the same. A user doesn't use 7702. It's an internal feature that the wallet will use for the user. When applications request a batch, the wallet needs to use a 7702 delegate to do it. Again, I don't use much EOAs. So I don't use the 7702. I did try it to see that it works. But again, if I don't have an EOA that I want to upgrade into a smart account, I have no use for EOAs. The question, it's a very low-level question. Users don't see the low-level features. It's not even the internal side. They use MetaMask. And MetaMask will support batching features because now you have a better UX with Uniswap. One-click swap without a proof. That's a feature that the wallet and the framework and the application together did for the user. It doesn't use the 7702. It shouldn't. I'm relating a lot. Chris also has different smart accounts. I think my challenge is that you start losing control of how many smart accounts you have. Because you're always using different apps and doing different things. So that's the only kind of thing. Starting to track starts becoming challenges. Cool. I mean, that kind of concludes my questions. We have three more minutes. First of all, thank you very much for all the panelists. It was very nice to have the full overview from the low-level stack and also getting some glimpse where we should push for native counterfeiting, where we should push depth to adopt the ERPs and also how to utilize existing tech in the wallet, like Snap, but also Generate. You can try out 7702 and MetaMask. It's fun. We have a couple more minutes, maybe for one or two questions, if there are some. We have five minutes for questions, actually. Five minutes. Nice. Hey, I have a question. So I think previously in discussion of this full upgrade, there was this idea of having native account abstraction on Rollups before fully introducing it to Layer 1. So my question would be, how do you see the current development in this? Is this still something that we as an ecosystem would like to try out, maybe a battle test? Or will it also be the same as 7702? The first sector upgrade comes to the mainnet, and then everybody has this feature afterwards. You are the best pro, right? Basically, it's a question about the status of native account abstraction on Rollups. As I said, native account abstraction doesn't give you extra features. And even the security, it gives you guard benefits, and it gives you some security features that are mostly irrelevant on L2s. So 4377 gives you everything. And if you want to upgrade from normal accounts, you use 7702 for that. As I said, they work together just the same. We continue to push RFP 7560, but we see more of an effort to try to push 7701, because yes, it will benefit to have the same account type on all networks. And it will go to L1. But it doesn't add any new features above 4377. Okay, guide saving. Feature-wise, there's no extra features for us to add. So the work right now on native account abstraction is mostly on L1, on 7701. Hello, guys. Sorry to go back into native account abstraction stuff. But I was just thinking, are you working on that being post-quantum compatible already? Because obviously there's issues with signers in the future going boom. So is that something we could use to make Ethereum post-quantum? One of the reasons to add native account abstraction was to support post-quantum. But not only post-quantum, any signature type you like. Many people use PATKI. They're not post-quantum, but usability-wise, they're much easier to use than a normal Ethereum account. So we're not pushing all the users to post-quantum, but they will be able to upgrade their account. Every user will be able to upgrade its account to whatever smart account he likes. It can be post-quantum. 4377 by itself has a problem with that, because it's an ERC, and the bundle themselves requires an EOA, so it's not post-quantum. Native can be, because there is no inherent EOA in the system. But again, it's not by itself post-quantum, it's post-quantum ready. Yes, I think also to be post-quantum ready, as Thor said, it's important that we actually have to kill the private key, because the private key being ECDSA-based is the weak link in post-quantum security. And actually, again, also as Thor said, a smart account in itself is not post-quantum secure, but it gives you the flexibility to introduce something that is post-quantum secure. I think in one minute, theoretically, the next talk starts,