L2 Interop Working Group #6

Transcript

cool all right let's get started welcome to the L2 interop working group call um drop the agenda in the chat for anyone watching the recording it is issue 1404 in the PM repo uh cool I think we can just uh jump right into things then first off we have Luca from the reown team with the walkthrough of 7811 hey everyone I'm going to share my scen just give one sec uh cool um okay folks so like before we

go through the demo I wanted to spend a bit of time um talking about why like we're going to talk about 78 11 um but like why did we create in first place um so what is 7811 currently um DS when they interact with wallets they get the assets on their own so they query the accounts on chain State um usually by RPC or some like provider that Aggregates all the data um that's how they determine the account State um this is working well until you introduce stuff like chain abstraction um which then starts to introduce problems um why specifically the that doesn't know what

the wallet can do right so the dab thinks okay um I might have access or the account has like one usdc but the wallet knows okay but I can swap the assets I can breach the assets um I might get like 10 usdc right which is not reflective on the accounts on chain state so the 7811 introduces wallet get assets which is a simple RPC um that gives the ability for wallets to declare which assets are supported by the account not necessarily which assets are on the accounts like on chain State why is this important again um short demo like this is not the demo this is like why it's important I'm connected on um C swop I know we have folks from pretty

much every D5 project in the call so no hard feeling so I chose this one um I have 1.5 usdc right um so this is letting me swap if I change to two it's going to say insufficient usdc balance even though um I the wallet might know how to resolve this right um so but it the issue is the DAP is not letting me even click this because it wants to preserve the ux um so what we did is we have this wallet here which supports chain abstraction um this is our chain obstruction solution which went live um quite a bit time ago but yesterday we published a paper as well

on how exactly are we doing this so I have 3.37 um usdc on Optimum and I'm going to switch to something like carbit um here which has um basically no usdc which is great um then I'm going to copy my account address here and I'm going to go send usdc um it has available balance here of 3.4 which is the aggregate balance of my other chain again like this is not my arbitrum balance if I go to my wallet here which just displays the balance on this chain it has 03 but the wallet knows it could get the usdc from different chains so if I do this and if I do this and I go send

usdc um keep in mind this is still in progress so that's why the the latency is a bit iffy um the wallet actually gets the request again on the target chain which is arbitrum um and is actually simulating the request trying to parse okay um this request as like whatever sending usdc do I have this USD uh no um do I have some other token if yes I can swap it and then complete the request if I don't have the token on the Chain um I have to bridge and then swap which is what it's doing here for my optimism balance and then if I approve it's not swapping it's just bridging um if I approve here um it's going to bridge first and then it's

going to complete the initial intent submitted by the daap which again is important because when we Design This our chain obstruction solution we put put it in the wallet um and it's completed um successfully again on the that side and yeah we put our chain abstraction solution in the wallet instead of the dab um but still the dab has to request something and our premise was always minimal changes dab side so the dab only declares what it wants to do on the target chain not how and the wallet figures out how uh which may be via I don't know again like swap Bridge 7683 magic span whichever other solution doesn't really matter and the 7811 gives

the ability for wallet to declare um okay if I know you I have this assets if you send a request that spends this asset um it's going to be completed um so the dab can still preserve the nice ux so we don't have um this thingy here um so yeah I think that's it from the demo perspective I have no idea if we have time for questions Josh or um do you want to handle that async or yeah yeah we can maybe do a minute or two of questions if anyone has any cool I guess one question for you really quick Luka are there any asks of anyone this in this group or just interrupt more broadly what what are yeah what are the

things would be most helpful to you okay so um I know some of the folks here have been on the uh interop off side in Denmar I was in the what it called um the user Journey mapping group and we discussed exactly this um so our vision here is to make 78 11 kind of like a counterpart to 7683 so 7683 which is going to be resolved by the wallets wallet side and the DBS kind of need to know that it the request can be resolved so they need something like 78 11 there are other like Alternatives like um observ funds in 5792 but they based on what we talked about like with the dabs they really do

not like kind of disabling this checks which would basically be kind of enforced by exil fonts got it cool well that the number uh 7811 I'm going to drop it in the chat as well awesome and Luka you are in the telegram group I believe so if anyone has questions for you they can they can find you track you down there exactly yeah I'm going to share also the we have another um group um for 7811 specifically if it's cool with everybody i' would like to share the

