Future of EOA and AA Breakout #6

Transcript

all right I guess we can start um so this is the breakout number six to discuss 7702 and uh we are going to discuss the latest um proposal uh the latest uh change request and we will try to uh to move forward um if if we can at the end of this call and then there is ACD on Friday so it would be nice if we can have some type of decisions for Friday um I think I've seen uh a blog

post recently um an ammd about proposed changes um maybe we can start here or maybe like Client First you can give us a quick up date uh on on the status and the latest U version of 7702 um I don't really even know where to start at this point all right we can I feel like the current situation is basically that like we've been in this uh state where there's been

a couple of proposed changes um and and the list of proposed changes like sometimes keeps increasing and like sometimes we keep like having some ongoing discussion on them and I think there's a strong desire to get this to the point where we can uh I actually yeah like have finality yeah on the spec or if if not finality on the spec something very close to that so that you know at least the scope crep of the whole thing doesn't just keep

increasing right so I know that at least about a week ago when like I suggested the uh idea to have this uh breakout there were at least a couple of uh different ideas around uh like the uh the current uh the current design which uh has you know this the new account type and then some proposals for things that we can that we can replace it with um and I'm I'm trying to remember what the specific ones are okay

so one of them is uh this uh concept of a of a code reset op code um another one was the basically adjusting the behavior storage up codes so that so that they yeah like use hashes to like to go into the into the terministic storage slots uh that are different for every proxy and then I think like one or two other ideas um so I guess one way to start is to just directly get into some some of those I mean or we can talk about like underlying philosophy but I feel like just like talking about either one of

them just gets into the other one anyway that makes sense I mean maybe I can set a little bit of context also for so we we wrote this this document that about code reset and um and I can maybe share with with everyone here a little bit of context on how that that came up I want to be mindful like I feel like I'm kind of like coming in at like the last mile here where everyone is already super fatigued about rehashing this um this uh this EIP and making some some suggested changes and so um I do I do really appreciate you guys spending the time to entertain it um because I know everyone the common goal here for everyone is to get something included in Petra um and uh and that's I think the Northstar that we need to to keep um

everyone aligned on um but yeah there was a there was a a workshop that was hosted by the wild connect folks and and and Derek put together um during Brussels where we had discussed a little bit the 7702 proposals and then the latest changes that uh like client had um had merged um and the topic of ephemeral versus non-ephemeral uh related to the uh the code that's being added to 7702 accounts was sort of uh brought up and um the impetus for this initial uh discussion was the idea way to maintain the optionality of an account to be um either uh persistent or ephemeral um in the in the creation um and then throughout that Workshop sort

of came together a few different ideas around how to to be able to enable that um so maybe I can quickly share the screen and and share the link to this um to this document here um you know how to copy the link uh yeah you can past the link yeah okay so there's this um this document that that be put together that really just aim to be a summary of of the discussions that we had um it suggests uh three changes to the

7702 proposal um one of it is around 3607 so basically to disable the um the the eoa key from being able to to continue taking operations um the introduction of this code reset op code that allows for deleting the code at an um at an address without um without impacting the storage and then uh having optional Cal data that can be passed as with the um with the transaction to be able to initialize the account um the idea being that if you want to have ferality you can implement it by um by deploying the account code calling the

Constructor um and then at the end of The Constructor having this code reset op code be called such that the account returns into EA functionality um so that was that was the the the impetus of and and sort of the summary of the of the workshop we had discussed a few of the different concerns with this um one of them being as vital mentioned the the storage slot um issues and then we sort of discussed two mitigations one of them being at the solity pragma level and then the other one being updating the storage knots I don't think that it makes sense to like discuss these mitigations specifically because they feel very tangential and it also solves an issue that exists already with um with smart contract upgrades um so I I

think it would be wrong to focus this this workshop on on the the storage stuff um perhaps perhaps it makes more sense to focus a little bit more on um on the suggested changes um so that's a context from our perspective but yeah feel free to to ask any questions or or jump back in um okay so andgar maybe you want go sure I can I can give my opinion um so so I will say um this is definitely it it looks like an interesting um directionally going feature in in in general code reset but I I am I think I'm opposed to adding it to 772 just because it basically just

changes the character of 772 quite significantly it basically turns it from a temporary kind of um um upgrade of of newa into smart account into a permanent one because by by default you can just basically use code that does not have code reset and that way basically it's not all of a sudden a permanent um upgrade which is specifically something that we considered out of scope for for 7702 um and then even even with this kind of this code reset it basically it's a completely new type of of of of pattern that we haven't really reasoned through uh before which just significantly changes the the character of the AP the scope of the AP it's something where I definitely think I can see a world where some feature like that

eventually would make sense and would be a nice feature to have but to me there really is no no good reason to combining it with the existing EIP could you help me understand what's the profile of the current EIP that you think is being that that that is being changed here by those suggestion so what what's the intent behind the current EIP that this would sort of violate so the intent behind the count appears that in any situation the ultimate authority over the EA or the is always lies with the the EA key itself and uh that basically the code is just a supplemental delegation that can always be ultimately revoked by the authority

of the of the original um UA and in in this situation now you can basically like you you you would now instead move the authority of of Del moving the Del moving the authority back to the UA into the code so the code would have to itself decide to call um code reset and and and unless and until it does that the the eoa key itself is powerless and that's specifically a thing in my understanding was was not what what what the EAP was trying to achieve that makes sense yeah I I agree with you you know if that's the intended outcome of the IP then this this is a deviation from that from that objective I think from the conversation that we've had with a lot of the smart contract wallet teams they

would prefer to have this ability to um switch sort of completely to to a Smart contract account because then this allows you to unlock a lot of functionality of a smart contract account um but if purely the goal of this e is to add programmability to eoas um then it creates this new type of account which is kind of like not an EA not a smart contract account it's this this third third type of account that right now as far as I understand no one is really building building towards um so so yeah I wonder who's who are sort of the stakeholders here that that want this program yeah I I think it's probably uh I can chime in here so uh anybody who

has I think wallet will be building towards this uh because the entire idea uh the way we see that right the entire idea with 3074 moving gone to 7702 is that until now a lot of the things that we as an ecosystem wanted to push for came uh uh not aligned with uh eoa wallets and so EA didn't participate and so the adoption was pretty small so when you introduce something like um a way to do interaction between daps and wallets that will allow batching 99% well not 99 but like a lot of the wallets that are actually using those

features are not part of the game they do not participate this gets less adopted so as soon as we have those capabilities like 7702 we will be building towards supporting a more uh uh uh a a smarter better ux uh uh with applications where both smart contracts any OAS can support the basic feature set um so that's that is I think at least the way I see this this is probably the biggest goal that we're trying to achieve uh right now is to allow those better ux experience uh to be widely adopted and then over time I think that there's a way to introduce a

