EIP-7702 introduces a new Ethereum transaction type, “Type 0x04,” also known as the “set code” transaction. This transaction allows Externally Owned Accounts (EOAs) to temporarily adopt smart contract-like behavior by dynamically assigning executable code.
The tech behind EIP-7702
EIP-7702 enables EOA owners to sign a delegation designator, an address containing executable code that their EOAs temporarily adopt. The delegation designator allows an EOA to inherit the contract code from a designated address while maintaining its own state. Any CALL operation directed at the EOA will execute the code from the delegate address, while preserving the original EOA's storage and context.
This mechanism bridges the gap between EOAs and smart contracts. Without it, EOAs didn’t have their own state or code. With EIP-7702, they will have their state and borrow the code from an existing contract, chosen by the delegation designator.
This delegation will not completely transform an EOA into a smart contract, leaving a few key distinctions:
- The delegated EOA can still initiate transactions and smart contracts can’t.
- The EOA can change or remove the delegation designator at any time.
- The EOA private key retains full control of the address, in addition to any control set up by the code.
How EIP-7702 impacts everyday users
Once EIP-7702 is implemented on production networks, it will give EOAs almost all contract features. Easier transition to smart wallets and account abstraction is the main benefit, allowing EOA users to:
- Batch operations: Users will be able to batch complex operations inside one transaction that would otherwise require multiple transactions.
- Sponsor transactions: EOA users will be able to use a paymaster to cover the gas cost of their operations, meaning they will no longer have to hold native currency. The paymaster could be compensated in some other onchain asset such as an ERC-20 token or even with an offchain deal.
- Issue sub-keys: EOA users will be able to create special keys with a limited scope. For instance, they could access only a fraction of the funds held by the EOA. The EOA owner will be able to set any other limitations, such as restricting the types of tokens or the time the key can operate in, etc.
- Enhance safety: EOAs can now have recovery or safety features built into their logic. Recovery mechanisms can be set up if the EOA private key is lost, allowing the funds to be recovered.
- Simplify asset migration: By pointing the delegation designator to an existing smart contract wallet, users can move away from pure EOAs to smart contract wallets. Without EIP-7702, moving assets to a smart contract wallet is a complex and gas-intensive process. So, instead of moving funds from an EOA to a smart contract wallet, EIP-7702 allows you to move the smart wallet code to the EOA.
- Support adoption: Paired with the efficiency and scalability of L2 solutions, this improvement can further facilitate adoption and create seamless onchain experiences. Migrating to smart contract wallets on L2s is cost-efficient since gas prices are usually low. EIP-7702 further simplifies this process, bringing greater flexibility and improved user experience.
The road to “true” native account abstraction
EIP-7702 brings significant changes to the ecosystem, but there’s still a long road to “true” native account abstraction. EOA private keys are one of the obstacles on that road.
Even after creating a delegation designator, the private key still has all the privileges and can run any transaction for the EOA. This fact has some implications for delegated EOAs:
- A stolen private key can’t be disabled. The only way to recover from it is to have a way to transfer the funds out of the wallet.
- EOAs with only EIP-7702 changes can never truly be trustless multisig wallets since the original private key has full control and, therefore, needs to be trusted.
- Delegated EOAs can never be trusted to lock funds or act in a certain way since they can either change their delegation or initiate a malicious transaction with their private key.
So, the perfect scenario would be that every new account is a smart account with its own code. One possible way to solve this problem is to have a default delegation for each new account. The delegation designator could then point to a smart contract that has code in place to handle communication with a gas paymaster and verify signatures.
This would allow for flexibility in removing the private key authority by changing the signature check to another system (possibly a quantum safe, multisig, or any other type imaginable). To address these issues, the future of native AA will require new EIPs.
Step in the right direction
Although native account abstraction still isn’t completely supported, EIP-7702 is an excellent step in the right direction. It will bring an unprecedented, smooth experience to many users by allowing EOAs to adopt smart contract features.
EIP-7702 will bring much-needed flexibility in batching operations and signing different privilege keys, removing many tedious actions like signing multiple transactions to do one complex operation, constantly signing logins or authorizations, and much more.
Overall, bringing EOAs closer to smart contract wallets will greatly improve end user experience. Plus, pairing smart contract wallets with simulation infrastructure can further improve dapp UX and support adoption. Learn how to use simulations with smart contract wallets to get started!
