Ensuring Ethereum EIP-7702 Upgrade: A Secure Proxy Model for Transitioning from EOA to Smart Wallet

We developed EIP7702Proxy, a lightweight ERC-1967 proxy contract designed to serve as the EIP-7702 delegate basic logic forwarding for EOA... that addresses some of the challenges unique to EIP-7702 delegated accounts. This article is from an article written by the Boardlink community and is compiled, compiled and contributed by ForesightNews. (Synopsis: Ethereum Pectra upgrades "hacker flip", Wintermute warns: EIP-7702 automates the deployment of a large number of contracts) (Background supplement: Ethereum Foundation's "One Trillion Dollar Security Project" releases first report: Sorting out smart contracts, infrastructure and cloud security... Six Ecological Challenges EIP-7702 enables simple Ethereum wallets (EOAs) to upgrade to smart contract wallets, providing greater 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 be upgraded and keep all their assets and on-chain history, with the same wallet address. It's like switching from a landline to a smartphone without having to get a new number. EOA is upgraded by setting up a "delegation designation", i.e. a pointer to a delegate smart contract, and then delegating the logic of the smart contract to manage EOA. As a result, an upgraded EOA can have functions, set storage, emit events, and perform all other operations that a smart contract can perform. The EOA can change or delete this delegate at any time with 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 serve as an EIP-7702 delegate for EOA. In addition to the basic logical forwarding performed by the agent, EIP7702Proxy includes additional features and design choices that address some of the challenges unique to EIP-7702 delegated accounts. One goal of designing EIP7702Proxy is to maintain as much peerability as possible between a "standard-deployed" Coinbase smart wallet and an EIP-7702 delegated Coinbase smart wallet, which means abstracting the additional complexity required for 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 stay secure in a 7702-enabled environment. Below we present specific challenges and corresponding design solutions that allow us to securely adapt any existing smart contract wallet implementation for EIP-7702 upgrades. Challenge #1: Enforcing Secure Initialization The first major hurdle 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, typically 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 equivalent step of "deployment"), so this cannot be done atomically. This separation of steps creates a critical vulnerability window. When the implementation contract is "deployed" to EOA via EIP-7702, there is no guarantee that the standard EVM transaction for this 7702 upgrade and initialization wallet will be executed atomically. Technically, even if committed at the same time, the code that sets the authorization can be independent of the initialization transaction application, which may allow an attacker to preemptively execute the initialization transaction and claim ownership of the smart account. Solution: EOA signature is required to atomically configure implementation and initialize Note that the existing Coinbase smart wallet is deployed after the ERC-1967 proxy with the UUPSUpgradeable implementation (the actual CoinbaseSmartWallet logic). The code in the actual account address is a proxy that uses a regular storage location 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 becomes active (and therefore dangerous) only when the agent actually establishes a connection to it. So if we can't force atomicity deployment and initialization, we can force atomicity implementation setup and initialization. EIP-7702CoinbaseSmartWallet Contract Structure and Logical Delegation Process In the context of EIP-7702, the EOA itself is the initial authority to make any changes to its account, and a signature must be provided to authorize any owner who initializes and establishes a new Smart account. Our EIP7702Proxy contract implements a setImplementation function that atomically sets up new logical implementations and initializes accounts. setImplementation function: Verifies the signature from EOA, which includes key data such as the address of the new implementation contract, initializing calldata, the address of the validator contract that will evaluate the security of the final account state, and basic signature replay protection such as nonce and expiration time. Set the value of the ERC-1967 pointer to the new implementation and execute the provided calldata against the new logical implementation. Call the validateAccountState function, which must be implemented by the certifier included in the signature. A validator is an implementation-specific contract that contains logic to evaluate whether it considers the final account state secure. For example, for CoinbaseSmartWallet, CoinbaseSmartWalletValidator checks if the ownership status of the account is non-empty and is therefore no longer vulnerable to arbitrary initialization. Challenge #2: Shared Storage Delegated across EIP-7702 The most complex EIP-7702 challenges may be related to storage management. EOA is free to re-delegate its logic to a different contract at any time, or delete the delegate entirely. All delegates share EOA addresses on...