addition features that will uh maybe like Anar said like over time we introduce more and more capabilities that kind of push towards more and more uh uh smart contract capabilities taking over but uh but yeah I think this like using this account that is an EA but has the ability to run code is definitely going to be going to be adopted um and I can say that because we'll definitely be building with this all right um the one thing that I just wanted to add is or maybe raise as a question is regarding uh the ability to add code reset just as a way to basically uh not save the code for future uh operations which is I think I've been saying this a

few times but having a one transaction ability is still useful so regardless of stopping EA transactions if we can have the ability to code reset at the end of the transaction I think that may be a smaller addition that is still valuable I understand if like not everybody sees the value a single transaction delegation but but in terms of actual risk on the people using uh this I think it actually makes a big difference uh I guess that approach is interesting because that just like fits right into like basically the the way that self-destruct already works right exactly and Derek you had your hand

raised first next think uh you're muted thank you Derek from W connect so I agree with aric and everyone in this room that I think the core premises that 7702 374 bring to the taable we can batch transactions we can sponsor transactions and users can pay uh for gas in erc20 and users don't need to learn what gas is anymore because they learn what ANC 20 years which is especially important now that we have this explosion of L2 chains um Mike so I don't represent a wallet other than a

test wallet but I've talked to a bunch of wallets about this um I talked to aric I talked to Rainbow I talk to to trust trust is a special case because they have an ESC 437 wallet and that's only really trust ESS and okx who are noteworthy 437 wallets who who adopted that I'd say say maybe coinbase smart wallet um the point I want to make is I'm concerned about the adoption of 77022 I think if there's this Emeral case with self-destruct I think it allows for an easier um migration path for for wallets um because there's less state to manage because you deploy and then you undeploy and um and I'm also a

fan of the modification because it allows us for with which I know is not the intent of 7702 but it allows for a more permanent migration um but it allows for it on the like a layer above the protocol so um we don't need to wait for another protocol change but your main concern is adoption of of 7702 in the in its current form all right ah yeah um so like looking at how we reached 772 is looking back at where how we reached here because it feels like

we're backpedaling a little bit like we had 376 370 whatever uh like the the up codes and we thought okay these are not compatible with 4337 and these are not compatible with existing infrastructure that that we want to be compatible with and this is why we were like like okay let's do 7702 and when we first introduced 772 without the the designations delegation it had some problems and a lot of people were raising issues about these problems when we came with the designation delegation all of these problems were fixed but

now uh we are faced again with oh but wallets don't like that um but we were fix like by doing this we were fixing other issues that other providers and other wallets have been complaining about so it it like I I what what I'm trying to say here is that there isn't a a a spec that will please everybody that's 100% uh uh like a fact there there's always a spec that is going to be the most like the the best for most but that will not work the way everyone wants now if we want Emeral uh uh delegation designation I think we can figure this out but code

reset is is not I I don't think code reset is the way to go uh because with code reset I feel like it it provides this uh ability inside the evm and not from the transaction itself and I think that if we want to introduce something like this it should be from the designation itself so you designate only once with the nons and then once this like this this transaction is executed the designation is reset uh but I I believe that last time we talked about this Ansgar said that there is a Dos Vector to this to this

approach and I want to touch back on that like we we go back and try to solve this issue and this is this is I think the the correct approach to Emeral designation or delegation okay um do we have more uh more strong opinions on on on this or should we uh should we jump to the to the next point David

yes um yeah I'm David from wallet and um I wanted to share some views um from a wallet perspective on why we think that code reset may be quite useful um in a lot of wallets like um some of the other ux things that have been mentioned like batch sponsorship and things like that uh will be able to be done through 7702 but one other major thing um the 7702 somehow um delegated to further protocol update was regarding validation and in quite a lot of ux related uh hurdles that wallets and a lot of protocols I think um needs to handle right now is

regarding the validation and user key management and I think um this code reset and blockchain the wallets the EAS from making protocol level transaction actually enables a custom validation scheme that could be um implemented through smart contract so um yeah one thing I wanted to add on top was that besides some execution related functionalities that 770 10bls I think um the other thing um that we're interested in and want to see coming through is regarding the validation like we want to unlock some validation related features and make those things customizable so that for chain obstruction uh related protocols as well

and some for wallet we can um I think somehow potentially reduce the risks related to wall Key Management okay um init go ahead yeah I I just want to highlight what David basically said and I I sort of agree that there is no perfect solution everyone is trying to um make the evm ecosystem better in their own way and so there are a lot of different opinions but just putting uh out there the stuff of how wallets think about um basically with the current 7702 spec we

are creating this new type of account which uh has smart contract code but the eoa has root access so the eoa can move assets away from the from the smart contract code and that has that basically breaks validation that basically so you get what do you get from this is you get batching you get pay masters but you don't get the security of smart contract wallets and that is I think like the root cause of all this discussion is where like do you still want the eoa private key to be able to have the root access of your account or are you willing to delegate that uh job to the smart contract code because if if you delegate that job to

the smart contract code then you have access to a lot of us exper social recovery um resource logs uh all all of which make uh the overall experience much much better in terms of wallet for wallets and other uh other application Builders and so that is one thing that I want to highlight over here one of the concerns that we have heard when we talk to some of the people uh about why the why making the private key a root access is important is because so that it is very clear to the user that the private key the private key can still basically withdraw fund so for all the chains where the user has not migrated to the

smart contract wallet or for some Edge case tokens where permit or e- recover based permits are still valid if the user loses their private key then their assets uh can be withdrawn for those tail end chains and for those tail end tokens uh I think at the end of the day this is uh a point about educating the user and some someone or the other has to educate the user about what is the seriousness of the private key even after they have migrated to a Smart contract wallet uh and we cannot expect a retail user to basically click a button and understand all the nuances of okay now my my private key is still the root user

I need to keep it more more secure we have been talking to wallets half of the wallets uh one week ago did not know what what is the current spec of the 7702 so even the wallets who are working in this domain do not know what is what are the nuances we cannot expect this from a user the perfect place to educate the user is when the user is clicking the button show them like a big red button saying keep your private key secure and so even in that scenario if you if you basically educate the user that way what you get is even if the private key leaks which happens if the private key root user all the users assets are at risk but if the user has migrated to this more secure more secure version then um only the assets which