link so you know folks enjoy sounds great thanks thanks Luka up next Chris for the uh want to share a few things on the zoo Berlin interrup event yeah my screen as well give me one second can you see my screen perfect perfect cool yeah so in June we'll have subin again and um it has been quite a shelling point in the ecosystem last year in terms of research and actual practical progress for example for um pre-confirmation who

launched their first death net there and this time we have a huge focus on L2 interoperability so we're working together there with Ellie from espresso with Luca from L2 be um and with ar rest from T1 protocol but also including a lot of um of course the big l2s in the ecosystem Bridges across hyperlane wallets and Inter protocols such as Lea and polymer um and topics will be yeah across the board the topics we're discussing in here but the big difference will be of course we come together in person we'll have two full days and then also the rest of su Berlin to discuss we will co-create the agenda together ahead ahead of time we'll create telegram group and this just an invite because we want to spread as much as possible across the ecosystem and

really have all of you represented there um so if you want to join DM either me on telegram as Chris HG I'll also share a message and a bit of info there or Ellie or Luca and love as as many as of as many as possible of you to join there and make it really really um yeah practical Workshop oriented and have some good results there together so yeah excited for that that's it from my side and yeah if you have any questions I'll post it on telegram as well and you can also DM me there awesome thank you Chris cool we can keep going then uh

next up resource loxs I mean I don't have anything prepared per se I don't know if anyone else here wanted yeah oh cool hi so let me see if I can showare video it is okay so yeah the goal is just to kick off a bit of a conversation in this group around um around resource

locks um I think that there's been a lot of productive conversation around standardization of intents and uh Josh sort of asked me to to jump in and start talking about resource locks and I think it'll be important to have sort of this group as orchestration of the conversation around this you know part of the motivation is we're seeing more teams experiment with uh with this mechanism and you know primary goal is just having common language and then secondary is sort of work towards any sort of uh Collective action whether it is standardization or pushing free IPS or you know whatever else that that makes sense so I just have a quick walk through here of sort of high level topic of resource locks and a few uh open

questions at the end so to set the context so I'm Stefan um I'm founder at one balance uh previously uh was co-founder at flash Bots and have been sort of thinking about the role of meev in ux for for a bit of time and that led me down the solver based stuff and uh ultimately resource locks so um I founded one balance along with my co-founders to sort of based on the thesis that resource locks are the best short-term solution for cross chain ux and what we've built is a toolkit for champ structed apps um and then we're also helping various different teams that are Building interop Solutions uh to support them with the

implementation of of resource locks within their system um I think resource locks have been around sort of as a topic now for for about a year U but there's still a bit of sort of confusion around what they are and how they're perhaps distinct than intense um and so I think primary thing is sort of explore uh a definition of of what is their role um and I think this sort of perspective is probably the best way that I found to to explain it um Josh can you give me a thumbs up to make sure you see my screen awesome so everyone knows sort of the classical Bridge which is you deposit on an escrow on the source chain

you wait for finality then the bridge admin sort of notices that finality and then they mint the assets on a destination chain or they pass a message to the destination chain that gets included and then the user can do stuff on the destination chain you know the critical path there everyone knows Source chain finality plus destination chain inclusion is sort of too slow and like the source of all the fragmentation problem that we're looking to solve in this group in 10 Bridge you know the Innovation is you can actually get the solver to eat the finality risk and front some Capital through their inventory on destination chain and so the way that these intent bridges are sort of implemented today you still send a transaction on the source chain you wait for the usion but not the finality

and then the solver goes and fronts the capital on the destination chain and then you have a settlement mechanism off the critical path um and so your new critical path is Source chain inclusion routing and destination chain inclusion which significant ux Improvement already um and then this is where you know further Improvement upon this comes comes resource locks and so um just called it fast intent bridging but you can have a lock provider resource lock provider remove the double spend and finality risk completely as opposed to just shifting it to uh to the solver and that allows things like higher capacity on the solver side um easier spreading to other chains Etc um and it also

reduces a critical path to be just lock verification routing and destination chain inclusion where the first two things sort of occur offchain and uh and you only have the destination chain inclusion which is which is onchain now what's involved as part of resource lock is essentially to just say that your escrow step which you have as a first step to the intent bridge is happening ahead of time um and the user can do that deposit and and spend it multiple different times um and so uh you have the verification and the the routing and then the destination chain inclusion um before you can receive the assets and then the rest of the flow is sort of

