E IP-7702 enables simple Ethereum wallets (EOA) to be upgraded to smart contract wallets, providing greater security, advanced functionality, opportunities for Gas sponsorship, and other benefits. Historically, smart wallets had to be built from scratch, but with the introduction of EIP-7702, traditional wallets can be upgraded and retain all of their assets and on-chain history, while keeping the same wallet address. It's like switching from a landline to a smartphone without getting a new number.
EOA is upgraded by setting a "delegation designation", a pointer to a delegate smart contract, which then delegates the logic of the smart contract to manage the EOA. As a result, the upgraded EOA can have functions, set storage, emit events, and perform all other operations that a smart contract can perform. EOA can change or remove this delegation at any time through a new, signed EIP-7702 authorization. While this unlocks many new possibilities, this powerful feature also introduces new security challenges that require careful consideration and innovative solutions.
To enable EOA to act as a smart contract wallet, we developed EIP7702Proxy, a lightweight ERC-1967 proxy contract designed to be used as an EIP-7702 delegate for EOA. In addition to the basic logic forwarding performed by the proxy, EIP7702Proxy also contains other features and design choices that address some challenges unique to EIP-7702 delegate accounts. One goal of designing EIP7702Proxy is to maintain as much parity as possible between the "standard deployment" Coinbase Smart Wallet and the EIP-7702 delegated Coinbase Smart Wallet, which means abstracting the additional complexity required by the EIP-7702 mechanism into a dedicated proxy and continuing to rely on the original implementation of CoinbaseSmartWallet. The solution to this challenge can be effectively applied to any implementation logic, not just the CoinbaseSmartWallet implementation, while also helping EOA remain secure in a 7702-enabled environment.
Below we describe the specific challenges and corresponding design solutions that allow us to safely adapt any existing smart contract wallet implementation for use with the EIP-7702 upgrade.
Challenge #1: Enforcing secure initialization
The first major obstacle to implementing EIP-7702 comes from its initialization constraints. Traditional smart contract wallets (including CoinbaseSmartWallet) typically handle secure initialization (establishing account ownership) atomically during their deployment through a separate factory contract. This atomicity means that many such implementations have unprotected initializer functions that can only be called once. However, the design of EIP-7702 does not allow initialization calldata to be performed during the code delegation process (the step equivalent to "deployment"), so this cannot be done atomically.
This separation of steps creates a critical vulnerability window. When the implementation contract is "deployed" to the EOA via EIP-7702, there is no guarantee that this 7702 upgrade and the standard EVM transaction to initialize the wallet will execute atomically. Technically, the code that sets the authorization can be applied independently of the initialization transaction even if submitted at the same time, which may allow an attacker to preemptively execute the initialization transaction and claim ownership of the smart account.
Solution: Require EOA signature to atomically set implementation and initialize
Note that the existing Coinbase Smart Wallet is deployed behind an ERC-1967 proxy with a UUPSUpgradeable implementation (the actual CoinbaseSmartWallet logic). The code in the actual account address is a proxy that uses the normal storage locations defined by ERC-1967 to store pointers to its implementation logic. Our solution to the initialization vulnerability in the context of 7702 involves recognizing that any implementation logic only becomes active (and therefore dangerous) when the proxy actually establishes a connection to it. Therefore, if we cannot enforce atomic deployment and initialization, we can enforce atomic implementation setup and initialization.
EIP-7702CoinbaseSmartWallet contract architecture and logic delegation process
In the context of EIP-7702, the EOA itself is the initial permission to make any changes to its account, and a signature must be provided to authorize any owner to initialize and create a new smart account. Our EIP7702Proxy contract implements a setImplementation function that atomically sets a new logical implementation and initializes the account. setImplementation function:
Verify the signature from the EOA, which includes key information such as the address of the new implementation contract, initialization calldata, the address of the validator contract that will evaluate the safety of the final account state, and basic signature replay protections such as nonce and expiration time.
Sets the value of the ERC-1967 indicator to the new implementation and executes the provided calldata against the new logical implementation.
Call the validateAccountState function, which must be implemented by the validator included in the signature.
A validator is an implementation-specific contract that contains logic for evaluating whether it considers a final account state to be safe. For example, for CoinbaseSmartWallet, the CoinbaseSmartWalletValidator will check that the account's ownership state is non-null and therefore no longer vulnerable to arbitrary initialization.
Challenge #2: Shared storage across EIP-7702 delegations
Perhaps the most complex challenge of EIP-7702 is related to storage management. EOAs are free to re-delegate their logic to different contracts at any time, or remove delegation entirely. All delegations share the same storage space at the EOA address. Over time, multiple contracts sharing access to the same storage may lead to "storage conflict" problems. Storage conflicts occur when two contracts make different changes or make different assumptions about the same storage location, which can cause unpredictable errors.
Management of storage conflicts is already a familiar problem in the world of proxy design, where mutable implementation logic is used to manage shared storage. Even though upgradeable proxies can change implementations, the proxy code itself (for non-7702 addresses) cannot change. This brings determinism and guarantees to the upgrade process. 7702 re-delegation introduces another layer of complete mutability to the underlying logic that can manage this shared storage. This essentially removes any guarantees around the effects that arbitrary delegations may have on storage. For example, if an EOA delegates from delegate A to B and back to A again, the returned delegate cannot make assumptions about the state of its storage, and delegate B may have erased or manipulated it into a state that is not achievable through delegate A's logic alone. This is true for any 7702 delegation, regardless of delegation mode, as the previous delegate may have stored or deleted anything at any storage location.
Example of invalid state of delegate A caused by the A → B → A delegation pattern
Solution: Externalization of safety-critical stored values
EOA delegation can arbitrarily affect account state. If an EOA is delegated to a malicious or destructive contract, no incumbent delegate can protect against this. As with signing a drainer transaction, authorizing a malicious7702 delegation can have catastrophic consequences, and protecting against these outcomes is beyond the scope of our design.
We designed EIP7702Proxy to be self-defensive against foreseeable problems in a multi-wallet, 7702-enabled ecosystem of well-intentioned but potentially chaotic actors. It cannot protect EOAs that authorize truly malicious or buggy delegations.
One foreseeable issue involves the signatures of the setImplementation call and the risks posed by mutable account state. EIP7702Proxy relies on EOA signatures to set up the implementation logic and initialize to a secure state. If these signatures can be replayed, they could become a liability. For example, if a signature authorized an initial owner who was later compromised and removed, a replayable signature could re-establish the compromised owner or force a downgrade of the implementation.
A common protection against signature replay is to use a nonce in the signing message and mark it as used after verification. Risk to 7702 accounts: Other delegations may corrupt this nonce tracking storage. If the storage tracking nonce usage is deleted, the EOA's setImplementation signature (which is publicly available in the mempool) can be reapplied when delegating back to the EIP7702Proxy.
To ensure that signatures cannot be replayed, we implemented a separate NonceTracker singleton that maintains nonce state in an immutable contract location outside of the account storage. Only the EOA can affect its nonce (incrementally only), preventing other delegates from manipulating these security-critical values. NonceTracker ensures that each setImplementation signature only works once, regardless of any changes to the account storage.
Challenge #3: Increased risk of sharing traditional storage locations
Standard storage slots like those defined by ERC-1967 are particularly susceptible to potential storage conflicts because they are conventional locations that multiple delegate implementations may use. The ERC-1967 implementation slot is the only standard storage location used in EIP7702Proxy, and it stores the address of the logic implementation that the proxy points to. Our design ensures that regardless of the value of this storage location (which determines most of the logic available in the account), EIP7702Proxy will always be able to successfully set its implementation logic to the contract expected by the EOA.
To more clearly illustrate the problem being solved, note that when an account transitions between different delegations (A→B→A) where both delegations implement the ERC-1967 proxy pattern, delegation B will naturally use the same storage slot that delegation A uses to store its implementation address. During its term, delegation B may modify or overwrite this slot, either intentionally or as a normal part of its own proxy operations. In the UUPSUpgradeable proxy pattern, the logic for upgrading the implementation is defined on the implementation contract itself. If the implementation that delegation B places at this indicator position does not contain the expected upgradeToAndCall interface on the implementation, then when returning to delegation A, the mechanism to change its implementation may not exist in the currently available logic.
Example of new delegation overriding a shared traditional storage location
Solution: Upgrade mechanism available on EIP7702Proxy
Our EIP7702Proxy solves this problem through its setImplementation function, which provides an implementation-independent upgrade mechanism directly on the proxy itself. This ensures that even if an intermediate delegate has pointed the ERC-1967 implementation to an invalid implementation (or removed it entirely), after delegating back to the EIP7702Proxy, the original EOA retains the ability to reconfigure the proxy's ERC-1967 pointer to point to the logical implementation of their choice.
Challenge #4: Backward compatibility with standard EOA behavior
One of the design goals of EIP7702Proxy is to maintain backward compatibility with account EOA functionality in addition to new smart contract functionality. The presence or absence of code on an address affects the execution flow of protocols that interact with that address, as they use this feature to distinguish between EOAs and smart contracts. There are two main behaviors to consider: signature verification and token receipt behavior.
Signature Verification
The signature verification standard for smart contracts is different from that for standard EOAs. Smart contracts implement the isValidSignature interface defined by ERC-1271 and are free to define arbitrary logic to determine whether the contract considers the signature valid. For standard EOAs, the signature is verified via a standard ecrecover check, which ensures that the signer reverts to the expected EOA address.
To ensure that existing or future EOA signatures will continue to be recognized on EOAs after the 7702 upgrade, EIP7702Proxy implements a version of isValidSignature that first delegates signature verification to the isValidSignature function that should be defined on the logic implementation, but if verification fails, a final ecrecover check is performed. If this check passes, the signature is considered valid. In this way, EOAs using EIP7702Proxy can guarantee that simple EOA signatures will always be recognized on their addresses regardless of their smart contract wallet's isValidSignature implementation.
Token Receiving
Some token standards (notably ERC-1155 and ERC-721) attempt to prevent tokens from getting stuck in smart contracts that may not be able to manage them. These tokens require any smart contract that will receive such tokens to advertise this ability by implementing standard token receiver interfaces, which are called by token contracts during token transfers. It is also important that the logic on the upgraded EOA contains a standard receive function or payable fallback to be able to receive the native token. Accounts should not be left in a state where they cannot receive ETH or other tokens, even for a short period of time.
Since our proxy lacks an initial implementation, we include an immutable DefaultReceiver implementation as the default logic for EIP7702Proxy in the absence of an ERC-1967 indicator. This receiver implements the receive function and receiver hooks for these common token standards, ensuring that accounts can accept token transfers before explicitly setting a new implementation.
in conclusion
The EIP7702Proxy design allows us to maintain close alignment with standard deployed CoinbaseSmartWallets and continue to use the existing CoinbaseSmartWallet implementation while addressing the unique security challenges that arise in the context of EIP-7702. By carefully considering initialization security, the impact of storage temporality and interference, the need for uninterrupted token processing, and backward compatibility with standard EOA signature verification, we have built a proxy for securely delegating and managing EIP-7702 smart contract wallets. While EIP7702Proxy was designed with the CoinbaseSmartWallet V1 implementation in mind, this proxy is ultimately implementation agnostic. We encourage developers to evaluate this solution for 7702 protection of other smart contract wallet implementations.
Original link: https://blog.base.dev/securing-eip-7702-upgrades
Denglian Community AI Assistant will translate excellent English articles for you. If there are any inaccuracies in the translation, please forgive me~
Dengchain Community is a Web3 developer community that helps developers become better Web3 builders by building high-quality technical content platforms and offline spaces.
Blockchain community website: learnblockchain.cn
Developer Skills Certification: decert.me
Station B: space.bilibili.com/581611011
YouTube: www.youtube.com/@upchain 