are uh which which lie in the permit type scenario are at risk and we ran some numbers almost 99.85% of transactions that happen in the last year do not have those permit type uh issues and 99% 99.9% of L1 tvl does not have um does not have a permit so the the amount of uh assets that we are caring about for for uh for making sure that assets are are at risk or are not at risk is very minimal um that's not true we exchange DM we exchang DMS about this ens is a token that's at risk

that's billions of dollars like it's not true that it's me amount of risk many of these tokens that have permit to are do not support 1271 yeah I just sent a link uh I just sent you can argue if it is minuscule or not but almost 99.9% of assets are not at risk that's not true yeah of the L1 fdv I have I have sent a link to the to the analysis as well ens is at risk but uh are you willing to hold back uh changes for for one token one or two tokens yeah for billions of dollars of value absolutely yes all right well this is this ANS

chain or like I don't understand like there's two there's two tokens that are significant that um that have like permits I don't trust what you're saying because I literally picked one random token and it was at risk so until someone else does some analysis to tell me that ens is literally the only token at risk you were trying to tell me we ago that there weren't very many funds at risk I pick a random token and it is clearly at risk so I don't really trust the fact that you guys are saying that there's not that many that much funds at risk it doesn't seem true so and it doesn't really matter because ens is at risk and that's a billion dollars I I would that's enough for me I don't agree that enss or I would reframe that

question so let me let me reframe this again you have two scenarios one where priv prate key is the root user and it has access to all the assets the second where the private key is not the root user and only a subset of assets are at risk we are proposing the second scenario where a subset of assets ens and a few more others are at risk what you are proposing is if the user loses their key then all the assets are at risk is is that correct or not I I don't know what you're saying let me let me share my screen

maybe that's clearer so there are two proposals one for making maybe maybe let's take it step by step so that uh you and other in the call might might understand one proposal is to make the eoa private key the root user which is the current 7702 spec the second is to not make the eoa private key the root user which is all the transaction go through the smart contract code those are the two proposals right

mat sure those are the proposals so with one proposal if the user leaks their private key they all their assets are at risk ens and all the others with the second proposal if the user leaks their private key then only a subset of assets which have e recover and not 1271 supported uh those assets are at risk right I mean this is there are so many things wrong with this comparison that you're trying to draw here like it doesn't matter that if you go with this code reset mechanism that the EAS have migrated that only then a

subset of assets are at risk and you're trying to like draw this comparison that it's better than in the world that we have previously the problem is is that when people migrate migrate fully to a Smart contract wallet they expect that the smart contract world is going to secure their funds and that's not possible because of these tokens that don't support 1271 it's still possible to steal the tokens so yes if you migrate to a Smart contract wallet from an EA then some of your funds will be quote unquote protected that's not really a fair comparison because really a true smart contract wallet does not have this problem where funds can be stolen out from under them so it's difficult to communicate to users to educate them

that even even though they have upgraded to a Smart contract wallet their friends have a nosis safe that they deployed a smart contract wallet they don't have to worry about these private key problems it's hard to communicate that because they came from an EA the private key still has to be secured in a very special way yeah this is the issue it's not about reducing the scope of funds that are at risk and then the analysis that you're trying to do where you're trying to say like the number of transaction the amount of volume of transactions is very small that's a risk that's like completely the wrong metric to be accounting for you should be accounting for the value doesn't matter if the value is being transacted it matters if the value is at risk if the

value can be stolen if the private key is leaked so who cares like if you're sending usdc back and forth between two wallets 10,000 times like what matters is that ens $1 billion is possible to be stolen the the value is only so yeah I agree it's an education issue you can only the value will only be stolen if the private key gets leaked and the best person and we cannot expect the retail user to understand all the nuances about different type of security considerations when they are clicking a migrate button the best so let's now make it harder for them let's keep it simple yeah yeah let the best EA EA completely control the account or

you deploy a smart contract wallet that's simple that's the world that we live in today there's no reason to like complicate the situation to me it came back to like what was mentioned at the start like if the intent of this EIP is just to add programmability to EAS then like all these discussions are like somewhat moot I think what's like been a struggle for a long but that's what the point is so why do we continue to have this conversation like we've been talking about this for 3 weeks asynchronously and people keep saying the point point of 772 is not to migrate EAS but we again are here on this call trying to

migrate EA smart contract wallets so when are we just going to say all right we're not migrating EA a smart contract wallet and move on to the next problem all right I appreciate your patience with me uh Matt like I know that you've been on this for like much longer than I have and so that's you know my apologies for coming in again at the last moment here and and rehashing these questions um so please please bear with me um so understood on all those points I think our intent here was to share some additional features that aren't going to be covered by 7702 and that some of the concerns that were raised so far weren't as notable as um as what was initially um perceived it to

be um but I'm happy to yield the floor for other folks to to contribute their their opinion here uh you have I think you were the first uh yes so I don't want to argue any specific feature and I also have my concern about any form of E migration which can never be done in a fully safe way and not only because of fa permit but the reason I the reason I do like this change is from the from the protocol perspective because one concern I had about uh the current version of 7702 is that we are adding a third account type one that is that is both an

EA and contract and it has some uh some security considerations that the EAP should at least mention and it's easy but it's much easier to reason about to reason about the EAP about the security of this if we are not adding a third account type so the CH what the change does is basically alternating the account easily between being an EA and being a contract but the account is always either this or that it is never both at the same time and that's the so that's the main the main reason I would consider I would consider this change H the alternative is to try the alternative is to have a thorough

analysis of what are the implications of of this third account type and then to at least document them in the uh in the security considerations one of them is the those we discussed which can be mitigated by at least three different ways one of them is this change which makes the do impossible uh there were two others one that Matt proposed limiting the limiting the penny transactions for these four accounts that have code to one penny transaction instead of 63 and uh yet another one is what ASA proposed making the code available only when the trans action declares it so

this also mitigates the loss then so we need to decide on one of these and write it in the security considerations or to or to accept the proposed change and then it's no longer a consideration okay Fair Point uh Derek Pedro I don't know which one of you was first uh Derek go ahead sure sure yeah yeah so so I think I think I just want to to uh maybe show two points right you know so so so one is that like I think um uh I think everyone is is aligned that if we were to migrate the EA permanently then the risks of you know

leaking the E key gets lower right you know because like the I guess like the attack service gets lower right but I think like it's also true that like like it just can't be done perfectly right you know so like with things like permits uh and like other protocols that check signatures but Al just the fact that like the account will still be EA on on other chance right so my point is that like there is just not not a ea migration proposal that is like really able to address all these issues right so that's like the first point but also like the second point that I feel like I I haven't seen people mention it's just that like the the the the very reason the very reason why we W up with this current form of 7702 is actually precisely I mean I mean