exactly the same as you would you would do inside of the traditional sort of intent Bridge uh design um so that's the justification of like why resource locks and uh and and why a lot of folks are are getting more and more excited about it now there's different types of resource lock and sort of the design space I'd say over the course of the past six months has been increasingly explored um where you could sort of categorize into two two families the first one is account based locks which uh you are sort of creating locks on all the assets that sit inside of uh uh the user account um and then the second one is escrow based locks so

you have a separate smart contract that you deposit into and uh and you you sequence the locks uh within that um that account and then of you know the escro based lock Solutions I think two are are sort of worth mentioning which I think would would be recognized by by a few people so there's the Compact and Magic spent Plus+ that I would sort of consider to be implementations of escrow based locks um the important part is sort of the locking mechanism that's used is is independent to the rest of the settlement mechanism right so they are both sort of just covering the top piece here of this the sequence diagram and then the rest is all the traditional

intent flow so so long as these solver networks Implement uh compatibility for resource locks then it's um it's sort of Happy Days and you get the ux benefit across across the the ecosystem um so this begs you know the question of like what are challenges with with resource locks that have been identified and thank you to the people that sort of participated in the in the chat on telegram um I just pulled those from there but uh but the two main ones that sort of been talked about the first is that 7702 doesn't support SCA based uh locking um and so unfortunately the current implementation of 7702 uh allow ows the eoa to uh revoke a delegation at any time and so the EA

retains sort of root control over the um the account which means that you can't Implement some kind of policies on the account that limit the the revocation um but uh you know it would be possible to implement an EIP that uh that does a different type of Delegation than 7702 perhaps extends it such that allows uh policies such as time lock or uh or multi uh as part of the revocation of the delegation the sort of second issue that's been discussed is sort of a failure of or limitation of 1271 uh signature verification which is a standard for verifying um

authorizations as part of smart contract account implementations um and the issue is that uh 1271 doesn't have any sort of semantics around how it can be uh a signature can be revoked and so as part of the flow a solver May believe that they hold a valid uh a valid authentication but it gets revoked as part of the execution um and so the solution space is essentially to to push the authentication outside of the smart contract accounts into um directly into the the escrow um as part of of escr loocks um and uh and also sort of some some implications around um around uh erc20 permits and uh and how they're

supported as part of uh of account locks um so those are sort of problems are being actively talked about and and sort of looking for for mitigation um and I think you know the question that's relevant for the discussion here is what should this group do about um about resource locks I think the first one is to make sure that whatever intent standard and settlement stand standards are develop are resource lock aware and I'm going to give a bit of a hat tip to to Kevin here for the message that you posted because I think it it really summarized well what is the role of an intent standard and what is the role of a settlement standard um and how we can make sure that all the

solutions that we build are remain interoperable with um with each other uh so intent standard allows user to express a list of settlement vendors whose attestations they accept the actual semantics of the content and a list of commitments resource lock vendors they're willing to lock their funds sellman standard verifies the sment protocol conforms with the users expressed intent on locking user funds the commitment resource lock vendor is one of the vendors that the user supports um likely defined by a front end this ve vendor is expected toit events to notify the solvers and then on releasing user fund the sellman vendor is one of the vendors that user allows and uh that the stations can be verified so I think this sort of provides a very

good high level sort of objective statement for what these these standards Can U can do and avoid sort of the overlap in in um in trying to put too much inside of standard or too much inside of a settlement standard as well as provide the context of of where resource locks fit um fit into the picture another thing that this group can do is to work on a draft of an EIP for a 7702 extension that uh that has more advanced delegation rules we had put together a proposal last summer around this and sort of a code reset op code um and so I can show that I think it's been showed in in the group already um but that could be an additional path that that we

explore as a group um and otherwise I think you know up for discussion if there's anything else that you guys think is worth uh worth discussion or uh working together on uh it would be great to to get your input so yeah uh any thoughts this is great thanks Devon um on the topic of smart contract accounts and 7702 having uh equivocation issues I do think that a standard would be awesome to to refresh 7702 and make it equivocation compatible

in the interim we should really work to build out good canonical off registry the plan with the compact version one of the compact right now is to introduce this notion of an emissary where you can assign an account specific to a family of resource locks that has the ability to speak on your behalf basically can uh if you if your signature isn't your ecdsa Sig isn't valid or your 1271 signature isn't valid then it'll go ask the Emissary and provide a call back and that Emissary um ideally should be a

