DAPPCON 2025: Kill The Private Key: Road to Full AA from 7702

Transcript

[Applause] Thank you everyone for joining and thank you to the panelists for coming here. I'm going to I'm going to do a short round of introductions to keep the introductions short like I'm Richard. I'm one of the co-founders of safe but more importantly we have Kristoff who is one of the founders of Pimico here. We have draw um from EF who is part of one of the authors from 4337 heavily involved in most of the standardizations around account abstraction and serum. and Franchesco from Metam Mask and yeah I think the exciting part for me here is we have a nice distribution between the stacks we have Kristoff more on the dep Frances more on the wallet side and then on the protocol side draw from the F

right so why did I do the intros because actually the first question that I want to ask to all of you as like introduction warm-up round why is account abstraction and or 7702 so important for you why does it play a role in your day today left and we stay with Metamas. Yeah, I'm double miked. I don't know something is not working but uh yeah I mean I'm leading developer relation at consens so the mother company metam mask is one of the product super excited also about linear the zkvm but let's let's go back to the question um I think like obviously we need more uh US component we need to actually like facing the reality that this world is not just about uh protocol developers but is also about dabs developers so we

want to actually build environments CLIs that actually allowing dubs developer to build a good front ends and good onboarding for the users. So I'm uh definitely very excited about uh I think one of the the first big uh wave of innovation around uh getting better kind of like usability and I think 772 is definitely like pioneer this and uh bringing a lot of like new kind of functionality obviously now is is all about transaction but we see already dabs that care about UX adopting it. So I think it's uh super exciting and we're evolving in the right direction.

Erh 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 it 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 protocol there is usability features 4 through7 for account obstruction and 7702 as a way to add some most of those features even to plain EOA accounts.

Your original question was you know why are smart accounts why they account abstraction important and then Simmons note too the most concise way I've sort of practiced of of explaining this is that um before smart accounts you basically had a choice of do you care about um self- sovereignty do you care about owning your private keys completely or do you care about user experience right if you care about self- sovereignty you save your private key somewhere you save your seed phrase and you have to guard that and obviously uh you know unlock it every time and go through all trouble. If you want the actual user experience, you go to a centralized exchange. With smart accounts, you get both the self-s sovereignty and the usability together.

With 772, this is important even more because um this EIP in a practical sense um makes it very easy for existing wallet users to upgrade um 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 uh 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, right? Like we started 4337. I mean it's has been a while when it was since we started this and even 772. Why everybody says it's a 15inut things from Vitilik, 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? Right? Like it's so important. Everybody is excited. Why doesn't it move faster? Like because the the Boston is not on the onchain level. Um these onchain things whether you're using a you know what smart account are you using? Is it using this specific protocol change or not um that was like obviously that needs to be solved but um the real difficulty getting people to adopt smart account is uh more on the tooling level side of things. So for instance um I want to drop in uh an EIP which which I think we'll we'll be talking a bit more about here as well which is this EIP called um 5792 right this this is this has EIP at the start but it's actually uh more of a standard it's more like kind of like an ERCish um

and this um defines a new way um of allowing DAPs to communicate their intent of what they want the wall to do um and this is something that's been really missing. So before for instance DAPs had no way of asking walls to do a batched transaction unless they controlled the wallet itself. They had no way of suggesting um really um in a very standardized way that they wanted to use a uh sponsorship mechanism to actually pay for the gas of the user. Um there was obviously ways like you know safe came up uh with ways of like embedding the app into like the safe UI to do this to some extent but there was no widespread way. Um so I would say uh 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 772 account uh because no matter what functional functionality it had there was no real way of the DAP being able to use that to benefit the user. Okay. I think contrary the problem was account obstruction was something that Ethereum wanted from the beginning from the early start. Vitalics simply had to publish something before it could get it done and there was several EIPs try 86 I believe and 3074 the problem is that all of them had serious security problems there was denial of service vectors the reason we 3074 was not because all the good things it did it did a lot of things actually