it's not really precisely but like but I think I think like the a very big part of the of the reasoning has been that people actually want to keep their EAS right like like it's not actually a I think like I think I think basically like I feel like there will be more adoption for smart accounts if there was a way for people to try out these smart account features whether it's batching you know sponsoring guests session Keys there's a way for people to try all these features without having to permanently give up their uas right so if the cost of trying out these smart account features is for them to in a way almost like permanently migrating their EA that's actually like a um I think I I of course like I understand that like qu

resets will will allow the the users to then revert from the smart com back to the UA but that still depends on the smart con being actually correctly cor correctly implemented right but like with the current 77 7702 the fact that you can experience all the benefits of smart account in like a very low friction and very low commitment way it's is in my opinion actually not the bug but a feature right you know just like the fact that you can kind of like have the best of both WS yeah so um yeah so so basically like my and I think like maybe the the third point I want to make make is just that like I think we can probably all agree that even if one proposal is like say a little better like marginally better

than the other at this point I think we can can all agree that the most important thing is to ship this impactra right you know so like like if the alternative is like you know we ship proposal one in Pure or we ship a slightly better better proposal that's that's like another 12 month away I think like most people like most you know like So-Cal stakeholders in the in the in the in the space will prefer the first option right you know so I also want to say that like you know I think wire is very important for us to consider all the point of view all the points of view I think at some point we just have to really commit to a solution to make sure that we can ship this impa yeah good points Pedro then Derek again

how Derek so thanks Derek for for sharing that I think that you put it like really nicely what we all want to achieve but from my take I think I share a little bit what y all have said is the current solution puts the account In This Very ambiguous state where it's both an EA and a smart account and I know we're talking about education but I think it's much harder to educate the user around how it's both at the same time depending on their certain circumstances rather than having like just clear black and white separation like we already have the ability to revert back to Ana but

when you're a smart accountant newa I think it should be just very clear as water that you're either one or the other right the ab like there's a separation between these two it's still an EA like it's an externally owned account it's owned by the private key we're allowing them to delegate some control to some other keys but the rout control is still the EA but that's exactly what the proposal is trying to do where when it's delegating then it's actually removing the access from the private key so but it doesn't that's the problem the problem is exactly what you're saying which that's control of the eoa or that's theol the control of the

account the eoe key could still spend the assets like this is why this is exactly why we cannot do this proposal but the permits it's a much smaller scope than just saying then we're just going to let the EA be EA completely like the per already have e so when when I said it's h when I say the account is both I didn't mean from the user perspective but from the protocol perspective you do you agree with me that it's a third account type and nothing like what we had before yeah yeah I agree with I agree with what you're saying there but I think Pedro is saying it's from the user perspective which I don't really it is

from the user perspective because if the user has the ability to import it seed phas to a different wallet and it has some delegated smart contract then the wallet is not going to going to act as the same smart contract in a different wallet what it Imports like the user will kind of lose this aspect of it's an actual smart cor account that is being managed rather than the private key like the private key should be secondary in this migration and what's happening in this if you don't want to call it migration if you want to just call it like upgrade like the the 772 delegation is essentially saying oh you have some feature but you're still in EA like don't we

just continue as in EA plus the delegation right and that has been the goal that we've been trying to achieve since 3074 like four years ago so I'm not really sure why all of a sudden we're like up in arms that is the solution that we ended up on like we are just trying to give the EAS execution abstraction nothing more if you need more than that then you should migrate to a Smart contract wallet all right well but there's obviously disadvantages with that like you can't just like migrate like people have assets they have it's not like they started their accounts from scratch and when you migrate to a Smart account you're starting from scratch like so it

in theory it sounds like it's a feasible solution but in practice it's not and that's why we've ended up on 7702 because we went down the conversation we looked at 7377 and said you know client teams do you want to allow eway to migrate to Smart contract wallets this seems like something everybody wants wallet said this is what we want and we looked at it and we realized that there were problems and it wasn't very clear how to make it work nicely and so we decided not to do that and until we are able to do it in a nice way like I don't think that we can do it at the protocol level and so the best thing that we can do right now is to let eoas have some extra functionality that brings them closer to parody with smart contract wallets but it does seem like the only

blocker for this proposal is the idea that permits exist today in assets and because they exist we should not go full migration I mean I think that there's probably other problems with people using private keys to control the authority of some operation we just need to look more deeply into what those other things are but permit is enough of a reason to me not to do it because billions of dollars of assets would be at risk of being spent out from underneath a thought to be smart contract wallet upgrade and that to me is just that's a complete non-starter so I like I don't really understand why we keep having this conversation when people are just like glossing over the fact that that

private key will spend money out from under the smart contract Wallet account that was upgraded to then we just ended up halfway then I all right well that's my take we'll have to disagree on this one Derek uh from wallet connect I think and then vitalic or vitalic directly if dere so I was muted I don't learn okay two two points first on the billions of dollars at risk like um I'm I might not be technical enough here but it sounds like I still have to lose my private key for

those funds to be at risk so um I think Derek from zero have touched on that that um I mean ultimately the the risk still goes down with this with this proposal it doesn't go up um but maybe I miss but we're not trying to fix the risk with EAS we've accepted that eoas are the root control of the account we're not attempting to drisk it with proposal totally but I but it sounds like we're making something worse and to me it sounds like nothing's getting worse how are we making this worse we're making it so that you a can do execution abstraction this is like what they've been demanding for years the way I understand you arguing is that we are

actually creating more risk but to me it doesn't sound like we introducing any new attack vectors you're still not supposed to lose your um seed phrase private key um but the other point and that other people brought this up earlier that want to respond to in direct touched on this so the the intention I think is the same of keeping like making it simple keeping it simple stupid for wallets and I guess end users so everyone has the same intention um so I'll argue that with this ephemeral setting and this is actually easier because um the EA is just an eoa then with the with the self-destruct I carry out a transaction on and on chain a and

then temporarily have the smart account and and these features and then I'm back to where I was before and I don't need to worry about the state or things being different from different on different networks basically so I think I haven't fully thought this through but just by Design that's more State and it just seems more complex to handle not just for end users but also for wallets who who need to implement this and um so and then also one wallet might start implementing this and another one doesn't the end user now wants to migrate from wallet a to wallet B so um my assumption is that it's just harder and the main intention out of this

Emeral feature was to keep it simple stupid for wallets um so yeah the intention is the same but I think we disagree on on what's actually simpler for for wallets right okay maybe just so one like bigger picture uh question here is that it feels to me like the chance that we will get consensus on what we think about fall migration in time for PEX is basically zero right and so the other way to one other question to ask is uh if we do um status quo 77 7702 like what