Singleton uh canonical off registry where there's a time lock on updating your um updating your signer and then we can do pass keys and um smart contract based wallets and that kind of thing so um that is at least where we're sort of thinking right now um but ideally we come up with something that is uh useful to whoever is trying to make these uh these off based systems that are resistant to equivocation issues yeah it'll be interesting to see

how much it makes sense for this to be a standalone um registry versus be embedded as part of each uh Vault solution yeah I feel like there's going to be enough Variety in signature schemes and and use cases there that you could Envision you know someone's doing BLS if someone's doing pass keys with secp 4 or 256 R1 if if you're doing a multi- style there's there's quite a bit of variability and it would be really nice to be able to just set that once for

each flavor and then have protocols dip into it but um yeah it's the hope is that we can do it in a way that's generic enough but um yeah makes sense yeah this this is great any other thoughts yeah I'm not sure if you guys can hear me okay but would it be nice it would be very nice to add all of these uh resources around resource locks on the official interrupt repo as a new section as if we want to continue having this in mind when developing further

ercs Etc it'd be nice to have it um there and also have all the nomenclature and properties of resource looks as well in one place because I know there are multiple efforts I've seen other projects doing something similar as well so I we want to try to aggregate all the information that we have in one place yeah it's a great idea I mean I I'll show this in the group um I'm not sure who has right access to the repo but I I'll share it and we can get that reflected awesome yeah you should be able to create a PR into the rippo we can we can help you guide it guide you through it one comment in the chat from

yoav if you saw that Stan by the time that we can merge in EIP for code reset we'll hopefully have EIP 7701 which adds native AA yeah um I think there was some debate in the chat about whether or not 771 addresses the issue fully um but I you have I totally agree um you know we may not need a different delegation model if we can get native a awesome well this is great thank you maybe let's keep going just to get through the rest of the agenda thanks so much cool uh next up message

passing um uh so yeah I don't really have much much of an update um on the message passing group uh but the status is that so previously we have kind of worked through these properties that we all agreed on um in Denver that we think this message passing ERC should have and so um yeah and so the next step is to actually kind of move forward with this ERC so for the um because we want to you know kind of for the sake of time ERC 7786 is the likely Contender right now and so we are given these properties that we agreed on we are going to look at

7786 and see what specifically on that if anything needs to be changed um with the plan being to push 7786 forward as the message passing standard um so yeah that's the status I think right now the big the uh biggest thing that we're working on is like the proper gas abstraction so seven if 7786 does have gaps uh accounts for gas abstraction um but since it's such a large part of message passing is being able to pay for gas uh you know we want to make sure that it's um it's a very robust and userfriendly um gas extraction protocol so uh yeah that's kind of the

status awesome thank you any questions cool okay well thanks for the quick update we can keep moving along uh next up open intense framework is Pedro here yes thank you Josh there you are I'm Pedro from open Seine I'm going to a brief update on the open intense framework H for those who don't know the open intense framework was created by H hyper and builds on the standardization work by by across with 7683 uh it aims to provide a production ready stack that lets up chains and

rollups instantly plug into the intense Market enabling like seamless crushing interactions so what what we're doing now is we're teaming up with the eum foundation defi Wonderland defi across hyperlane boot node Hashi uh and multiple layer tools to define a road map that will bring H the oif to production ready maturity be fully featured and and widely adopted H the road map is still being finalized but once we have a dedicated team working on this we'll share it with the community and welcome your feedback H for now like what I I can say is some of the key goals with the oi are to unify ethereum including small rollups and app chains H to standardize to standardize and Mize

intents for a thriving a cross chain app developer ecosystem we we believe in the same way that erc20 ER allowed defi to exist like like there were tokens already before erc20 right but thanks to like this common interface ER defi was born and we think the same is going to be true for for intents right like there are many intent protocols that already exist and and work but we need to to standardize how intents work for like a real ER application ER industry to to emerge and then we also want to make like the broader intense Market more

efficient around blockchains we we we also want to do some work on auctions for like intent based swaps and and and more things uh some of the areas of focus uh for our work like to to get to these goals are going to be further defining and extending uh earc 7683 with for definition and and structure H we want to create a an open source filler implementation that handles rebalancing settlement uh and and other things we we want to create like modular settlement options with escros with resource logs H Stefan I would like to to have a conversation with you uh this week or or next week um

