EIP-7702 enables simple Ethereum wallets (EOA) to upgrade to smart contract wallets, providing higher 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 while retaining all their assets and on-chain history, maintaining the same wallet address. It's like switching from a landline to a smartphone without getting a new number. EOA upgrades by setting a "delegation designation", which points to a delegate smart contract, and then delegates the smart contract's logic to manage the EOA. As a result, the upgraded EOA can have functions, set storage, emit events, and perform all other actions a smart contract can execute. The 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 serve as an EIP-7702 delegate for EOA. In addition to basic logic forwarding executed by the proxy, EIP7702Proxy includes other features and design choices that address some challenges specific to EIP-7702 delegated accounts. One goal in designing EIP7702Proxy was 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 CoinbaseSmartWallet implementation. The solution to this challenge can be effectively applied to any implementation logic, not just the CoinbaseSmartWallet implementation, while also helping to maintain security for EOA in an EIP-7702 enabled environment. Below, we will introduce 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 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 EIP-7702 design does not allow initialization calldata to be executed during the code delegation process (equivalent to "deployment"), thus preventing atomic completion. This step separation creates a critical vulnerability window. When deploying an implementation contract to an EOA via EIP-7702, there is no guarantee that this 7702 upgrade and standard EVM transaction initializing the wallet will execute atomically. Technically, even if submitted simultaneously, the code setting authorization can be applied independently of the initialization transaction, potentially allowing an attacker to front-run the initialization transaction and claim ownership of the smart account. Solution: Requiring EOA Signature to Atomically Set Implementation and Initialize Note that existing Coinbase smart wallets are deployed behind an ERC-1967 proxy with a UUPSUpgradeable implementation (the actual CoinbaseSmartWallet logic). The code at the actual account address is a proxy that uses the standard storage location defined by ERC-1967 to store a pointer to its implementation logic. Our solution for the initialization vulnerability in the 7702 context 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 implementation setting and initialization. In the EIP-7702 context, the EOA itself is the initial authority for any changes to its account and must provide a signature to authorize initialization and establish any new smart account owner. Our EIP7702Proxy contract implements a setImplementation function that can atomically set a new logic implementation and initialize the account. The setImplementation function: - Verifies a signature from the EOA containing key data such as the address of the new implementation contract, initialization calldata, the address of a validator contract that will assess the final account state's safety, and basic signature replay protection like nonce and expiration time. - Sets the ERC-1967 pointer value 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 a contract specific to the implementation that contains logic for evaluating whether it considers the final account state safe. For example, for CoinbaseSmartWallet, the CoinbaseSmartWalletValidator will check that the account's ownership state is non-empty, thus no longer vulnerable to arbitrary initialization. (The translation continues in the same manner for the remaining text)

Challenge 3: Increased Risks of Sharing Traditional Storage Locations

Standard storage slots defined by ERC-1967 are particularly vulnerable to potential storage conflicts, as they are common locations that multiple delegated implementations might 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 switches 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 term, delegate B may modify or overwrite this slot, whether intentionally or as a normal part of its proxy action. In the UUPSUpgradeable proxy pattern, the logic for upgrading the implementation is defined on the implementation contract itself. If the implementation placed by delegate B at this pointer location does not include the expected upgradeToAndCall interface on the implementation, the mechanism for changing its implementation may not exist in the currently available logic when returning to delegate A.

Solution: Upgrade Mechanism Available on EIP7702Proxy

Our EIP7702Proxy addresses this issue through its setImplementation function, which provides an upgrade mechanism directly on the proxy itself, independent of the implementation. This ensures that even if an intermediate delegate has pointed the ERC-1967 implementation to an invalid implementation (or completely removed it), the original EOA retains the ability to reconfigure the proxy's ERC-1967 indicator to point to the logic implementation of their choice after returning to the EIP7702Proxy.

Challenge 4: Backward Compatibility with Standard EOA Behavior

A design goal of EIP7702Proxy is to maintain backward compatibility with account EOA functionality in addition to 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 considering two primary behaviors: signature verification and token receiving behavior.

Signature Verification

Signature verification standards for smart contracts differ from standard EOAs. Smart contracts implement the isValidSignature interface defined by ERC-1271 and can freely define arbitrary logic to determine whether the contract considers a signature valid. For standard EOAs, signatures are verified through the standard ecrecover check, which ensures the signer is recovered to the expected EOA address.

To ensure that existing or future EOA signatures will continue to be recognized on the EOA after a 7702 upgrade, EIP7702Proxy implements a version of isValidSignature that first delegates signature verification to the isValidSignature function defined on the logic implementation, but performs a final ecrecover check if verification fails. If this check passes, the signature is considered valid. This way, EOAs using EIP7702Proxy are guaranteed that simple EOA signatures will always be recognized at their address, regardless of their smart contract wallet's isValidSignature implementation.

Token Receiving

Some token standards (particularly ERC-1155 and ERC-721) attempt to prevent tokens from being 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 standard token receiver interfaces, which are called by the token contract during token transfer. Equally important is that the logic on an upgraded EOA includes standard receive functions or payable fallbacks to be able to receive native tokens. Accounts should not be in a state unable to receive ETH or other tokens, even for a short time.

Since our proxy lacks an initial implementation, we include an immutable DefaultReceiver implementation as the default logic for EIP7702Proxy when the ERC-1967 indicator is missing. This receiver implements receive functions and hooks for these common token standards, ensuring the account can accept token transfers before explicitly setting a new implementation.

Conclusion

The EIP7702Proxy design allows us to remain closely aligned with standard deployments of CoinbaseSmartWallets and continue using existing CoinbaseSmartWallet implementations while addressing unique security challenges in the EIP-7702 context. By carefully considering initialization security, storage transience and interference effects, the need for uninterrupted token handling, and backward compatibility with standard EOA signature verification, we have built a proxy for securely delegating and managing EIP-7702 smart contract wallets. While the EIP7702Proxy design considered the CoinbaseSmartWallet V1 implementation, this proxy is ultimately implementation-agnostic. We encourage developers to evaluate this solution for 7702-proofing other smart contract wallet implementations.

Original Link

Click to Learn About BlockBeats Job Openings

Welcome to Join BlockBeats Official Community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Communication Group: https://t.me/BlockBeats_App

Twitter Official Account: https://twitter.com/BlockBeatsAsia