is in the current tip then like that is still compatible with us offering full migration later right y yes okay right and so I think like if we if there's these questions that we can't get consensus arounds then I think the thing that we should be optimizing for is not trying to like rush to get consensus on these questions in two weeks but basically ask the question of like what is the Kick the Can down the road and full account migration it feels to me that the kick that can down the road

solution is basically to uh not uh enable full migration now uh but anything that's uh but then even like that conversation I think realistically will uh continue to be open for as long as even some people care about it it and you know who knows like maybe the in in a few years major applications will like figure figure out how to uh know change move move away from their dependent on permit to and like that whole risk will decrease by a factor of 100 and things might change right

but like it does feel like trying to like Rush toward everyone being on the same page in the within the next couple of of weeks is the wrong approach there so I I guess uh one other way to frame these questions right is basically not does 7702 in its current form solve all the problems but uh does 7702 in its current form like lock out possible Futures that we that that we might want to have like are there axes that we care about on which

it like actually moves moves backwards and makes uh solving the rest of the problems in in a future EIP that gets included post Spectrum more difficult yep that sounds like a reasonable approach [Music] um so with that said maybe um like client you have something to add to viic proposal well proposal to to discuss this way no I think it makes sense I'm not against EA migration in theory I'm just against it in 7702 and against it

without solving the problems that are being raised from it so I think it is a good way to frame it that we should think about what are we locking ourselves out of from the future if we do 7702 in the mostly specified current way and my take is that there's not really much that we're locking out all right sounds fair um balic do you still have your hand raised or no Aus then I think you were the next one yeah I just wanted to share a small different perspective um because for UA migration we are

discussing that there are many ds and and tokens and whatnot that don't won't behave correctly if EA is migrate but the problem is that this is a bit of a chicken and an egg problem and as long as tokens and DBS don't have the incentive to actually support is smart contract wallets and possible EAS migr into smart contract wallets H as as long as they don't need to they will probably not do it so the the Stillman argument for enable migration is that as soon as we do it then dabs and contracts need to take a explicit action to handle this scenario otherwise they will they may be

vulnerable to to attacks or this problem of the EA leaking out so in general I am neutral to either way but I think it's it's worth um considering the the idea of enable migration shows as an incentive for everyone in the in the ecosystem to properly have to account for smart contract wallets because now every single wallet can become one at any point in time so you cannot just say okay we are not goingon to support smart contract wallets because EAS are always there now EAS can always switch and yeah you you cannot account for that okay K you can

go um yeah I was just going to add so I think it's not it's a good idea to separate out the migration concern from this I I still don't get the push back on migration and for me it seems like a feature that's quite that's quite necessary but I don't think that it it's worthwhile to to fight this anymore I do think that the thing to consider is just the the side effects of delaying uh this to to a different AIP so I think that's the only thing that we're sort of creating path dependency on is there's going to be other ecosystems are going to move faster um towards supporting cross chain stuff scalability all these different things and I know that those are features a lot of smart contract W

that people have been trying to to develop for um and so I I already know that there's a lot going to be a lot of disappointment from the people have been developing on this stack for for a while to see that um that there's going to be longer timelines to be able to get something like IM migration or support for uh smart contract accounts more natively um supported so that's just my my my take on like what what is the cost of of this well anyone wanted to add

something Derek were you just unmuted oh okay all right do you want do you want go no please I understood Derek um but I think Nico said Greg no I will I was saying Derek right before but it was on you all good Greg you can go ahead yeah I mean I was gonna say something a kindu theal had jumped in on before but I think like the fundamental thing we need to remember here is like it took us how long to get

3074 approved which prompted this whole discussion on getting which prompted 7 and 702 even be coming into light and we don't have enough time to actually get anything reasonably heavy implemented for Petra as Petra is already underwater in terms of like how much shit's getting put in I think we just need to be pragmatic and say what are like the best features we can get away with today to give eways like a little bit more breathing room and teams more breathing room so that we can slot an advancement in and upgrade that for the next one

for the next hard Fork because like everybody's already kind of said and we've already hinted at now it's we're not going to get everything and the more we try to like make this fancy we're just going to run into further problems so I mean like from my point of view I would say get as Slim and lean as we can to pull this off so that at least the EAS can like get a little bit ahead of the curve um and then just like really really spend the next like year six months eight months to like figure out what is like the best situation we can get for us moving forward yep there seems to be an

agreement uh around this idea of getting something in uh something that doesn't block the future but something that is yeah lean and small enough to to not run into troubles um I guess we can keep discussing it uh right now we still have 30 minutes uh on the goal uh so we can probably use them to try to to start this this move and to assess what we can um retain in 7702 and and What needs um to be left out let's say

um so if anyone has an actual take Eric maybe yeah so actually just something small if we're talking about a bit more of the pragmatic uh usage of 7702 uh I think something I would love is to to see maybe there are some modifications that can be done that would make it uh cheaper uh because like the the usage of storage I'm not sure exactly what it would mean because we had so many permutations that I'm not exactly sure what would be the cost of actually using this in a real world situation where you're like on a dab on uni Unis Swap and you now are being asked to deploy the contract and do a

batch transaction like what would the cost be if there's a way to make the cost cheaper overall with uh different uh tricks that can be built into this uh I think that's worth looking into like that's just an area just making the experience cheaper for users right so more optimization uh Greg do you still have your hand up or is this from the previous intervention oh sorry that's from the previous one but I mean like I will make like one note in regards to like features and functionalities it's like where 7702 sits is not like where I would dream for things to go but it gets a job done and ultimately if like we can

get away with some of the things that 3074 was going to get I think that's good enough as well right like to frankly if we want to under overhaul the like account model which I think needs to be reconsidered you know in general to get us like a much more Rich account system we're going to need more than like I don't know when vital proposed it but like two months a month ago like we're gonna need more than a month and we're gonna need more than two months it's going to take us like a very long time so yeah anyway I'm done just keep it simple keep it clean and we can work from there okay so question to the 7702 um authors uh to you what would be the the key things to to get into PCT TR

if we were to to get something in can we just back up very quickly and say that we're not going to open the conversation about EA migration again for 77 to because we kind of mentioned something along those lines but it wasn't super clear that that was the decision can we have a decision point on that um I think we can I can't promise though because obviously some people might try to reopen it again uh but for this go I guess I can I can vouch for the duration of this go um okay I mean let's say not is the duration of this call but for 772

we're not going to reopen this because it's becoming detrimental to actually shipping 772 so yeah from here on like that's not something that we're going to consider accepting for 772 and I recommend pushing that as a separate proposal I I agree I agree with that I just want to uh I want to make sure that we're being consistent about it so like uh so in the future if we discuss any form of C migration we should be equally rigorous about it and also if it doesn't solve the if it doesn't solve for example the permit problem we should not consider other forms of EA migration

