In other places in the protocol, a full uint256 chain ID is supported.
A large chain ID like that can be chosen by hashing some state and/or configuration, enabling the idea of a “counter factual chain identity”: a chain instantiation bound to its usage rules. For future more ephemeral chains this is ideal, as a user does not need a central registry to update to attach specific rules or configuration, those can be proven against the chain ID instead.
And this can expand into neat protocols where the user signs transactions in advance, and the chain is only instantiated when certain conditions are met, exactly with the rules and pre-state as committed to by the chain ID.
This can also be a big part of making chain configurations more interoperable and chain-instances more elastic, as there is no need for a central registry to register the chains in a uint64 namespace.
Disclaimer: I did not come up with these chain ID schemes, these things go back as far as 2018 comments on ethresearch sharding threads, likely earlier. @vbuterin might be able to share some history about the general idea.
Can we please revert this chain_id size limit in EIP 7702, and support full uint256 chain IDs in the auth list?
The fact that this is actually an anti-goal of yours I find very odd.
It was many times raised that the migration path this provides is riskier for users and presents barriers to adoption. It also rules out entire classes of experiences without justification, in my opinion.
The fact that there are experimental wallets that demonstrate some of this functionality does not invalidate the point that there will be a proliferation of standards and necessary adoption of such (more complex, fragmented) wallets before apps can benefit.
I’m not sure why wallet teams are the only voices which matter here. In listening to breakout sessions #5 and #6, it seems there was actually fairly widespread interest in the ephemeral flag. I heard repeatedly comments from @derek, @g11in and a number of others comments along similar lines, that as far as I can tell were never really addressed. I also heard @adietrichs say that ephemeral would be really desirable, if not for the problem of auth tuples being picked up without the user op.
Therefore, I would instead like to focus on a specific concrete proposal to modify the EIP and potentially solve the issues with it:
Add a transient (ephemeral) flag to the authorization tuple: if transient is set, clear the delegation after execution
Have each signature include the calldata in addition to the other fields of the authorization tuple
I believe this would have the following benefits:
Full Compatibility: These updates maintain all existing functionalities, ensuring that those currently satisfied with EIP-7702 face no disruptions
Robust Security: By binding authorizations tightly to transaction data, we protect against misuse and unauthorized transactions
Single Signatures: Supports both current users and newcomers, facilitates broader and more efficient integration, and allows for graceful adoption
Low Implementation Impact: The required changes are minimal and designed for easy integration with the existing system, minimizing development overhead
I would appreciate first and foremost any feedback on the efficacy of the proposal, before dismissing it out of hand due to potential philosophical differences.
Please feel free to raise your concerns on ACD and with other developers. I don’t find your arguments sufficient to modifying the current behavior of the EIP.
Thanks for letting us know. I had a feeling there were some people hoping to use this functionality but I didn’t know about the counter factual chain identity proposals when we discussed the size. I’m happy to make this change.
I share the goal of improving user experience and enabling new capabilities on Ethereum. However, I believe the current form of EIP-7702 could have far-reaching structural consequences that undermine the protocol’s decentralized ethos. By placing critical delegation and batching functionalities into the control of wallets, rather than making them available at the protocol-level, the proposal risks recreating the gatekeeper dynamics we have worked so hard to avoid in the transition from web2 to web3. This could stifle open innovation, raise barriers for independent developers, and concentrate power in ways reminiscent of major app stores and browsers in the legacy web.
As an app developer, I want to express my support for the points that @jflatow is raising here.
My Core Concern:
The heart of the issue is that EIP-7702 risks turning wallets into gatekeepers. Instead of offering these capabilities as a neutral, protocol-level primitive accessible to all developers, the current design may effectively hand control over important functionality to a small set of wallet providers. This consolidation of power could mirror the way Apple’s App Store or major web browsers control user access and developer integration, creating incentives for these wallet providers to lock in developers, restrict access, and extract rents.
You mention that users can update the code they delegate to, ensuring they retain ultimate control. However, it’s unclear what mechanisms guarantee that this remains simple and permissionless in practice. Given strong economic incentives, large wallet providers might have every reason to discourage easy switching or to wrap these capabilities in proprietary contracts. Without a neutral, protocol-level guarantee, we’re left hoping that private actors “promise not to do wrong” rather than being sure they “can’t do wrong.”
When you push the features of this EIP to smart contract wallet developers (features that every app developer wants) you are actually trusting them to govern access fairly and, in the process, are relinquishing control. In the absence of gatekeeping, these features could enable dapps to compete and innovate freely. I think we should consider what’s happened historically when such gatekeeping structures are present.
If we enable “ephemerality” for app developers at the protocol-level they will not be beholden to private actors and/or forced to interact through smart contract wallet interfaces, which is an essential counterbalance. I strongly believe we should pursue a balance of powers and ensure that EIPs do not introduce market structures that recreate systems of leverage that led us to create blockchain in the first place.
I do not share concerns about the ease of integration for dapps. Rather, I worry that key functionalities—fundamental building blocks of the user experience—will be controlled by wallets rather than directly accessible at the protocol layer. This could create a stratified market where developers who want to offer sophisticated features must integrate with whichever wallet providers dominate. In effect, this reduces the agency of dapp developers and could stifle open competition and experimentation.
One thing I’d like to point out is that EIP-7022 will likely not prevent people from doing this. It’s important to acknowledge that there are teams exploring session keys, scripting, and other advanced capabilities in smart contract wallets. If the community’s endgame is to embrace such complexity, why not do it in a way that preserves Ethereum’s core values—neutrality, openness, and permissionless innovation?
As an app developer, I feel strongly about this topic. I think it is important that we hear the voice of the app developer community before creating a change that could have a multi-year impact due to the structural implications of this EIP.
Thank you for considering my perspective and I look forward to discussing this more with the community!
Permissionless: I believe this is extremely clear. If a wallet is self-custodial, it’s always possible to remove a delegation or set a new one, without asking for permission from the wallet provider. It only takes one simple on-chain transaction signed by the EOA key, which the user should possess if the wallet is self-custodial. If the user doesn’t possess this key, EIP-7702 is not the reason for their lock-in.
Simple: This may be less clear, as there is quite a bit of technical nuance.
Removing a delegation is maximally simple: one transaction that erases the delegation designator from the account.
Migrating to new account code is on the surface simple, but doing it in a secure way may or may not be simple depending on the way the account has managed the account storage. I’m proposing a new section in the EIP security considerations to explain this, summarized below.
If the account code followed EIP-7702 best practice with respect to storage and used something like EIP-7201 and Solidity’s upcoming layout location feature, the migration is safe to do in one transaction that simply redelegates to the new code.
If the account code did not follow best practice, the migration may not be safe and should be preceded by clearing the account storage. This storage clearing can be implemented by a third-party (i.e., it doesn’t need to be done by the original wallet provider) as a kind of delegation target dedicated to this purpose. Once this is done the new account code can be installed.
Regarding market structure, I’d like to draw an analogy to Ethereum’s application-layer ERC-20 standard versus the built-in token primitives that some other blockchains provide. You could make the same argument against Ethereum’s approach in this case. Paraphrasing from your post:
Instead of offering these capabilities as a neutral, protocol-level primitive accessible to all developers, the current design may effectively hand control over important functionality to a small set of wallet providersasset issuers.
This has not happened. ERC-20 has been successful, as have other application-layer standards. EIP-7702 is following a similar philosophy: minimal but very general features at the protocol layer, complemented by application-layer standards.
We should now be working on those standards and best practices. I suggest looking into EIP-5792 and contributing to its development and adoption.
I acknowledge that, from a purely technical standpoint, it’s permissionless to change the delegated code with a single transaction. However, my concern is less about the mechanism and more about the practical dynamics that will emerge under the current design of EIP-7702.
In practice, what guarantees that wallet providers will expose the full spectrum of this capability in an accessible way in their UIs? Most users rely on a wallet’s UI rather than directly signing transactions with raw keys. If these wallet interfaces fail to offer a clear and easy path to update or remove delegations, the “permissionless” feature risks becoming moot. It’s similar to how users rarely switch from Chrome to Chromium—they technically could, but the friction and lack of convenient alternatives often discourages it.
Without the ability to include calldata and set an ephemeral flag, I find this very unlikely. This is because, in the current state of the EIP, it is impossible to know what the EIP-7022 transaction will do once signed. In other words, if wallets cannot fully simulate or verify the effects of a 7702 transaction, they may feel compelled to restrict access, effectively gatekeeping a critical piece of functionality. This is my central point of concern: the current EIP design, unintentionally, may encourage a market structure where wallets hold the keys to essential, protocol-level features that should be broadly available.
I actually fully agree with the simplicity of the technical implementation and process. I believe you are correct. Again, I think, due to the lack of a calldata or ephemerality field, that wallet UIs will not allow this.
I appreciate the analogy and understand the point you are making here. However, I do think these are two very different standards and capabilities.
In the case of ERC-20, the community was setting a standard interface for fungible tokens at the app layer. It didn’t force developers to rely on a small set of intermediaries to achieve core token-related functionality. In contrast, EIP-7702, as currently specified, risks making fundamental execution capabilities—like batching and code delegation—indirectly dependent on wallet providers’ cooperation. Put another way, ERC-20 didn’t necessitate the need for further standards to emerge on top for developers to access the core functionality of what ERC-20 offered in the first place. In effect, we are creating an upstream dependency to access a down stream protocol-level capability that is EIP-7022, which few other ERCs have done.
A closer analogy might be if delegatecall were only accessible through certain approved proxy contracts. Such a restriction would concentrate power and introduce a form of gatekeeping that is inconsistent with Ethereum’s ethos of open-access primitives.
I also totally agree here. In this vein, I really believe we should add the simple flexibility of setting an ephemeral flag and let users sign a specific calldata. This change makes EIP-7022 a more general, protocol layer feature. This also lets the application-layer decide on whether wallets should standardize at the app layer or if apps should have access to this, as well, through complementary developments.
I believe it’s important to involve the app developer community more directly in this discussion. Their perspective is essential because they will ultimately build on top of whatever transaction and account model we standardize. We should not overly rely on a single class of stakeholders—like wallet providers—when deciding how to introduce core protocol capabilities.
Please let me know if any of my points resonate! I look forward to discussing further.
This isn’t a limitation of the EIP but a consequence of turing completeness. Including calldata and an ephemeral flag doesn’t change that fact. Simulating a transaction doesn’t give you a complete account of what it might do, so even with those additional capabilities to know what an EIP-7702 transaction would do requires an analysis of the contract code that is in general intractable.
Sorry I’m not engaging with all of your points but this concern has already been discussed throughout the year. Many people from different communities have been involved in the process.
That is a fair point with regard to Turing completeness. However, I do think the point still stands of gating this access behind smart contracts as opposed to letting app-developers more freely leverage the feature set.
Would greatly appreciate how the community has addressed the above questions regarding how realistic we think it is that wallets will allow people to easily switch and issue 7702 transactions? Has this been discussed?
I also think the features above only add flexibility and can power all of the wallet use-cases, in addition to app-level capabilities.
@frangio one thing I wanted to inquiry about, as well, is how do we aim to allow protocols to have access to these features? That is, programmability within the context of an EOA? Is it expected that all accounts will adopt modular standards that enable protocols to have access to these features?
EOA wallets can gatekeep today but they don’t. They could easily disallow users from using dapps they don’t have partnerships with. They also allow you to export your private key to use elsewhere.
Hey, I was going through this EIP recently and got confused about the impact on the mempool of clients.
As mentioned in the “Security considerations → Transaction propagation”:
With this EIP, it becomes possible to cause transactions from other accounts to become stale. This is due to the fact that once an EOA has delegated to code, that code can be called by anyone at any point in a transaction. It becomes impossible to know if the balance of the account has been sweeped in a static manner.
While there are a few mitigations for this, the authors recommend that clients do not accept more than one pending transaction for any EOA with a non-zero delegation designator. This minimizes the number of transactions that can be invalidated by a single transaction. Another alternative would be to expand the EIP-7702 transaction with a list of accounts the caller wishes to “hydrate” during the transaction.
This EIP makes it impossible for mempool to statically analyze the validity of an incoming transaction because it is unknown whether other pending transactions will decrease the balance of the incoming transaction’s sender.
Mitigation is recommended in the EIP that clients do not accept more than one pending transaction for any EOA with a non-zero delegation designator. However, it is still possible that attackers may leverage lots of different EOAs with non-zero delegation designators to populate the mempool with lots of later-to-be-found invalid transactions at the EVM execution stage.
Mempool is usually of limited capacity. It is possible to overwhelm the mempool with large amounts of malicious, later-to-be-found invalid, transactions and make the client have to discard other valid transactions from the mempool (suppose the malicious transactions have higher priority than other valid ones, by, e.g., priority fee). The client under attack may end up not being able to include sufficient transactions in the proposed block, wasting the block space. This can happen both in a client that serves RPC accepting transactions or receives transactions from other P2P nodes.
I believe making mempool unable to statically verify the validity of transactions is in general an undesired change and opens the gate for DoS attacks. This may have a more severe impact than expected.
Hey, I was going through this EIP and noticed that the destination field in EIP-7702 seems to serve the same purpose as the to field in other transactions. I’m curious about the rationale behind using a different term (‘destination’)? since it takes a bit of time for me to figure out this field, not sure if it’s a common problem for readers.
About the three use cases of require(msg.sender == tx.origin) checks,
Examples of (1) and (2) can be found in contracts deployed on Ethereum mainnet, with (1) being more common (and unaffected by this proposal). On the other hand, use case (3) is more severely affected by this proposal, but the authors of this EIP did not find any examples of this form of reentrancy protection, though the search was non-exhaustive.
How are these statistics done? If any, could you kindly share the scripts used to search for smart contracts with these three different use cases? This will be quite helpful for other EVM-compatible chain teams considering implementing this EIP, as they also want to check if this EIP will break smart contracts on their networks.