everything that eventually was done with 772 the problem with 3074 was it it caused a it opened a denial of service attack on network block builders could not protect themselves. They could be easily attacked. Not easily, okay? But they could be attacked like a massive N of service on the network. This is the reason we had to compromise until we have to try until we found something until Vitali came 7702 which is it can be used for denial of service but they are can be mitigated with 3074 you can't mitigate these issues. Yes, you do need an interface and RPC call like 5792 and yes the work on that

accelerated when uh 467 7702 were on the way there was no need for this RPC call before there was a 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 uh prevent them. But I mean there were smart accounts before 447 even before uh there was like smart account no safe it's not an account when I say an account an account is something that onchain doesn't depend on any external entity like a relayer to submit its transaction.

It can is the sponsor itself. It can delegate its payment to another entity but it is not required to and 4337 that because it's not a core protocol uh is not really doing you might say that bundle is a kind of a relayer but bundler are uh built in a way that they can be in a mele just like nodes. So in that sense it is decentralized protocol and you 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 relayer to submit your transaction later it upgraded it itself. Now it is an account

once you add decentralized module like 437 on top of seven I don't know if it supports. 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 protocol like 437. Richard, I think like it reminds me now the builder night in Tokyo that we had about the spiciness. It's it's an interesting one. I mean there's 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 is it complicated? we saw from I mean we see dep protocol side from the wallet side why why only now why not earlier I think

like also there are um it's quite I mean it's quite complicated because there are also different stakeholders in the game right um I think also like we don't want to kind of upgrade to smart account without uh you know kind of like forcing uh behaviors and kind of like needs for for users I think the two things uh and we touch on a little bit like uh you know do we need private keys we kind of like I mean that's the title right killing private keys I think like those two things are not kind of like mutual exclusive right we want to make sure that we are not forcing people to just upgrade their their smart account but is the same time uh making sure that people are availability of like new interesting features um and I think like you see

already kind of like the apps adopting or or getting kind of like later in the game uh but is it's just very interesting to see because when I see also there are different stakeholder there are a lot People also criticize a bit like uh things about kind of like delegation rights to do things. There is more entry point to actually like uh to to been hacked. I mean it's also like interesting and also there are new debates. I don't know like I'm not deep into kind of like this sub accounts kind of things. I just saw like the Pedro speaking about now the third kind of like behav accounts. I'm not sure about like flexibility and if it's fitting about this this panel narrative but uh yeah I think al yeah I think yeah we're we are

getting there but in the same time there is a lot of like different debates and a lot of stakeholder and we want to make sure we're shipping something that is kind of like reliable and is not forcing consumer um decision right yeah you're actually mentioning an interesting topic where it's like we see change coming from this right like and I mean You talk to a lot of teams when it comes to Pimnico that wants to build on top of let it be 437 but probably also 7702. Do you already see different questions coming from the developers that have deps or integrated wallets or is it still all the same or do you have they already embraced 77 mode 2 and see this as a better way towards full account abstraction? um

some of my time nowadays uh is actually going towards um debunking this a quite common misconception I would say that 7 similar 2 is somehow competing with 447 right um so so 72 just to clarify it turns your existing account u and gives it smart account features 447 is a standard um for smart accounts that lets them plug into a very diverse widespread ecosystem of relayers and uh pay masters and gas sponsored modules. So, um I' I've had people asking like, "Oh, should I use 447 or 1702?" I mean, very likely in most cases, the answer is uh you can just use both if you really want to, right? Uh

one of the main benefits that I've seen from this whole wave of 72 adoption and you know, Petra going live is just this renewed meme um of smart accounts per perpetuating, right? So we've seen this when 447 was taking off where um yes people were integrating the actual standard itself but even more people were just really excited about the the value of smart accounts. We were seeing a lot more projects um say like hackathon projects building with it. We're seeing lots more people sponsor gas regardless of it was 437 or not. I'm seeing the same thing with this right with 772 where people are adopting the necessary standards that actually I think are are limiting um smart accounts adoption right now like 5792 as opposed

