Original Title: Securing EIP-7702 Upgrades: A Proxy Pattern for Safe EOA-to-Smart Wallet Transitions
Original Author: Amie Corso
Original Compilation: Foresight News
EIP-7702 enables simple Ethereum wallets (EOA) to upgrade to smart contract wallets, providing enhanced security, advanced features, gas sponsorship opportunities, and other benefits. Historically, smart wallets had to be built from scratch, but with the introduction of EIP-7702, traditional wallets can upgrade while retaining all their assets and on-chain history, and maintaining the same wallet address. It's like switching from a landline to a smartphone without needing a new number.
EOA upgrades are performed by setting a "delegation designation," which points to a delegate smart contract, and then the logic of the delegate smart contract manages the EOA. Thus, the upgraded EOA can have functions, set storage, emit events, and perform all other actions that a smart contract can execute. The EOA can change or revoke 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 the EOA to act as a smart contract wallet, we developed EIP7702Proxy, a lightweight ERC-1967 proxy contract designed to serve as the EIP-7702 delegate for the EOA. In addition to the basic logic forwarding of proxy execution, EIP7702Proxy includes additional features and design choices that address some of the challenges specific to EIP-7702 delegate accounts. One goal in designing EIP7702Proxy is to maintain as much equivalence as possible between the "standard deployment" of the Coinbase smart wallet and the EIP-7702 delegate of the Coinbase smart wallet, meaning abstracting the additional complexity required by the EIP-7702 mechanism into a dedicated proxy while continuing to rely on the original implementation of CoinbaseSmartWallet. The solutions to this challenge can be effectively applied to any implementation logic, not just the CoinbaseSmartWallet implementation, while also helping the EOA remain secure in an EIP-7702-enabled environment.
Below, we will outline specific challenges and corresponding design solutions that enable us to safely adapt any existing smart contract wallet implementation for EIP-7702 upgrades.
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 via separate factory contracts. 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 for the execution of initialization calldata during the code delegation process (a step equivalent to "deployment"), making it impossible to complete this action atomically.
This separation of steps creates a critical vulnerability window. When deploying the implementation contract 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, even if submitted simultaneously, the code setting the authorization can be applied independently of the initialization transaction, potentially allowing 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 existing Coinbase smart wallet deployments are 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 conventional storage locations defined by ERC-1967 to store pointers to its implementation logic. Our solution to the initialization vulnerability in the context of 7702 includes recognizing that any implementation logic only becomes active (and thus dangerous) when the proxy actually establishes a connection with it. Therefore, if we cannot enforce atomic deployment and initialization, we can enforce atomic setting of implementation and initialization.
EIP-7702 CoinbaseSmartWallet Contract Architecture and Logic Delegation Flow
In the context of EIP-7702, the EOA itself is the initial authority for making any changes to its account and must provide a signature to authorize the initialization and establishment of any new smart account. Our EIP7702Proxy contract implements a setImplementation function that can atomically set a new logic implementation and initialize the account. The setImplementation function:
Verifies the signature from the EOA, which includes critical data such as the address of the new implementation contract, initialization calldata, the address of the validator contract that will assess the security of the final account state, and basic signature replay protection such as nonce and expiration time.
Sets the value of the ERC-1967 pointer to the new implementation and executes the provided calldata against the new logic implementation. Calls the validateAccountState function, which must be implemented by the validator included in the signature. The validator is an implementation-specific contract that contains logic to assess whether it considers the final account state secure. For example, for CoinbaseSmartWallet, the CoinbaseSmartWalletValidator will check that the ownership state of the account is non-empty, thus no longer vulnerable to arbitrary initialization.
Challenge 2: Shared Storage Across EIP-7702 Delegates
The most complex challenge of EIP-7702 may relate to storage management. EOA can freely re-delegate its logic to different contracts at any time or completely remove the delegation. All delegates share the same storage space on the EOA address. Over time, multiple contracts sharing access to the same storage can lead to "storage collision" issues. Storage collisions occur when two contracts make different changes or assumptions about the same storage location, potentially leading to unpredictable errors.
Managing storage collisions is already a familiar issue in the field of proxy design, where mutable implementation logic is used to manage shared storage. Even if upgradeable proxies can change implementations, the proxy code itself (for non-7702 addresses) cannot change. This provides determinism and guarantees during the upgrade process. The 7702 re-delegation introduces another layer of complete mutability that can manage this shared storage. This essentially eliminates any guarantees regarding the impact that arbitrary delegation may have on storage. For example, if the EOA delegates from A to B and then back to A, the returned delegation cannot make assumptions about its storage state, as delegation B may have erased or altered it to a state that cannot be achieved solely through the logic of delegation A. This is true for any 7702 delegation, regardless of the delegation pattern, as previous delegations may have stored or deleted anything in any storage location.
Example of Invalid State of Delegation A Caused by A → B → A Delegation Pattern
Solution: Externalizing Security-Critical Storage Values
EOA delegation can arbitrarily affect account state. If the EOA delegates to a malicious or destructive contract, no current delegation can safeguard against this. Similar to signing a drainer transaction, authorizing a malicious 7702 delegation could have catastrophic consequences, and preventing these outcomes is beyond the scope of our design. The EXIP7702Proxy we designed aims to be self-defensive against foreseeable issues in a multi-wallet, EIP-7702-enabled ecosystem composed of well-meaning but potentially chaotic participants. It cannot protect the EOA from authorizing truly malicious or erroneous delegations.
A foreseeable issue involves the signatures of setImplementation calls and the risks posed by mutable account states. EIP7702Proxy relies on EOA signatures to set implementation logic and initialize to a secure state. If these signatures can be replayed, they may become burdensome. For example, if a signature authorized an initial owner who is later compromised and deleted, replayed signatures could recreate the compromised owner or force a downgrade of the implementation.
Common protections against signature replay involve using nonces in the signature information and marking them as used after validation. The risk for 7702 accounts: other delegations may disrupt this nonce tracking storage. If the storage tracking nonce usage is deleted, the EOA's setImplementation signature (publicly available in the mempool) could be reapplied when delegating back to EIP7702Proxy.
To ensure signatures are non-replayable, we implemented a separate NonceTracker singleton that maintains nonce state in an immutable contract location outside of account storage. Only the EOA can affect its nonce (only in an incrementing manner), preventing other delegations from tampering with these security-critical values. Regardless of what changes occur in account storage, the NonceTracker ensures that each setImplementation signature only works once.
Challenge 3: Increased Risks of Shared Traditional Storage Locations
Standard storage slots defined by ERC-1967 are particularly susceptible to potential storage conflicts, as they are common locations that multiple delegate implementations may use. The ERC-1967 implementation slot is the only standard storage location used in EIP7702Proxy, which stores the address of the logic implementation pointed to by the proxy. Our design ensures that regardless of the value of this storage location (which determines most of the logic available in the account), EIP7702Proxy can always successfully set its implementation logic to the contract expected by the EOA.
To clarify the problem being addressed, note that when an account transitions between different delegates (A→B→A), where both delegates implement the ERC-1967 proxy pattern, delegate B will naturally use the same storage slot that delegate A uses to store its implementation address. During its tenure, delegate B may modify or overwrite this slot, whether intentionally or as part of its normal proxy operations. In the UUPSUpgradeable proxy pattern, the logic for upgrading the implementation is defined on the implementation contract itself. If delegate B places an implementation at this pointer location that does not include the expected upgradeToAndCall interface on the implementation, then when returning to delegate A, the mechanism for changing its implementation may not exist in the currently available logic.
Example of a new delegate overwriting a shared traditional storage location
Solution: Upgrade Mechanism Available on EIP7702Proxy
Our EIP7702Proxy addresses this issue through its setImplementation function, which provides an upgrade mechanism independent of the implementation directly on the proxy itself. This ensures that even if an intermediate delegate has pointed the ERC-1967 implementation to an invalid implementation (or completely removed it), upon delegating back to EIP7702Proxy, the original EOA retains the ability to reconfigure the ERC-1967 pointer of the proxy to point to the logic implementation of their choice.
Challenge 4: Backward Compatibility with Standard EOA Behavior
One design goal of EIP7702Proxy is to maintain backward compatibility with the account EOA functionality in addition to the new smart contract features. The presence or absence of code at an address affects the execution flow of protocols interacting with that address, as they use this characteristic to distinguish between EOAs and smart contracts. This requires consideration of two main behaviors: signature verification and token reception behavior.
Signature Verification
The signature verification standards for smart contracts differ from those for standard EOAs. Smart contracts implement the isValidSignature interface defined by ERC-1271 and can freely define any logic to determine whether the contract considers the signature valid. For standard EOAs, signatures are verified through the standard ecrecover check, which ensures that the signer is recovered to the expected EOA address.
To ensure that existing or future EOA signatures continue to be recognized on the EOA 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, it performs a final ecrecover check. If this check passes, the signature is considered valid. In this way, EOAs using EIP7702Proxy can be assured that regardless of how their smart contract wallet's isValidSignature implementation is defined, simple EOA signatures will always be recognized at their address.
Token Reception
Some token standards (particularly 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 receiving such tokens to declare this capability by implementing the standard token receiver interface, which is called by the token contract during the token transfer. It is equally important that the logic on the upgraded EOA includes standard receive functions or payable fallback functions to be able to receive native tokens. Accounts should not be in a state where they cannot receive ETH or other tokens, even for a brief period.
Since our proxy lacks an initial implementation, we included an immutable DefaultReceiver implementation as the preset logic for EIP7702Proxy in the absence of the ERC-1967 pointer. This receiver implements the receive function and the receiver hooks for these common token standards, ensuring that the account can accept token transfers before explicitly setting a new implementation.
Conclusion
The design of EIP7702Proxy allows us to remain closely aligned with the standard deployment of CoinbaseSmartWallets while continuing to utilize the existing CoinbaseSmartWallet implementation, all 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 handling, and backward compatibility with standard EOA signature verification, we have established a proxy for securely delegating and managing EIP-7702 smart contract wallets. While the design of EIP7702Proxy takes into account the CoinbaseSmartWallet V1 implementation, this proxy is ultimately independent of the implementation. We encourage developers to evaluate this solution for providing 7702 protection to other smart contract wallet implementations.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
