Exploring EIP-7702
Future-proofing EOA superpowers and enabling permissionless innovation
Over the last few weeks, EIP-3074 has been seriously and widely debated in the account abstraction ecosystem. The EIP was flagged for inclusion in Pectra, starting development for devnets, dev tooling support, prototyping and debates around the standard. One core debate focused on its impact on the account abstraction roadmap and on existing account abstraction designs, most notably ERC-4337.
Yesterday, Vitalik proposed EIP-7702 which aims at a similar goal as EIP-3074 but has a different implementation. Notably, it seems more aligned with the account abstraction roadmap, existing infrastructure as well as proposals, including RIP-7560.
Overview of the EIP
EIP-7702 takes inspiration from EIP-5806 and proposes a new transaction type, during which the contract of a list of EOAs can be set with the provided code relevant to each EOA. In practical terms, it means that on top of the existing fields of a tx, an array is provided, which includes a contract code and signature per element. When executing this tx type, a client would loop over this array, recover the EOA address for each signature, and set the code of this EOA to the provided contract code. At the end of this transaction, the code of all of the EOAs provided is removed. The proposal does not require any of the EOAs provided to be the transaction origin, making it compatible with relayers, including ERC-4337 bundlers.
How does it differ from EIP-3074
EIP-3074 introduces two new opcodes, AUTH and AUTHCALL. On a high level, AUTH recovers the signature of an EOA and, if successful, sets a context variable that allows for AUTHCALLs to happen. AUTHCALL executes a call that is, in most respects, similar to the normal CALL opcode but uses the recovered EOA address as the message sender. This means that an EOA can give a so-called invoker contract permission to execute calls that originate from that EOA.
Both proposals have the same goal: to give EOAs the ability to execute code. EIP-3074 achieves this by allowing a contract to execute calls with the EOA address as the message sender. EIP-7702 achieves this by setting the code of the EOA for the context of a transaction. Thus, the latter is almost completely compatible with existing smart accounts since a user can just sign over their code using their EOA and have that code live under the EOA address for the scope of a transaction. By contrast, EIP-3074 requires rebuilding existing smart accounts to use the proposed opcodes (as discussed in a prior blog post).
Why it is more aligned with the account abstraction roadmap
Currently, the account abstraction roadmap on Ethereum depends on ERC-4337 and (in the future) RIP-7560. The core focus of both of these proposals is censorship resistance and decentralized relaying. One key factor in this pursuit is the separation of validation from execution. However, with EIP-3074, validation (using AUTH) is tightly coupled with execution (using AUTHCALL), making it harder, but not impossible, to decouple these from each other. By contrast, EIP-7702 does not have such a restriction and is entirely un-opinionated towards the design of the smart accounts.
Longer term, the goal of the account abstraction roadmap is to move all users onto smart accounts, some of which will need to happen through permanent migration from EOAs to smart accounts. The way this would likely occur in an EIP-3074 world is with EIP-5003. This extension adds another opcode, AUTHUSURP, which allows contract code to be permanently deployed to an EOA address without code. In EIP-7702, migration could be implemented much simpler, potentially making it as easy as adding a flag to the signed data.
A clear path to permissionless innovation
In our prior blog post, we discussed invoker whitelisting by wallet vendors as the most restrictive element to the design space around EIP-3074. In short, if a dapp wishes to build new product features that require a novel invoker contract, they must have the contract whitelisted by all relevant wallet vendors.
Our proposed solution to this problem was a modular invoker that borrows from the research and development around ERC-7579 and/or ERC-6900. This would allow for one or a few highly secure and trusted modular invoker implementations that are universally whitelisted and extended by any developer via a module. A permissioning and security system borrowed from the modular account abstraction space would then allow for the permissionless development of invoker features.
EIP-7702 creates a simple means of directly adopting the existing modular account abstraction solution to unlock permissionless UX innovation with EOAs. It ensures backward compatibility with existing modular smart account implementations and all the tooling and infra being built around modular smart account standards.
One further upside of EIP-7702 is that it makes it far easier to build an application that uses smart account features like batching, sponsorship, session keys, and more for both EOA and smart account users. While this is to some extent also true for EIP-3074, an application would likely have to go through more effort to become compatible with both. In the worst case, this means that dapp developers might choose to only support one or the other, creating fragmentation for users, essentially forcing them to have both an EOA and a smart account that needs to be used depending on the application.
Open questions
In-protocol revocation
EIP-3074 initially did not include a way to revoke AUTH signatures in the protocol. Having this in the protocol means that even when an invoker becomes malicious or has some sort of bugs, it would be possible to revoke the signature. After input from the community, the proposal was amended so that the EOA nonce and chainid would also be signed over. Nonetheless, this change still sparked a lot of debates.
EIP-7702 currently includes no in-protocol revocation mechanism, but there are some suggestions to include it. However, one downside of this is the need to pick a specific mechanism for this, for example, the account nonce, a maximum nonce, a nonce manager, or another mechanism. One problem with this is that it essentially requires picking and sticking with one of these proposals rather than allowing account developers to choose how this is done. Because of this, we believe that the proposal should remain un-opinionated and retain flexibility.
Storage
EIP-5806 prohibits the usage of the SSTORE opcode in the context of the EOA address. One reason for this is that if an EOA can eventually be upgraded, there might be already-set storage which could lead to unexpected behavior. Because of this, we believe that a similar restriction would make sense for EIP-7702. This would entail that smart accounts would need to be re-written so that their storage lives in an external contract. However, this would not be majorly complex and we have already prototyped an example for this.
Permanent upgrade
One further idea suggested by Vitalik is to add a flag to the transaction data to permanently upgrade an EOA to a smart account. Practically, a client could just check if this flag is set and not remove the code at the end of the transaction if it is set. One further idea is that even if this flag is not included in the Pectra hard fork, the fact that it would be minimal effort to include in a client could mean that rollup clients might experiment with this feature and add it before it is added on Ethereum.
Conclusion
EIP-7702 is more aligned with the account abstraction roadmap and is less likely to cause tech debt for Ethereum clients and protocols built on top. As a result, we see it is a strictly better version of EIP-3074, given that it achieves the same aims in a more elegant and future-proof way. There remain some open questions on the standard so it makes sense to keep exploring its implications but it seems likely that it would remain a better way forward for EOA UX that is also aligned with the smart account ecosystem. This entails that EIP-7702 is also more likely to lead us to a future where permissionless innovation is possible for both EOAs and smart accounts and not just the latter.