to you know more people turn their accounts into 772 but no we've seen we've seen adoption in we're starting to see adoption in the DAP space I would say so obviously most recent I think has been unis swap who's who's now enabled um 5792 which which is again the prerequisite to um them being able to get the features from these new 772 accounts I think um relay has also enabled it, matcha has enabled it, revokec and a couple other ones have enabled it. Obviously there's a lot more to go, right? So this is just like tip of the iceberg. Um but I it seems like it might be enough to actually you know trigger a larger cascade and actually uh pressure everyone else to to get going with it too. Yeah, definitely can see this also.

So I mean it's one of the things that at safe we fought for a long time more probably less successful where it's like how can we get deps to really embrace the advantage of smart accounts and here really 7702 seems to be a little bit of a tipping point which is nice to see. You mentioned the synergies between 437 and 772 and here I want to come back to also your point draw because when it came to 3074 and even 77 when I joined all core dev calls that seemed like a fight sometimes I can remember there was the fight I with everything he said about the synergy between I agree the fight was not against it the fight was a

like we never fought neither 7702 We we we fought 3074 not because of 4337 because by itself it was insecure for the network. It was impossible to secure a block builder with 772. It is possible. We never argued against it and they are not fighting each other. H 7702 taken EOA addits a lot of the features of abstraction. It has an account. It has batching. It supports gas limit. It can support pass 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 multisig even safe or whatever on top of your EOA, there will always be a single key of a multisig that can do whatever it likes in the you cannot lock resources. You can you can block it on the different chains. It will always work whether there is a 772 installation on that or not. So it is a an amazing feature wise it gives you all the usability features but the security features up to some extent you can have recover of your pass keys or whatever but there is always this EO behind the scene so for new accounts we recommend

use an SCA a normal account don't 7702 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 uh always recover your account but it also mean that anyone who gets access to your private key can recover and take over your account. You cannot get away with that. Yeah. On metamask side I mean also there for me lots of questions how metam mask will use 7702. Maybe starting out with will mam mask use 772 to support 4337.

So I I mean we are kind of supporting already on on snap side right there are different kind of features and uh I also want to mention I'm super grateful for like you know like devs when they can start like revoking accesses you know big shout out to to exactly those dabs right like revoke cash even unis swap now uh there is a lot of like different teams um also like I want to mention the fact that um for user specific right people obviously want to kind of like have their ownership but in the same time supercharge like with different function and there are different needs that we're already seeing it right like we already shipping like kind of stuff like obviously best transaction but also like revoke accesses uh fine graining delegation is something that is asked more and more right creating like light

light wallets for actually like you know family and friends um so yeah I think like uh 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 full control of what they're doing. But in the same time, you have also like obviously new user um and uh different user kind of like needs around uh new kind of like supercharge features. Uh but even like gasless transaction, you know, was something that we were not able to do that before and I think it's it's great to accomplish that and I think the space is also moving forward uh on uh on that direction. I mean I'm excited about embedded wallets in

general. I know it's another kind of like topic but the fact that now we have web3 o in in our family there is a lot of like kind of like journey that we are able to satisfy that is not just about delegating rights to do things but it's the entire onboarding journey right doing like SSO login or social login is a big things for on boarding kind of like new new user in the space you mentioned I do agree but like a lot of features that um that are super interesting that 772 brings coming back to my little bit provocative question you for the relaying feature, will you rather use some I mean there's a I know some products inside the consensus family that can do relaying, right? Like will you fall back to these or do you um fall back to 437 when it comes to the

sponsors transaction and so on or do you not know yet? So I'm uh I mean one things I can say is that for example Ryan and the team around delegation toolkit is doing an amazing job. There are also like you know um there is a lot of discussion around enabling 437 specific kind of like like um features through snaps. A lot of also like dabs are actually like coming with this request. Um but I think like fine grain 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. Um yeah so there is a lot of work being done on uh on the dedication

toolkit side. Okay. What do you think in a time frame wise where you say now every metam mask account is actually delegated and uses advanced features? Do you say this is a foreseeable future in crypto terms please not in traditional? Yeah know I mean this is a good question right? Uh and it's going back on the on the titles. Um I don't think like we want to force people uh and I think it was mentioned before right we want to force people upgrading their accounts. I think we want to make sure that people has still full control on their access but also like being kind of like uh supercharge of this this feature right so there is no kind of like forcing I think it will it will come on kind of