agreed actually disagree I mean it's out of out of the scope for the SC but disagree with this like the point was that 3 months ago we said there's not enough time before pectra for us to rigorously think about the implications like we might even decide that the permit concerns not enough of concern to block migration um it's more that we just need proper time so if we find us before the next start fol we again will have only as little time as we have now and we would will have made no progress I would agree but if we just actually take proper time for that that would not have to be a br in the future but I mean that's the same saying the same thing I think like if we do the research and we realize that it's not a problem for some

reason then that's equivalent to coming up with a quote unquote solution like we have to neutralize this problem yeah and in addition uh just since uh so since we are not using this form of mitigation I think uh we should have in the security consideration we should have we should mention what mitigation should be used for the uh for the dose issue whether it's limiting it to one transaction or to a or at least highlighting the problem so that clients are aware of it andar do you yeah yeah yeah go ahead

yeah the question right that you asked was from the author's point of view what are the open questions or the questions where would still kind of want to get feedback on or something and to me that there are three three ones that I'm primarily still un unsure about and so those are number one is the kind of the exact ephemeral nature of of of of the delegation so basically as as I proposed in the past one alternative would be that instead of having The Code by default active after delegation and only if you specifically send an EA transaction that basically overrides that and then you can still do that um in practice if we're thinking about it a bit more it feels like the only way where that would be different so

basically if instead you turn it off by default and you only turn it back on when you send uh user Ops the only way that would be different is in passive situation so if someone interacts with your account you know while you away you know you you did your delegation operations and everything and then someone wants to interact with your account should they basically by default interact with the code or with the Cod less version of your UA um to me it feels like it seems safer if by default they would attacked with the Cod less version of the UA just because there might be existing token centers or something that basically check that the recipient is in US something and then they might they might fail if if if that's not long the case so I I have some bias towards going to um only

having the implementation active when you explicitly plag it as such in the transaction but I'm open either way so that's kind of point one topic one is this kind of AAL nature topic two I would want to briefly check with people how they think about uh code accesses so the E right now states that actually if you if you inquire about the the code of the of the account with with um excode copy or things like that that it actually Returns the the code of the delegation Target which to me seems very dangerous because it can give people the WR the false false understanding that that's a persistent contract that lives in the in in the at the address and then you make assumptions about it never changing

because for example you could you could analyze it and you never you don't F the sruct whatever people did there and then you basically believe it's safe and then it gets HED out under you so my feeling is you should never be able to access the actual um code um of the delegation Target so that's a another propos change and then the third one um that's a very new one like you of a few days ago convinced me that actually it might be worth one more time reopening the discussion around init code um and that is specifically because in the past init code was not really considered because um basically the initial versions of 7702 all had were rerunning every single time trans action you wanted to use the smart account but now that we basically

have this persistent delegate delegation Target setting it actually seems reasonable is to potentially have an an init code Step At the beginning of of of the transaction where basically you you just send up call data that gets set and runs in your account and the nice thing there is that basically it would more closely mirror the way um smart accounts are initialized today where basically you deploy them and then you initially immediately um call into them them automically to actually set them up H otherwise you have this annoying thing where there deploy and then you have to be robust against people calling in before before you can actually in initialize you also have to double sign with the same UA key multiple times it's a bit ugly so I'm I'm at least curious

about in COD so to me those are the three open questions ephemeral Behavior code reads and in code yes uh Ahmed I think you were first oh um yeah so my opinion about these three points uh the first one I'm not a bit I don't see this as a problem I don't think that we need to go aeral route uh I think it should be an option for the user if they want to go with the ephemeral route but like like we mentioned before uh Ansgar mentioned that this could lead to

uh Vector if we add a a flag where uh you can make it ephemeral uh I'm not entirely sure if that uh can be mitigated or not and uh for the second point I think uh I agree with Ansgar on it and I think that we can make x x code copy and uh sorry xcode uh size and xcode hash uh return and empty account so like uh like the same thing that they would return for an EA and for the last point if I remember correctly it was about init code I know that uh initializing the smart contract would be ugly in the current form but I think

that adding init code will just complicate the implementation and I see that there is no need for it but that's a just my personal opinion it is not backed by any scientific or engineering uh logic thank you you're welcome J you can go regarding init code if we don't add init code yes I know it's complex need to think about gas then at the minimum we must add a very strong H security consideration to the EAP and that you cannot rely on any existing contract code because any contract like safe or others requires

setup State a setup of storage and if you rely on such a setup you cannot bind it to the transaction and you are vulnerable to a front run that someone will you uh you you create a 7702 signature and someone replaces the setup with something else and grab your account whatever and so you must have a setup that recheck a signature another signature so it's a terrible uxix because you need to sign twice or you are vulnerable to front run H so we don't need to think about how to fit in COD data or init code it's not init code because it's not really

Constructor but it is a c data that to call at the beginning uh enar do you want to precise something on what you meant with FML uh yeah I think physically because I realized that was going confus the question is just if you send a 772 transaction that sets your delegation Target to something other than zero or other than clearing it um and then of course the next time you send the user up or something yes you will use that code but what if in between someone

sends a transaction that calls into your account what should happen in the ear version of 7722 the thing would have been that if someone calls into your account it still behaves like a normal EA so no codex execution in the current version there would be code execution um I have some concerns around that because there are some token cards that basically look at okay that might have some incompatibility there but like yeah I just I just basically wanted to ask the question should it be have like a smart account or like an UA when someone calls into your account other than yourself yep am you can go uh I mean uh I was like this is what I

was answering actually and uh like what I think is that there is possibility of that happening like for example let me say I delegate and then I want to make uh multiple transactions uh and like the idea of sit code is was that you can delegate in a in a transaction and then execute with the pay master or the bundler at a later transaction action if we make uh sit code only valid with sit code transactions if oh I if we make the nons like like

what prevents some code transaction and including it we lost you for about 30 seconds you're back good sorry sorry okay uh sorry my connection here is is lost you again the statement about the connection with true a little bit bad but I'll try my best um thing that that you have to increase nons um and and someone like uh uh includes that in in their uh 7702

type transaction then that right Ahmed you're activate your account like like I'm I'm not getting how no no no I'm I'm saying I'm not seeing how the ephemeral thing mitigate all right Ahmed you're cing again maybe if you can try to get a better situation with the

connection um let us know or you can probably reply uh to Ard directly in the chat can work too all um andgar did we address the three points that you raised uh earlier and i' be curious because the only person talking about init code was draw whether um and and and I think draw was basically saying you would also

