:closed_book: Future of EOA/AA Breakout Room #5 -- :::info **Date**: June 26 2024, 14:00-15:00 UTC **Agenda**: https://github.com/ethereum/pm/issues/1081 **Recording**: https://youtu.be/_S01TtA3lao **Next steps**: - People are aligned to see [Matt's proposal](https://github.com/ethereum/EIPs/pull/8677) in the next devnet. - It will be merged in next week or so. - It is devnet 2 and we will take it from there. will explore more in the next stages. ::: (Notes+zoom chat) **Nicolas** To discuss that last update to 7702 Kevin - The proposal is basically serving the same purpose of revokability in the same way. - The new ver is also going in the same direction by trying single implementation at a time. - Our proposal was mimicing what proxies are doing. - Except migration being more difficult, I don't see the new proposal to be any different. - I think we're going into more permanent. Julian Rachman - I am against the permanent approach. I think we talked about this throughout the weeks Matt/Sam/Ansgar Ansgar - couldn't look into proposed change - conceptually it is somewhat cleaner, and in principle I like it. - two different option to activate the delegration target - add another field to 7702. give a list without authentication. It will make the tx make it active when needed, not permanenetly. Sam - If we're doing a permanent delegation, why not just make a tx type that deploys code into the EOA Richard Meissner - So the question is if the permanent approach is an acceptable path to approach the revocation topic. - So far it feels that while now Nethermind is fine with the proposal, other teams that did not have too much of an issue with the revocation, would rather stick to the non-permanent proposal. Julian Rachman - So why dont we just push the current 7702 language then? kevin - That’s also part of the proposal Ledger made, having an access_list like option a transaction to activate or not the behavior Richard - That would still mean only one delegation target at once, right @Ansgar Dietrichs  @Arik you advocated to allow multiple delegation targets, right? Richard Meissner basically on chain it is said which delegation target can be used, but it will only be used if you specify it in the transaction. Ansgar - Basically the original version of 7702 will be used, but limited to the address (singular) that is set onchain in the account. kvn - Not that we don’t like the permanent approach, it’s just like it feels like it was the kind of things that people tried to avoid during the discussion for EIP-3074 -> EIP-7702 Matt - In case of Revokation - you have given permanent delegation - the nice thing about 7702 is that autherization is only valide one time while setting the account. - the a/c is delegated to smartcontract wallet - now that we can write into the account feels like the best thing to happen. - Let people slowely migrate to smart contract wallet. Arik I think you can just add a small flag to decide if the delegation is single transaction or permanent and it should solve everyone’s issue… Richard Meissner should the single tx authorization be reusable? Arik No, if you used it and you want to authorize again you would need to do it on a new nonce… cause it increased Ansgar Dietrichs yes, I think in every variant of this, I would appreciate a one-time use flag, basically “don’t store this as delegation target at all, just use it for this tx” Arik - Ansgar, I am not sure I understood the mechanism fully - can you write it down? Ansgar Dietrichs - right, Richard summarized it well. With the additional asterisk that now by default “turning on” 7702 delegation for an already set target would no longer require any sort of signature by that account at all yoav - Seems like the right trade off to make Hoshiyari - Using this a malicious EOA would act as a genuine contract for eg; a vault until have enough funds to run away. I was wondering how the new version can mitigate this actor vector… Sudeep | Erigon - I don’t know if temporary delegation adds anything. Permanent delegation simplifies what 7702 does — which is to set a delegation designation. Also in temporary delegation wouldn’t you need to have a new authorization (since it’s nonce based) the second time you make a 7702 tx? Richard Meissner - yes, that is basically what arik is asking for. It is basically to bring in features like batching Ansgar Dietrichs - by temporary delegation, do you mean my alternative idea or the proposed one-time use flag Arik just mentioned? Richard Meissner - there no long running authorization is required, it is ok to do a per transaction authorization to batch and sponsor Sam - Can you self-destruct in the delegate call target? Matt thinks #### Temprorary delegate allocation does not bring us closer tothe smart contract wallet Arik thinks other wise - just having the ability to delegate may increase adoption Sudeep | Erigon - I don’t know if temporary delegation adds anything. Permanent delegation simplifies what 7702 does — which is to set a delegation designation. Also in temporary delegation wouldn’t you need to have a new authorization (since it’s nonce based) the second time you make a 7702 tx? Ansgar Dietrichs - right. so in that variant, once the delegation target is set, “turning it on” within a second (or third, or fourth, …) 7702 tx would not require a signature at all. 7702 basically would have 2 lists: one to change 7702 delegation targets, that comes with nonce and sig. and then one for accounts that should have their delegation enabled, without any sigs Arik - I think you can just add a small flag to decide if the delegation is single transaction or permanent and it should solve everyone’s issue… Ansgar Dietrichs - so one problem with this is frontrunning the one-time use tx (e.g. for griefing the user), if you send it via a public mempool. because the sig doesn’t commit to being used within a specific tx - temporary delegation - longterm deleg - permanent deleg Ansgar - The problem we are trying to solve is Frontrunning. - I am wondering any good ways to mitigate this as it is not with the protocol. - Matt proposal may have more context and I think could work. Unsure of any other ways to mitigate it. Matt - using in temp deleg or perm delegation - if there is a piece of code which has risk then there is no point of having of temporary delegation Richard Meissner (safe) - what is the most realistic version to push into the h/f - what is the complexity as we want to ship with devnet 2 - for me this is the pressing matter that if it is enough to implement - there are way more qns around revokability at this time - consideration of security and revokability are good way to go for us - agree to what ansgar says about timeline Julian Rachman - I guess we are using very loose terms here with “permanent”, “temporary”, etc. Maybe current “permanent” is better said as “persistent” delegation and “temporary” is better said as “expiring” delegation Ansgar Dietrichs - I would say “one-time” for those that cannot be used more than once. And then “optional” for those that are stored, but only active in the initial tx and in future txs that explicitly activate it again Julian Rachman - Sure!! Honestly anything away from using “permanent” and “temporary” would be right lightclient - ultimately you can also implement the one-time use with the current proposal lightclient - so there is no need to over complicate 7702 Ansgar Dietrichs - on a more general note, I will say that it really worries me how much the 7702 spec is still in the air, with regard to Pectra timing. **For context though**, Pectra size is very very large, so full rollout of the fork will probably take quite some time still. Imo the worst timing risk here is that Pectra ends up split into two parts, and that 7702 won’t be ready for the first part, so will end up having to wait an additional 4 months or so. Ahmad - suggestion - to preserve old 7702 behaviour, we can add a boolean flag - the nice thing about this is that once it absorbs the nonce, we gain the implemenattion simplicity from the core dev perspective Richard Meissner @Ahmad Mazen Bitar how do we handle the DoS vector that @Ansgar Dietrichs outlined for this approach? Richard Meissner - in the sense that the authorization can be invalidated by malicious parties Ahmad - this approch of adding flagg may satisfy all three concerns with a better implemenation of EIP Arik - Can someone explain why the persistence version is not attackable by this DOS vector? Ansgar - the prob I see is that if you send one time use tx, and is picked up by a bundler of anyone, the tx doesn't make use Richard Meissner - because if you frontrun the authorization it is available onchain and therefore it will still be valid in the tx that was frontrun Ivo Georgiev | Ambire - Unless im missing something, temporary authorizations would be quite limited in terms of UX You send one txn to set a delegation, so that you can then benefit from SCA features for one transaction Sounds like something that will never be used in the wild Richard Meissner - for batching and sponsoring this should be sufficient, right? Ahmad - it will just validate the tx. Ansgar - it will not activate and will not make use of the one time. Ahmad - got it, will think about it. Antony Denyer - You can basically “unbundle” it? kvn - Also, the more options we have, the more complicated the Wallet UX will be… Explaining this AA behavior in ten different ways for X different AA "brands", and making sign (very powerful) authorizations 10 times, is definitely something that feels very niche to me Ansgar - Pectra is very unprecedented - 7702 spec should be final very soon otherwise, it will not make it. - what could happen, that the EIP is split up in two - if that were to happen, we really need to decide. - I think we need to make decoision - what recommendation to ACD on what to ship in the next h/f - can we ship matt's change. - yes or no - I persopnally want to make delegation transparent - we should focus on the spec that we want people to use on the upcoming devnet Ahmad - EOF tries to look into code & gas introspection - I'd try to avoid intrspection of code and account - If we have the knowledge of one time designation will be consumed by the sender account, then we can authorize - unsure if it will work with paymaster - also if this is a requirement to allow authorization. yoav - It’s roughly equivalent to SSTORE so we could use the same pricing model (which will change with verkle) Ansgar Dietrichs - on a more general note, I will say that it really worries me how much the 7702 spec is still in the air, with regard to Pectra timing. For context though, Pectra size is very very large, so full rollout of the fork will probably take quite some time still. Imo the worst timing risk here is that Pectra ends up split into two parts, and that 7702 won’t be ready for the first part, so will end up having to wait an additional 4 months or so. Julian Rachman - Do you refer to the pre-matt proposal version? i wish we could have pre-matt’s proposal version but have come around to be ok with matt’s proposal Ivo Georgiev | Ambire - Unless im missing something, temporary authorizations would be quite limited in terms of UX You send one txn to set a delegation, so that you can then benefit from SCA features for one transaction Sounds like something that will never be used in the wild Ivo Georgiev | Ambire - Yes but you send one txn which isn’t sponsored or batched to get one that is? Sounds convoluted since many batches will be no more than 2 calls in the first place The sponsoring is even more convoluted I’m talking about temporary one time delegations ofc Richard Meissner - would this then be like a new param in this EIP, the expected tx.origin? Arik - Is it possible to make the “griefing” use case too expensive to be efficient? Ansgar Dietrichs - I don’t think restricting to a specific 7702 tx sender would be the right approach, that way it would be incompatible with 4337 Ansgar Dietrichs - at least with the public 4337 mempool Richard Meissner - could be optional xD (this is more a joke) Matt - The hard thing is we have too many people with different requirements' Richard Meissner - Do we have a summary on what we align on so far? Or at least 2 options that we have to decide between? Yoav - not in favor of temp delegation, if we still want to mitigate the issue raised by Ansgar, it will become possible for 4337 to better use. Ansgar - how will you handle different cases, seems difficult Yoav - agreed - maybe we don't need a temporary delegation. Sam - Unless you're running initcode, you don't get to revert before your code is deployed Richard Meissner - Just to understand the emulation: it would still have a delegation set and therefore behave different to an EOA when being called (or being the target of the EXT* methods), right? kvn - I don’t think we answered what would be the behavior of delegated accounts without the authorization in the transaction (having another list like access_list basically was mentioned ?) and in the context of transaction type < 3 ? Sam - Wouldn't it be a self-destruct? Yoav - if used during a tx, and says now it is becoming validated, it could work. - It is hard to think of all the scenarios. Matt - we can’t use the storage - the protocol should not touch the user space storage Kevin - we kind of changed the opinion on that, but I understand. Ahmad Mazen Bitar - I dont think client teams will go to change this on devnet1. We already finalized devnet 1 spec lightclient - agreed, this would really be for devnet 2 Ansgar Dietrichs - what is devnet 2 timing? would we have to decide on the spec to use by next acde? Nicolas - let's go for last round of for and against - dev and researcher thinks this is Richard M - might be helpful to go one more time - we don't allow temp delegation - will be dependent on nonce Ansgar - we seem to mostly align with Matt's proposal as the next step - we can explore my proposal as conceptually the extension of Matt's idea - my qn- do we have people on the call who strongly oppose matt's or my proposal as matt's extension? Ivo - I am **opposing temporary delegation** - there are various AA cases where it works better - eg. for batching Sam - If the delegation target is stored in code and you can change your delegation target, then you can mutate your account's code. Julian Rachman - I mean it would be wrong to not say that I do like the flexibility of pre-matt 7702. BUT I bias towards matt 7702 because we would be WAY worse off having this fall out in the worst case (knock on wood). The ethos for what 7702 is trying to do is still there and we want the ethos to be something we push into Pectra. Richard Meissner - I also find the idea of Sam interesting to utilize self destruct to reset delegation. Ansgar - with original 7702, it was also the sace - my extension of this was conceptually more permanent and advantageous Richard - with intrspection, I agree the changes of behaviour. With Proxys we already have a way to look into. - I like the one time allowing because if it is revert, you have to create a new authorization to reactivate again - Selfdestruct by itself will be interesting, but unsure if it is going against the isead of deprecating self destruct. Arik - I disagree with the statement regarding the batching use case - but it’s probably not worth the discussion here. 2 signatures that run an atomic 2-action code is not the same as 2 signatures that run two separate pieces of code. But again - this is not the main point in this discussion Sam - are we not planning to remove the self destruct even in the same tx Ansgar - as per Vitalik's proposal - yes ### Next steps Nicolas - People are aligned to see Matt's proposal in the next devnet - it is devnet and we will take it from there. - will explore more in the next stages. Matt - thanks for the feedback - will try to merge early next week - if any different idea is emerged may merge by the next ACD :closed_book: Future of EOA/AA Breakout Room #4 -- :::info **Date**: June 05 2024, 14:00-15:00 UTC **Agenda**: https://github.com/ethereum/pm/issues/1054 **Recording**: https://youtu.be/gsc_yTdHRig **Links shared**: * Working document for [Wallet best practices](https://hackmd.io/@rimeissner/eip7702-best-practices) * Optional nonce * https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code-for-one-transaction/19923/158 * Signign Address vs Code https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code-for-one-transaction/19923/157 ## Next steps * discuss this more in All Core Dev and if we want another call. ::: (Full Notes in WIP) **Tim Beiko**: Okay, I guess we probably get started. Had a few things on the agenda for today. basically some spec discussions. Then, following up on what is best practices and the proxy pattern and see how how things go. Yeah, let's maybe kick this off with the revocability conversation. So Sudeep, I believe you are the one who posted on the Erigon’s behalf on the magicians. ## Optional revocability. **Tim Beiko**: Do you wanna take maybe a minute to like, walk through your views and concerns. **Sudeep | Erigon**: Yeah. So we have been considering, the security handling and concerns, and saying that it's the same as a private key or a seed phrase. I disagree there, because once you delete the wallet from your browser, the seed phrase, or the private key is supposed to be gone, and no more with the wallet provider. But with the signatures, it's a different deal like once you make a 7702 transaction, the authorizations live on the chain. And so let's say, if I don't trust the wallet anymore, and I want to move to a different wallet. Then I should have an option to do something similar to, Sign out of all accounts, or sign out sign out of all devices. There has to be like a mechanism for that. otherwise, there's always a lingering question about Is it safe? There was an authorization that that was there, and it wasn't really revoked. So what what happens there? **Sudeep | Erigon**: Second point is that the people who are opposed to revocability. I don't think they're opposed to revocability as such. But the constraints that it poses on the wallet providers. and I think the nonce solution, nonce revocability is definitely too constraining for the wallet providers to create a proper ux. So I think we should investigate like more solutions. Certainly, Max nonce is one such option. The nonce manager is one such options. I think we can like come together with come together with more solutions on top of this, which have revocability baked in, and also allow the wallet providers enough sort of breathing room to create the UX that they want. :closed_book: Future of EOA/AA Breakout Room #3 -- :::info **Date**: May 29 2024, 14:00-15:00 UTC **Agenda**: https://github.com/ethereum/pm/issues/1053 **Recording**: https://youtu.be/0vHHhZgrJ58 **Links shared in chat**: * notes at the Berlin workshop by Ansgar: https://notes.ethereum.org/@ansgar/aa-meeting-berlin * proxy pattern idea by Matt Garnett to discuss https://gist.github.com/lightclient/7742e84fde4962f32928c6177eda7523 ## Next steps - next call - 1 week from now, then bi-weekly - start working on best practices By next call we hope to - explore different specs & changes by Vitalik - ERC Proxy [Richard & Ansgar] - getting progress on best practice document [Ansgar] ::: ## Agenda Tim: Since the last meeting, PR on EIP7702 and the Berlin talk are the two main things. Hopefully, we can discuss and get next steps. Matt: PR is based on different convo in Berlin and at different places. In Berlin, we talked about some restrictions with wallet devs over there. #### Takeaways from Berlin - will not have a flag to persist the code, because of open question of EOA - need to do more research on storage allowances #### Issues - storage key collision between..., added 7610 - Replay protection Ansgar: In Berlin , different dimensions and open questions were discussed. - How do you specify the target - specify the address and not the code - Decision is that launching something that is already having flag is not right - other than storage, the other big thing was to start working on a wallet guidence - how should this be supported by Ledger brought different questions and concerns, thus warrented for a guideline ### Pectra 7702 spec #### [Update EIP-7702: refine based on discussions](https://github.com/ethereum/EIPs/pull/8561) Ansgar Dietrichs I really think this PR should be merged instead of being the perpetual catch-all for all changes to the EIP. I keep meeting ppl that only see the main EIP and are unaware of any of these changes. ### AA Berlin Workshop Summary #### Open questions: ##### **Replay Protection** Ankur Dubey Just to confirm, for replay protection has it been decided that both nonce and chain_id will be optional, by setting it to 0? Julian Rachman And then nonce would be set to null Daniel Lehrner (Besu) Yes, just one correction: nonce must be null, not 0 to be optional. Because nonce 0 is a valid value. ##### **Storage Restrictions** Yoav: @lightclient @Ansgar Dietrichs update re storage. I talked to the solidity team and they started looking into supporting storage layout remapping. Just got off a call with them and they're on it. If we agree on a standard for storage bases, it can be made safe without sstore restrictions. Basically resolving this old issue: https://github.com/ethereum/solidity/issues/597#issuecomment-1537533170 - whether to make it safe Felix: - it is usually unsafe to sign conflicting code, the safe side will be to allow only one proxy - it will allow contract development system to develop the idea of storage system as it is fairly new Konrad - have a modular account with ref implementation, may send a PR - Based on the PR it is pretty minimal effort Pr for context: https://github.com/erc7579/erc7579-implementation/pull/29 Richard Meissner I tend to disagree @Konrad. I.e. with Safe the implementation effort is little, but migrating users is a huge effort. Also auditing this and performing formal verification with external storage increases complexity. Ahmad - specifying a proxy and only allowing single contract Felix - the difference is that changing destinantion of the proxy - if want to switch from one to another wallet type, initially you'd point the proxy and when want to point to another wallet - with authorization approach, you'd be allowed to sign by anyone and run code in the context of account. Will be more risky as it is not an onchain action to designate which code to be run. Richard Meissner It is possible, but definitly way more effort than when we can directly use existing contracts. (Note: I do not see this as a blocker, just a comment on compexity) Ansgar Dietrichs I will say, if we think the “only one authorized implementation at a time, with changes requiring onchain actions” pattern is desirable, we should think about a more fundamental change to 7702 instead of just enshrining a specific proxy as target Ahmad: - it does not make sense to restrict the design Richard Meissner I tend to disagree @Konrad. I.e. with Safe the implementation effort is little, but migrating users is a huge effort. Also auditing this and performing formal verification with external storage increases complexity. Richard Meissner As said it is not a blocker, but we have to consider our existing users. Maintaining multiple contract versions is not really efficient over a longer time Konrad Could this be determined at runtime (ie having a flag that determines whether to use contract storage or external storage)? That way it’d only be one codebase Ansgar Dietrichs I agree with felix to some extent: there is some risk that given pectra might be relatively soon, that we don’t have enough time to fully figure out best practices. in an ideal world then wallets would wait before adopting 7702, but competitive pressures might make this infeasible thogard Could use a diamond storage pattern with address(this).codehash as the storage salt? But I agree w/ yoav - sequential storage would be a nightmare Ahmad: - I will not prevent SSTORE Tim - So the SSTORE will act like what TSTORE does Ahmad - Yes Yoav - We don't want it to work like TSTORE - say, setting a threshold for an implementation and the threshold increases. We should not change the semantic Richard Meissner Agree with @Yoav I.e. for a normal Safe you could replay txs as the nonce is in storage that would be reset Ansgar - External storage may be the better way Richard: One point for the external storage pattern was, that keystore related pattern are going in a similar direction Ankur - Allow the user to specify the additional contract storage address - if the user want to switch to another application, it switch to another storage code Dan Finlay I thought part of the 7702 motivation was reusing existing code, so making a big difference in the behavior or implementation of these account extensions would seem like it compromises the benefits over 3074. Dan Finlay I’ll note 3074 avoided storage issues. Richard Meissner That is because 3074 acts like an external storage holder, right? Dan Finlay right Richard Meissner But agree that with allowing storage it would provide more benefits Dan Finlay the invoker initiates the message on behalf of the user Ansgar Dietrichs I think it is pretty binary: either there are no changes, or it requires rewrite anyway elim Using existing code as-is would be the dream. But if it requires minimal modifications, imo it's still better than an entirely different architecture as required by 3074. Since the 7702 modified wallets can still be used as-is for native aa. Dror - How much external storage change the implementation to EOA Ansgar Dietrichs I also strongly disagree with implicit tstore behavior. if behavior is not identical, making it explicit breaking instead of implicit unexpected behavior is much preferable Ansgar Dietrichs storage contract defined in tx would not be forward compatible with later permanent transitions, no? unless we would then store that storage contract location in the verkle node and have this difference of former-EOA contracts forever? Ansgar Dietrichs I don’t think we can make final decisions on storage today. more important to figure out how we can get to making decisions on this over the next month or so thogard One pattern would be to SSTORE / SLOADs point at keccak(actual slot, codehash) for EOAs, but that runs into the same nonce replay issue unless the nonces are stored externally. Richard Meissner the "disadnavtage" with this would be that we have to touch existing opcode behaviour Yoav I held the same opinion until solidity agreed to add namespaced storage lightclient allowing storage isn’t going to block migration Yoav With that, it becomes easier to have a standard that all accounts should use Matt: Even if we have store, we see migration - same thing discussion - Solidity is able to suggest storage - if it is okay at the protocol level, then it is good - Allowing SSTORE to work as it is supposed to work in a normal contract **Tim**: Let's move forward with Storage and keep discussing. Matt - in 7702 it is possible to delegate to code offchain and is natural. - It is more likely a situation where user will end up - One way is to have a proxy contract that is allowed Sachin Tomar If we allow storage in EOA, won’t this result in storage conflict when EOA uses different implementations in different txns? Dan Finlay And risks the bundler including the wrong 7702 account, changing the behavior of the op Felix This is why I suggested to only allow a specific proxy, because then you'd at least be able to perform explicit transitions between the implementations. Dan Finlay Yeah, “just allowing a specific proxy” may not solve storage conflict, but does solve this important issue. ##### **Proxy Pattern** https://gist.github.com/lightclient/7742e84fde4962f32928c6177eda7523 Matt - Matt thinks this addresses the issue of Offchain delegation of 7702 elim Not necessarily the proxy code, but rather the implementation slot right? Ansgar Dietrichs I don’t dislike one proxy contract, but I would be very reluctant to enshrine it in the protocol. better to enforce via wallet whitelisting imo Ansgar Dietrichs also means that every tx is more expensive now, as it always has that additional delegatecall hop Dan Finlay I disagree; a user with srps in two wallets could get in hazardous situations easily here Dan - there can be conflicting 7702 message floating around - I think this is about ensuring the user about safety **SRP means Secret Recovery Phrase** Ansgar - open to the idea, but look more into fundamentally change 7702 Matt - what problem is being addressed? - (explained at 40 mins) Andrew - extend the account scheme with verkle? Gary Schulte Agreed re:verkle, but presumably we don’t want to wait for Osaka for AA Julian Rachman So would this proxy be a built-in proxy? Julian Rachman Built into the protocol vub **A few random ideas:** 1. Let the code of ADDRESS + 1 represent an EOA's "backup code", and have 7702 just temporarily flip on the backup codes of the listed accounts 2. Add an EOF version for "this account's 7702-code is at address X" Ansgar Dietrichs can’t do this before eof in pectra is certain Daniel Lehrner (Besu) An enshrined proxy could cause problems with L2 compatibility. Not all L2s are on the same hard fork as main net lightclient the proxy would not use new ops elim Why does it need to be a proxy? We just need to record on-chain somehow who the account is delegating to. So this can just be an agreed upon storage slot. 7702 auth'ed implementations can just "promise" to verify this slot. Can bypass the extra delegatecall Matt - Merge the PR without the storage restriction - and we go from there - the client team will implement - the wallet team want less permissive system and we will get to know where we land Vub - agrees Andrew - Noun nonce and zero nonce #### **Tim: Move forward with the PR to add in Devnet 1** - will be discussed in ACD meeting Ivo @ Ambire My 2c is that no storage restriction is amazing. Huge flexibility for wallet teams, no need to enshrine a contract, And the storage conflicts are a separate issue that always existed. Yes, 7702 makes it easier for it to accidentally happen but this is up to wallet devs to prevent (make implementations that use unique slots) Eilas - Noob question also that i didn’t get an answer for, why is there a keccak in the spec of the new tx type for 7702? It hinders ZK-EVMs Vitalik - it is broader issue - can be a part of the broader move Matt agrees with Vitalik. Ahmad - the wallet developers gather and agree on max flexibility Tim +1 on ERC proxy, if we could have a draft for next week’s call that’d be great