like on a time I don't know how how long it will take uh but also like we're looking how we can um leverage like the election toolkit for uh for for for metamas specific right not just providing uh the framework and I think the same path that happens with snap we will start seeing also like uh native integration and and native adoption, right? Like the Solana snap has been around for a long time before we were shipping the the Solana native integration, right? A couple of weeks ago. Maybe also a similar question towards you and um actually to get everybody to upgrade to a 772 account, we would need that to be available across all the chains. And I know that Pimico obviously

interacts with a couple 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 support them because at this point most of the chains that we that we see interact with um use one of like a couple chain stacks. So, so we've seen for instance, I think the first two chains, mainet chains that u I saw adopt 1702 were B and uh Binance Smart Chain and Nosis chain. Um next obviously was Ethereum mainet and then quite soon after I uh we saw the superchain ecosystem, the optimism superchain ecosystem adopted. So obviously you know

Bass Inc. Optimism um Zora um and a lot more of those chains. And actually just today um I just saw the announcement for arbitum upgrading to petra as well. Right. So I think like um with these chain stacks out of the way and actually like adopting 72 um it there's not really much else. Right. Assuming I assume there's going to be like a long tail that's going to take a a little um while but at the end of the day we've got I think the majority of of sort of TBL in Ethereum already adopting it. So we're perfectly set up. 77 two adoption will come on its own or anything where you say I mean we we have I don't want to call I think there's some chains which have like are still uh in the London hard fork that we support at

Pimico and I think there's some even before London right so ones which don't support like uh EIP559 which is like uh I don't know how long that ago that was right so I imagine there's definitely going to be you know ones where you can't you can't just rely on se live on all chains um but at this point it's like a good assumption to make for most. Yes. What can we do to convince them to upgrade? Um probably talk to their core developers and help them upgrade, help them change the the node software, right? usually uh when it comes to these issues um it's because they they say like you know many years ago they did a a fork of of GU or or or some other sort of core um core software and they have been having trouble basically

maintaining it and they don't want to like cause a big disruption but and get a lot of engineering months spent on like making these changes so I'd say any support there for them uh might be quite significant. We have talked a lot about adoption half time more or less right like I want to talk a little bit 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 we want to get people to use more account abstraction features more smart features when it when we look at the protocol level what has to happen next draw like uh in term of 7702 or something else I in terms of account right like we say that 7702 and also 437

before it but if you look at the protocol level 7702 was the first real change on a protocol level that is attributed towards account abstraction right like 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 the next EIP is a native account obstruction 7701 uh that we are now pushing uh uh it still has some work to be done there and the structure and security which is basically taking uh all the features you can get from 4337 and add them at the network level. Uh so it reduced the gas uh 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 same like if you create an application on top of uh 77 sorry on top of a 437 whether it is 7702 or not switching to a 7701 yes it will require of course contract upgrade that that's all all feature wise it should be equivalent. I was actually no not I'm not the moderator here but I I was going to ask a question about that which is I remember um a big cell for 7701 was that it was going to be built on top of EOF right and and now it seems like obvious I'm not sure how it's not

completely decided I guess but like EUF the the future for EUF doesn't seem super bright. No, no, no. It's now irrelevant. It's now unrelated. We built it on top of EF because EF looked like this the future. We built it now on top of uh without EF directly. So technically it requires us to add one more op code than when we thought to do it. It's built a bit differently at the uh EVM level, but functionality is just the same. So how is that uh how is that different then from the old um native account abstraction proposal? because I I remember there was one quite a while ago which was then replaced by 771 because of the eof uh possibilities there. Uh we're getting technicalities.

We we did have one that is based on APIs that requires dependency on solidity interfaces but this is something that core devs frownet because they don't want to enshrine any APIs which is called 7560. Erh so we understand it is a good way to start. We started it like for L2s not for L1's but uh and and still it's working. We are working with some teams to support it. But the future for L1 is is not in that direction. So uh 7701 was the way to take the account model we defined with 437 like separation of the validation and execution. Validation can