prefer having init code um it was more saying if we don't then indeed we have to be very explicit about the security implications which I'm not worried about the security implications as long as we make it clear that you know all smart account implementations have to be robust against someone calling into it for the first time that's not actually the the owner um that's not not a problem but it does add a bunch of overhead so I'm I'm curious whether people are at all open to the idea of reopening the init code discussion yep you have yes so so as I said before I do think I do think it's needed but if we uh if we don't do it just um to be more

accurate it means we can't it's not making existing accounts more robust it's it will be maintaining maintaining two versions of each account implementation because for normal smart contract you don't want to sign twice it doesn't make sense to if you are initializing it in the same transaction you don't want to H sign to send a configuration twice but for a for 7702 you must not have a setup function that doesn't explicitly check the signature so we would need to be explicit about it the security considerations and say that any existing account that has any existing smart account should not be

used with this there should be a special version for each account so I would prefer having init code but if we don't then at least we should make it very very explicit I'm fine to make it explicit and you're not and you're not fine with the init code I understand I mean I don't really understand the proposal because you're saying a nit code but draw was saying it's actually call data yeah it's a it's equivalent I would prefer call data because I would prefer call data because it just it removes some overhead that is not really needed

but init code is more consistent with the how contracts work but I mean how does the call data get to the contract then like what is flow so the flow is that uh during while setting the code you also while setting the code you automatically make a call so you specify call data and gas limit for this call and you have a call frame that calls into the code as soon as it is set in the same transaction and if it reverts then you do not set the code you don't need to revert the entire transaction but you do not set the code this uh this allows you to automically uh to automatically run the setup for the account

but as a relayer how do I know how much gas was used in that to charge the user uh for example you could use 437 and then uh but frame is outside of like this is a separate call stack like you're saying that during authorization it's considered it's considered a part of valid a part of validation from a 457 perspective it will be a 47 call stack wait goes through the entire 437 stack so you can process the transactions in for the 437 contract make the contract initialization see how much gas was used charge the user make the call into the

wallet charge the user what you're proposing with 7702 is during the validation of the transaction as you're setting the code before you set the code make a call in and then when that returns determine if in the valid kind of validation phase of the transaction if you should set the code for the transaction that's what you're proposing uh not not exactly no it's not it can't run it can't run during validation because validation is called by entry point and this one is top level so it happens before entry point what I'm what I'm saying is that it's considered to be as a part of the validation from cost perspective and from the rules perspective it has to obey the same rules because otherwise it

could it can be a do on the on the men pool but uh it's not measured so it's not measurable by entry point on chain but that doesn't matter because in 437 we we also have the pre uh we also have the pre validation cost for example the 21k that is a split among among users among accounts in the bundle so it can be accounted for in the both the user the user knows how much gas it's going to cost and the bundler knows it you can't know it on offchain but both parties know about it so you can just add it to the pre verification the user adds this cost

to the pre verification G and and uh bundlers will only accept it if it really does pay this pay the proper amount it just seems like a lot of Hoops to jump through when all they need to do is verify a signature from the ea uh well there's the tradeoff of having to maintain of having to maintain a separate implementation for the account I honestly don't care like they can solve this problem very easily we've put a lot of work in to make it easy for their wallets to continue working I think having two setup functions for their wallet is like a very reasonable ask for them uh yeah since okay I don't have a h

in this race I'm not a wallet developer so whatever whatever wallet Dev developers in the call I guess we had wallet connects uh they left we have nope uh evil from and buer maybe you can jump in if you want yeah I don't really have anything to say maintaining two separate flows is absolutely fine for us uh in the name of keeping things simple not any not flows contracts implementations of your account yeah yeah yeah yeah yeah yeah um yeah that's fine well that's at least

one opinion uh dra you can you can take the mic as I said I understand the complexity that adding such initialization call data adds but the alternative is to add a security consideration to avoid calling any existing contract for example you can cannot initialize safe you are not allowed to use any safe based code unless you using different safe implementation which has a different setup method which means it different path it doesn't share the same safe Master proxy which allows any setup run yeah we can have this SEC consideration issue into the

eaap because otherwise someone will say okay I will create a safe safe no you create unsafe you it is impossible to create a safe based on the Master Copy existing of safe that will be able to use 772 I mean yes we can add this no problem to add security consideration and then find the I don't know Martin to address that but to make sure that we are safe from right we could uh directly Circle back

with the safe people on this specific point um we have like eight minutes left so maybe we can we can uh keep discussing this quickly and then have a wrap up over the last five minutes so this leaves us a few minutes so anyone one anyone with a last remark people want to discuss storage then yes we can we can use those minutes to to discuss storage Yeah so basically I have put up here regarding that in which basically

we sort of map the keys of particular delegation to a hash uh hash chunk version so that it is also uh also compliant with the veral optimization so basically chunk of keys get mapped to a chunk of keys and if you for example change the delegation then they will map to a different area so this basically will solve the problem of conflicts between the storage if there is a delegation change and I think uh it is worthwhile to have it because otherwise we could have this some all sort of issues ranging from just aad ux to maybe even uh compromising the accounts as

well yeah can jump in I've responded to this asyn asynchronously a couple times and I don't see a reason to do this for 7702 because it doesn't solve the overall problem that we have and it might possibly restrict the design space of things that we might be able to do in the future to solve this problem for both EAS and 7702 or sorry both EAS and smart contract wallets so I think that one this is not necessarily A protocol problem this is more an application layer problem and two we haven't spent enough time trying to think about the possible solutions that support both 7702 and the existing smart contract wallets

yeah I mean yes you already mentioned that but I don't think we should compromise a feature with when we simply we can sort of address it and uh that is basically my problem with the response and maybe everyone else thinks the same way that is fine uh but I would like to hear what are the opinions are out there I mean I think that um since we have a white list of

designations oh okay all right no worries if anyone wants to jump in on Cat in there's maybe since we have h four minutes left it might be worth to start wrap up uh now and basically yeah I talk about next steps yeah I feel like it doesn't seem there's much support for this storage change um we can discuss more offline but in general most people appear to

think we should solve this for both 7702 accounts and for uh smart contract wallets so we should look more into that as a solution and personally I think we should look at this as a separate proposal for 7702 because it is both dealing with 7702 and with smart contract wallets all right so in terms of uh where yellow like like basically what we learned over the last one and a half hours um does it uh does it feel like we have consensus on the idea that like the uh the bar for changing things in 7702 at this point is basically find

like if we find something about the status quo that's either last minute or insecure or that like actually moves us backwards in a way that's going to be difficult to get out from and if we want more features there's opportunities to do that in separate theps Yep this is basically the the point we at now um yeah and I guess it also feels um like in general there's uh no like consensus on the idea of exact status quo but also