and also like multiple settlement authorities H we also want to make like uh an SDK and UI components to build with intents uh and we're also thinking about intent based account abstraction with like uh I 7702 and 457 uh I think I covered everything yeah yeah that's it thank you Jos yeah of course I just wanted to add yeah thank you open Zeppelin and everyone else who's who's being involved in this I'm excited to have Lei team um along with some of the earlier contrib fures like Pedro mentioned hyperlane I think I guess just really quickly from

my perspective the oif started as U as something that a group had pushed together but as a very initial implementation and I think the value in some ways was not just initial implementation but as sort of the shelling point to organize everyone else together and hopefully arrive at an even stronger sort of V2 or official V1 version of this framework um so yeah I I wouldn't over index on on what is what was pushed out so far which was great um but I think we all sort of have over the past month or so um through discussions realized and learn um how we can make things even better so yeah really

excited to have everyone help us to get there yeah and I want to add I realized from listening to to Stefan speak that a lot of the things one balance is doing might overlap with what we're doing with might have like a lot of common components so Stefan again like I would love to to meet with you and discuss this thank you cool and I guess the last thing I think uh Pedro and your team also working on a road map for the oif that maybe we'll be able to share in the next week or two whenever whenever you're ready yes absolutely cool so we'll make sure to share that with the group and of course anyone that has feedback on the road map for the oif feedback is welcome cool

no questions we can move on to the next I think we have an update from Wonderland on interoperable addresses ERC uh and the interoperable wallet that we will be working on yes let me share my screen can you see my [Music] screen yep perfect great so hello everybody I'm Titi from Wonderland and I'm leading the interoperable wallet project I'm going to go through our road map so first why the need of creating this wallet we need to Showcase in practice how our

standards will be implemented to do so we're going to focus on an experimental wallet development on testet which will be done on top of on buer codebase and over here you can find um some of the reasons we decided to fork and buyer aside from this we will build a wallet agnostic SDK for any wallet to easily Implement these features a little disclaimer our processes go by first doing an idea draft which is basically this role map with r estimates and before starting coding we do a tech design where we dig deeper in the implementation details and needs where we are able to provide more precise estimates so okay um moving into milestones we have divided it in two

phes the first one is this experimental prototype and as mentioned here the goal is to create a minimal bad functional W that demonstrates interoperable the addressing and in based cross chain transfers the first step is to fork and buire create UI and U explosive signs for it build these UI components and Implement serialization to transform human relable addresses to machine readable it's important to knowe that on this initial step we will work with row address leaving the neighbor solving for a future myone this aligns with the recent updates on our approach on interoperable address standard where we will split current ERC 7828 efforts in two parts new ERC Focus only on binary

representation keeping 7828 for naming standards this will allow each user group as wallets and intense provider to focus on the relev relevant parts so continuing with the wallet Milestones over here um we will translate these efforts into the wallet agnostic SD as mentioned before and once address forting and serialization is resolved we'll move to the next step of functional implementations where we will develop an adapter interface matching the open intense framework standard and develop intance based transfers so again as mentioned before this will be an experimental wallet on testnet where we will only aim to showcase the mechanisms

of course everything related to to the flows and UI designs with transfer errors handling will be built on this step and finally for this phase one all these efforts will be over here will be uh translated to the W agnostic SD so any questions so far we'll take that that as a know and lastly for the later phase uh two we will work on adding privacy features where we will EV evaluate different protocols comp compatibility like rail gun and oo and also payment request features to improve the ux as much as possible at the end you can find

some of some of the definition of Ts for this face T and if you have any questions or feedback feel free to reach out we are more than open to listen your thoughts in it awesome thank you Titi anything else from your side that you wanted to share no I'm good cool so yeah I guess just to um this one quick followup thought so we are this wasn't I guess clear in a previous call but announcing it here that yes the wallet that we are forking is the amby wallet I can drop a link in the chat um excited to move forward with this with

the Wonderland team and other contributors that will be joining the effort soon if anyone has questions wants to get involved um yeah just DM me or drop a message in the group cool okay uh well then last up a late addition to the agenda Georgios um wanted to share a few things on the interupt marketplace yeah thanks Josh let me share the screen no still not visible

right yet we see something we see yeah I see it okay yeah okay now now you see the I got it know yep oh perfect all right so what's the ethereum internal Marketplace um this that idea was born at Denver the offsite uh in the intense group uh so the people there after couple of discussions made it up that actually it's a good idea to start working on some sort of marketplace um so essentially kind of a sh platform for uh change protocols and and solvers