be constrained in uh several features in order to be able to support meles and decentralization. Uh account support validation and separately execution. So we need to add op codes in order to do uh that uh like have a validation function and then after that you know you can pay for the transaction. So it it cannot be so so we had to define this function it cannot be a method. So this is one we do to it define it using op code again we're getting very very deep I'm not sure that yeah and we don't have to go to all the details in term of low-level technical feature there are people who think that the next thing for 7702 is like

set a permanent code upgrade because 7702 right now is always controlled by an EOA and it can always change its implementation or switch back into an EO if it likes and there are people who want to do this a full upgrade of an account uh like an EO8 to stop being an EO8 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 permit that you created offchain. It will create problem with different chains. So believe that 772 is great feature for people with EUA to get some of the uh 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 SCA. Just also to write context, I mean I hope everybody here has full smart SCA refers to smart contract account, right? Like so um but also maybe forwarding this question a little bit, right? Like how should we upgrade and there is a lot of discussion, right? Like should it be a permanent upgrade with or should it be should we just migrate everybody using theoretically we can use 7702 to batch migrate everybody to a new sea account? Does MetaMask has like a vision? Yeah, I I think like I kind of like mentioned before I think like we will never force any uh anyone on MetaMask to upgrade or force upgrade. you will have all this option to remain as a as kind of like UA

functionality and uh and if people want to kind of like you know uh benefit on on top of some of the transaction I think those are two known mutually exclusive kind of like uh perspective I think multiple people will have probably like different accounts upgraded or not with different kind of like use case and uh we see already around uh kind of like risk portfolio management right like people are going uh with different kind of like use and behavior on different kind of like needs. But I obviously like I'm a big fan of uh I would love to have you know stuff like a counter recovery.

I want to definitely best transaction when I'm playing like a web three kind of like game. Uh I want to definitely dedicate action uh to to people to do specific things especially in in governance or kind of like specific voting rights. Uh I think like we definitely need to go in this direction and I think um yeah that's the only way to go if you want to kind of have a minimal uh behavioral product if you're even considering uh how web two is behave around the apps today right even best transaction is something that is kind of like always been natural but the fact that we're coming here now is also showing that there is a lot of like um you know energy for for new uh features and that's why also like the I'm excited

about all the embedded wallet kind of use case right the only the fact that we don't provide still um a uh you know SSO login or social login for like newcomers in the space uh is still hard to understand right and I'm excited right now that we can propose uh that with with the web3 solution and on the DEP side the entire kind of like SDK suite yeah maybe related question because you said there are different use cases that we can go for and theoretically or that you want to optimize for and um theoretically to optimize for different use cases we could say we have different contracts that we delegate for. I saw I think I talked with Kristoff earlier today that like oh unis swap is bringing

their own delegator account or and then a brings their own delegator account and um in my talk earlier I was asked do I think users are smart enough um to understand where they should delegate to right like which is the best account to delegate to which I personally answered like you know we should have the paradigm users are stupid sorry to say for this um how do you see this at 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 up delegate to this account because this will give you the perfect user experience when you intact with our deb. I think we need to be super transparent on what the upgrading

means and what functionality you will gain from it. uh but I think you will have option to do that right and I think you want to have option actually to to going back to to be anyway or at least like having uh having possibility to but forcing I don't think is the solution a lot of people believe you know self-costity is extremely important and you also don't want to open up kind of like attack vector um and you know there is still a lot of debate the fact that we're here on a panel debating this is also like giving us a lot of like insights that you know not everyone is kind of like ready to delegate find permissions uh because of like different uh different uh kind of like yeah question and and even like security uh I'm not deep into that but I also