like low low enthusiasm for reopening boxes and making changes that are like not kind of very contained tweaks does that yep I think that's sums up uh pretty well the the situation okay um I mean that feels like we're you know like we're not quite uh rubber stamping 7702 at its current form and and putting a hash of it on ipfs and uh and set and setting its update address to zero but it's know it's still pretty close which I guess sounds like progress I guess it

is um Eric you want to add something very small but I think a lot of the anxiety right now is that that everybody feels like the next iteration will be in two years after verles and everything I do wonder if there's some way to add a small amount of uh uh space in future uh Forks to maybe do some small iterations once once we have something good like because I think everybody feels like we do it now and then nobody touches EAS for two years at least I don't think we can commit uh on on next Forks uh like this um maybe I don't

know like client can you um give us some some ideas of the next Forks if if there is some room I don't know if you have a a vision on this maybe you you just don't I don't have a crystal ball unfortunately but if things are important things are important and we will try to make them happen so I think we just have to try and do the best thing we can do today and it seems like we're coming closer to that thing and keep in mind that that's going to be the process for the future is doing the most important things um one last point that Anar pointed out that uh I'm not sure if

anyone has time to discuss is the code reads um can we touch on that or is it too late now um I I can stay for a few minutes no worries so um yes I I you can go on this if you want to so in in in EO in E we usually try to avoid any code reads so anything like exit code copy exit code hash exit code uh size and so basically code introspection and here it does not make

any sense to allow code introspection into the EA's delegated account uh my personal opinion would be to just have these specific op codes return the normal thing that they would usually return for an EA and we can simply add that to the EIP not I want to listen from light client and uh other uh uh client implementers on this uh one one argument against this is that H there's a there are already contracts that make an effort deliberately to not to communicate with

anything related to account obstruction but to only serve EAS and we are trying to discourage this Behavior so making it easy to identify ify that the contract you're interacting with is still an EA H it goes against this goes against this direction so I understand why it's easier for clients yeah okay so so we can we can keep this enabled for non eof but in eof this is disabled for everything so we can disable it also for 7702 okay yeah for E it should be the same CH okay okay this this makes sense to me this makes sense okay I understand

the reasoning asgar do you agree with this approach well I'm just I I I just think in a way the chain in the CP the chain is actively lying so basically you're asking hey what is what is the code in this account in in this contract because you even know that's an account and then basically the chain is telling you here's this code and you look at through the code and it looks all immutable and you're like okay I'm trusting this it has no indication whatsoever that it would have different behavior and then boom next time you you you actually interact with it it has different code in the same place and that is in invariant that I think is like I I feel like a I would be very hant to ever break it and be would to me

it feels like almost insane to break it without at least a clear like analysis like who right now uses these kind of patterns what what potential security implications could this have this is like a box that I really don't understand why the count spe is opening um and so I kind of I wrote in chat the four options that I see and out of all the four all the other three I would be okay with literally the only one that I think is the one we should really not do is the one the conspect does um which is actually just yeah how how is it how is it different from proxies I mean assuming that assuming I'm not aware of any contract that does this but if someone does they would have to get the code and static analyze it on chain to

see that there is no delegate call because if there's a delegate call if it's a proxy then they have no way of knowing whether it's mutable or immutable you know whether it could have different different implementation so I doubt anyone uses this pattern but I do know of many contracts that use the other pattern of trying to only communicate only transact with eways it's a due to proxies do you see anyone anyone using this method again I just I it seems just very it's very unpleasant that we have to kind of now make these assumptions um

you might be right I feel like I remember from 3 or four years ago and maybe in the context of 3074 or something that we did look at that and I feel like I remember seeing pattern like that that specifically traced and looked at basically like followed through recursively delegation Target and everything or something like that or some taint analysis I'm not sure maybe this was not actually unchain though um but all I'm saying is conceptually like again it probably probably it's not actually breaking anything but conceptually it just really seems like wrong thing to do but I don't know maybe this is just me being being all caught up on this and maybe move no yeah you are right you are right that it would be wise to get an analysis for this to see how it's actually being used I mean we know how it's being used against the

count obstruction but we don't know whether it also has positive uses so it will that do this kind of analysis of static analysis on delegate call so we should uh we should probably spend some time looking into this all right um sounds good J yeah one more observation regarding initialization code it's not having two different code it's mean forking the entire tree of think of a modular accounts that now try to get

some traction you cannot use any of them in the context of 7702 you only allowed to use monolitic accounts that require setup that uses a signature the root contract that you're trying to use I'm trying to think whe you ever going you ever will be able to change something else and I don't see a way because if there is a way to get away in modify storage without a signature then it could be called you absolutely can modify it it's just the first setup time you have to set a master controller for the account and the only way you can

authorize that is with the signature otherwise like you said you can be front run so once you have set that then it's just behaving like a smart contract wallet and you can have them set whatever yeah but if that code has a method that can do check whatever but can do it means that basically yeah it mean it means that we need to apply this recursively recursively also for modules in the case of modular account so so yes it applies not only to the core account but to any B creates a separate ecosystem no no no it's not I I think that the modules are unaffected what is affected is the core module is

the core contract you unable to use the core contract and do yeah so that's that's just an account that's just like any other account yeah the core contract is not allowed ever to have a setup without an extra signature because if it has that method it could have been called as a first transaction yeah that's what we said every account whether it's modular or not we have to maintain two implementations that's uh yeah I think that's pretty much a given okay yep um FR you you yes so uh quickly going back to the vode copy thing um

because I I don't know this was mentioned but there's a recently proposed change to eof to add just a little bit of code interest section back uh where the code size and potentially the code hash that is sorry X code size and X code hash op codes would be re-enabled in eof so I think the uh decision about what to do with respect to sort of weather to pass through the delegation um it C can be ignored because of that like I think it it's it's still a discussion to to be had and make a decision consciously yep fa Point um I guess we could we

could stay a bit more but we're already um over the limit of the call um we can take those uh discussions uh offline I guess um I will be writing um a resume because we discussed a lot of things uh and yeah I guess we we we agree with um at least some things around 7702 uh we can try to um to to keep it as small as possible to have something in pectra and and remove anything that would block um Improvement in the future for EA

migrations and and future improvements so this is uh for now the status quo and yeah thanks for being here today and let's discuss uh more offline and I'll be writing um a resume pretty quick pretty quickly probably tomorrow it will be available draw did you have something uh or was it is your hand raised from the last intervention nope all good um then I guess that's it thanks for coming today see you soon

thanks n thank you thank you