um so what kind of problem this is solving right so we uh identified that they after again uh lots of people in the room there are chains there are inter providers or solvers um there is there's problem for interrupt uh for change on day one especially and nonmature ecosystems nonmature l2s um so there's no unified resource um for uh for chains basically to understand and see their uh their options what's what kind of cross chain token STS are there what kind of bridge protocols what kind of intent protocols

uh and there is no really um and all these discussions are happening actually at hoc right world of M they're trying so if you're launching a new world up you're basically yeah trying to figure out to whom do you need to talk to um and on the other side uh I think the yeah this was initially also mentioned by thei team right that uh they want to support as many change as possible on day one but they don't really have the enough information right like simple stuff like uh uh the chain ID um gas tokens and stuff like that so right um so yeah these are the main problems that um uh we'll try to solve um how I mean there are a couple of

ideas initial ideas of course uh I mean I'm just mentioned here for for the first time so we can start getting feedback but uh the main stuff that everybody seem to agree so far is like this uh kind of um registration concept like like announcing themselves so new2 is just announcing ay here I exist kind of a single source of Truth for uh chain directory but also for interop protocols aggregators and of course solvers right um there's also the the same um the same problem in a sense for intent protocols and solvers They Don't Really um they don't really know uh where and how they can provide the services uh so you can

think of it of a kind of a matchmaking platform in a sense for uh these three um types of of projects right um what's the why this actually matters uh like we believe in the end of the day um yeah an accelerated goto market for chains um just more efficient on boarding uh for aggregators bridge protols and solvers and yeah just a more efficient cross chain ecosystem in general so if you guys are interested uh to get involved or suppor this please

reach out in the group and yeah that's a very early stage idea as mentioned so feedback is welcom then yeah let me know awesome thank you George yes if people have feedback want to get more involved should they yeah where should they reach out to you just on telegram you're muted if you're talking but yeah georgeos is in also in the telegram group cool okay um well we got through the agenda did it pretty quick we have can

end early then any last questions thoughts otherwise I have a question so earlier it was said that we may get 7701 uh merged at some point so it sounded like before there wasn't a path to get this merged and now maybe there is um and when we say native account abstraction like what does that actually mean like an any eoa interacting with a contract that implements 7701 would get like a account abstraction features or maybe someone else can explain it better uh I can so no it has nothing to do with eoa EA will always remain an eoa there's no real way to uh to make it full account abstraction because of this

ecdsa key uh even if you even if you could use something like our our past proposal for code reset you don't fully solve the problem because of existing permits and also issues with the other chains where you did not revoke the ecdsa key so 7701 is full account obstruction meaning that uh the address the address you are using has a validation function an evm code section as an eof code section so the validation actually is is code and there is no ecdsa key to begin with and this of course makes it easier to also do things like resource locks because there is no

master key that uh that could could bypass it okay and this is for a new address or a contract being deployed at an address or like what's the migration path for an existing user oh it's it's a new uh it's it has to be a new address if the I mean I mean it can also be an existing address that you migrate from for example EC 437 if you have a proxy if you have an account that is a proxy using 437 which is a common case you'll be able to H migrate this to 7701 but you won't be able to migrate an EA to full account obstruction because again there are

problems that I don't think that could be solved D or could be fully solved with the ebsa key okay thank you yeah okay that that supplements my understanding of 7701 I think the code reset path is the only one that sort of offers a way to upgrade an EA into the smart count capabilities um that also supports the the resource locks but uh but yeah the the sort of security concerns that were mentioned by uh by by UAV around permits do remain so there was discussion in the the group about um you know the number of tokens that have native permit on top of the erc20 is

like somewhat limited and those tokens that have it uh but are like very well used like Circle and usdt are all upgradeable tokens and so there are other ways of sort of mitigating those things if the community believes that um that an upgrade EIP is uh is a valuable thing to have yeah I think I still think I think a code reset would have been useful and I wish we could have gotten it into 7702 to begin with but uh it's not but it's not going to make it a full account obstruction proposal because permit is just one example there are other issues such as I mean your your your old

private key remains important because it could be used for grabbing your address on other chains or if you ever sign something for another chain or anything that uses EC recover on the same chain which permit is one example but is not the only one so it's a if you if you are migrating an account it's going to stay somewhat insecure and somewhat dependent on the old private key there's no way to fully rotate the key yeah that makes sense but it will be useful for resource locks yeah that that I agree and that's that's a primary reason why why I still would like to have this change to

7702 cool all right well maybe we can end things there thanks all for joining