like wonder if you guys see um ATF or in general even at safe like you know like the the fact that people are opening up delegating account uh is opening up new account uh vectors uh it's also like something that I don't know it also scares me a little bit Right. Because as you say users uh have also like you know different needs. Yeah. Yes. Um I think if we go deep into the technical discussions the our last five minutes would not be enough for this. Um so actually maybe related to this and speaking of personal experience like the 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 it also first myself like are you using 772 and I'm I'm a smart account maxi so actually I don't use 7702 because I have a smart account I all of my accounts are saved and the only thing where I use EOAS is to sign for safe I don't need 7702 for this besides this dev test account also they have 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 how about you do you did you upgrade your personal EAS to 7702 I again I'm similar to you where I already have the vast vast majority of my funds on smart accounts now there's different different tiers of smart accounts there's the ones which I treat more as like you know um like you know easy to use spending

accounts where it's just secured by POS key one where it's like a more of a multi-IG which obviously then I I want to be uh store more funds there. Uh but I don't really use EO EOAS that much dayto-day. So no I have not either. What about you? Just the same a user doesn't use 772. It's a internal feature that the wallet will use for the user. when application requires requests a batch the wallet needs to use 772 delegate to do it again I don't use much EUAS so I don't use 772 when I did try it to see that it works but again I don't I don't use if if I don't have any

EOA that I want to upgrade into a smart account I have no use for EO the the question it's a very low very lowlevel question users don't see the low-level feature. It's not it's not even the Intel inside. You know, they use MetaMask and MetaMask will support batching features because now you have a better UIX with a unis swap uh one click uh swap without approve. That's a feature that the wallet and the framework and the application together did for the user. It doesn't see the 772. It shouldn't. Yeah, I'm I'm relating a lot, Chris, like have also like different smart accounts. I think my challenge a little bit is that you start also like losing control of how many also like uh smart accounts you have because like also like

different is always different apps and doing different things. So that's the only kind of like things also like track starting to track starts kind of like becoming like challenges. Cool. Um I mean that kind of concludes my questions. We have three more minutes. Um first of all thank you very much for all the panelists. Uh 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 account abstraction um where we should push depths to adopt um the ERPs and what also how to utilize existing tech in the wallets like um snaps but also you know use m like you can try out 772 and metam mask but like it's fun. We

have couple more minutes maybe for one or two questions if there are some. We have five minutes for questions. Actually five minutes. Nice. Hey um I have a question. So um I think previously in discussion of this full upgrade there was this idea of um having native account obstruction on rollups before fully introducing it uh to layer 1. So my question would be um how do you see the current development in this? Is this still something that we as a system would like to try out to maybe a battle test or is will it also be the same as 772? First the um packra update upgrade comes to the mainet and then everybody

has this feature afterwards. You are the best draw right like basically it's a question about the status of native account obstruction rollups. As I said native account obstruction doesn't give you extra features and even the security it gives you guys benefits and it give you some security features that are mostly irrelevant on L2s. So uh uh 437 gives you everything and if you need if you want to upgrade from normal accounts you use 7702 for that. As I said they work together uh just the same. Erh, we continue to push RP 7560 but we we switch more more the effort to to

try to push 7701 because yes, it will benefit to have the same account type on all networks. So, and it will go to L1, but it's it doesn't add any new features above 437. Okay, gas saving but it's not feature wise there's no there's no extra features for us to add. So the work right now on native account obstruction is mostly on the L1 771. Hello guys. Uh, sorry to go back into native account abraction stuff, but I was just thinking is are you working on

that being like postquantum compatible already because obviously there's issues with signers in the future going boom. So is that something we could use to make Ethereum postquantum? One of the reason to add a native account abstraction was to support postquantum. But not only postquantum, any signatures type you like. Like many people use pass keys. They're not postquantum but usability wise they're much easier to use than normal the room accounts. So we're not pushing all the user to postquantum but they will be able to upgrade their account. Every user will be able to upgrade its account to whatever smart account it likes. It can be postquantum 437 by itself has problem with that

because the it's an ERC and the bundard themselves requires an EOA. So it's not postquantum native can be because there is no inherent EOA in the system but again it's not by itself postquantum it's postquantum ready. Yes I think also to be postquantum ready as to 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 postquantum security. Um and actually again also as draw said the a smart account in itself is not postquantum secure but it gives you the flexibility to introduce something that is post quantum secure. Um I think in one minute theoretically the next talk starts.