# [EIP-7702] The Rubber Stamp-ening

### Introduction

EIP-7702, scheduled for inclusion in the Pectra hard fork (Q1 2025), is arguably the most powerful Account Abstraction proposal for Ethereum to date. While the EIP was first drafted only 3 months ago, it has seen significant changes over its lifetime and has attracted impassioned debate from across the ecosystem.

The current version of EIP-7702 (thanks to the work of Matt Garnett, aka lightclient, and many others) is an elegant revision of the original proposal that solves almost all concerns—notably in-protocol revocation for EIP-7702 delegations. However, additional counter-proposals have started to emerge that aim to radically and unnecessarily alter the EIP.

### The EIP Process

Ethereum is decentralized by design, with no central-planning body—no one “owns” the EIP process. This is undoubtedly a good thing, but it means reaching consensus can be very difficult. Of course, there is nothing stopping contributors from presenting new proposals to replace existing ones. However, counter-proposals may have drawbacks—they:

- may be written by a single organization or small group, resulting in narrow proposals that don’t represent the needs of the broader ecosystem
- may not actually solve outstanding issues with existing proposals
- may open up new unsolved issues
- may reset timelines, making inclusion schedules infeasible
- are subject to counter-counter-proposals which further draw out the process

In the context of EIP-7702, it’s clear that many, if not all, of the above drawbacks apply to the circulating counter-proposals. Meanwhile, the current version of EIP-7702 is certainly the most viable version yet for inclusion on mainnet.

Ideally, through the EIP process, developers should propose features that appeal to as much of the ecosystem as possible, then attempt to solve any outstanding security or usability issues that that the proposal may have. However, with EIP-3074 and now EIP-7702, contributors have tended to spawn entirely new EIPs to solve outstanding issues instead of settle on one, then optimize.

We believe the community has two options at this point:

1. Support the current version and participate in the discussions to address any remaining issues
2. Push for new versions and see no Account Abstraction functionality land in Pectra

Of course, we are in favor of choosing the first option. If we allow the development of EIP-7702 to be bogged-down by a never-ending stream of counter-proposals, the inclusion of this functionality will get pushed back indefinitely and will deprive the ecosystem of this powerful feature until at least the next hard fork. We should instead take a hard look at the few remaining concerns and resolve them to the best of our ability.

### In-Protocol Revocation

The first version of EIP-7702 did not have a way for EOAs to revoke a smart contract delegation. This meant that once an EOA delegated to a smart contract, calling that contract in the context of the EOA was valid in perpetuity. This was very undesirable since the EOA could accidentally delegate to a buggy or malicious contract and have no way to block that contract from operating in its context. The current version solves this issue by enforcing a “one-delegation-at-a-time” policy for EOAs and making it so delegations persist beyond the initial transactions that set them. If an EOA delegates to a buggy or malicious contract, they can now delegate to a new implementation, or if they want to return to being a pure EOA, they can simply delegate to the zero address or their own address.

### DoS Attack Resistance

A criticism of the current EIP-7702 spec has been that it is open to mempool denial-of-service (DoS) attacks. However, this attack can be mitigated by lowering the maximum number of pending EIP-7702 transactions in the mempool to 1. This would guarantee that hybrid EOAs could have at most 1 transaction invalidated per block. Complementary proposals to further mitigate this issue are in progress and should be considered as they come.

### Shared Storage Mitigation

One novel issue that EIP-7702 introduces is shared EOA storage. Smart contracts each have their own storage areas, and EOAs traditionally do not have storage. With EIP-7702, delegations can now use the EOA’s storage, however every delegation has this same ability; the EOA’s storage can be used by whatever delegation is currently active including storage that was set by a previous delegation. This could be problematic if say: delegated contract A writes state variables to EOA storage, then the EOA delegates to contract B which also writes state variables to EOA storage, then the EOA re-delegates to A which now has its state variables corrupted.

There have been a number of recommendations for namespacing storage, however none of these recommendations address the fact that the entire storage trie is accessible to any active delegation contract. To successfully separate EOA storage by delegation, Ethereum’s storage trie would have to be modified. This would be too large of a change considering EIP-7702 was designed to avoid major changes to the VM.

Having unrelated smart contracts access the same chunk of storage (albeit at different times) adds complexity to security reasoning, however there are mitigations for this issue that can be implemented at the application layer, i.e. using external storage contracts, always (re-)writing state variables at the time of delegation, etc. This is the most practical solution and wouldn’t require any major changes to the VM.

### User-friendly Security Model

EIP-7702 creates a new hybrid between EOAs and smart contracts. It’s critical that users understand the implications of this. Specifically, the changes should not lead users to believe their private keys have been “retired” and no longer need to be kept secret. If EIP-7702 allowed EOAs to “permanently” upgrade to SCAs or if it enforced an “EOA-or-SCA-only” policy, this could lead to confusion over the status of user private keys.

The current version of EIP-7702 hits the functionality-and-security sweet spot. It makes it clear that EOAs are able to delegate to smart contracts for as long as they want, but always remain traditional EOAs at their core.

### Conclusion

The work to get EIP-7702 ready for mainnet is not yet over. Gas scheduling, for one, needs further attention, and other minor changes to the EIP will likely need to be made. However, any movement to abandon or radically alter this EIP at this point would be doing us all a disservice. As we’ve discussed, the current version of EIP-7702 enables incredible functionality, addresses core issues, and does this in an open, non-prescriptive way. In short, let’s not throw the baby out with the bathwater; let’s address any straggling issues head-on and bring this long-awaited feature to users.