As we know, EOAs can initiate transactions, but smart contracts can’t; EOAs can only do simple transactions, but smart contracts can execute more complex ones. EIP-7702 combines the useful parts of these account types: EOAs can now borrow smart contracts’ code.
EIP-7702, part of Ethereum’s upcoming Pectra upgrade, introduces a new transaction type (Type 4) that lets EOAs temporarily use the logic of a smart contract, allowing them to act like smart contract wallets.
How Will Wallets Handle EIP-7702?
Technically, an EOA can be upgraded to any smart contract. However, in practice, wallets are unlikely to permit this freely, as it could introduce serious security risks. It will likely be restricted to their implementation or a limited set of approved smart accounts, as they don’t want to allow users to delegate to a malicious contract that could cause them to lose all their funds.
MetaMask supports EIP-7702 and has a Delegator Contract. Here is an example of a type 4 transaction that delegates to that smart contract:
https://www.cyfrin.io/glossary/eip-7702
If we look at the account info, we can see the delegated address:
Also, when we look at the address, we can see that the delegated address’s Public Name Tag is MetaMask: EIP-7702 Delegator:
Additionally, you can check which wallets support EIP-7702 here.
Benefits of EIP-7702
Before EIP-7702, users had to make at least two transactions for simple transactions, such as swaps or deposits, because they had to approve them first. It makes users tired because they have to verify the correctness of all transactions and confirm them. They have to click the button for each transaction and check if it is true or not.
EIP-7702 enables multiple transactions to be completed in a single transaction. Due to this, users don’t have to click for each transaction and check it for correctness; they should do this just once. They can batch multiple transactions into one, such as sending funds to various users, which can save gas.It enables sponsorship. For example, someone else can pay for a transaction on behalf of a user, and the user can then pay the sponsor in ERC-20 tokens.It provides privilege de-escalation, which enables users to delegate limited permissions to sub-keys, rather than granting full access to their account. For example, a sub-key might be allowed to spend only ERC-20 tokens but not ETH, or limit spending to 1% of the total balance per day. This approach enhances security by limiting the actions that delegated keys can perform.Users can perform complex operations without having to deploy a custom smart contract, which provides savings in gas.Because EIP-7702 is an EIP, Ethereum and Ethereum-equivalent L2s will automatically have it. It is not required to have new infrastructure, and it can adapt quickly.EIP-7702 can demonstrate to users the benefits of Account Abstraction, thereby helping to facilitate its adoption.Users don’t have to migrate their funds to a newly created account. They can now have a smart account with just a single transaction — this makes EIP-7702 more desirable than ERC-4337 for users.EIP-7702 provides an EOA that functions like a Smart Account, but it remains an EOA, allowing users to revert it to its original state. However, ERC-4337 accounts are just Smart Accounts.
Does EIP-7702 Remove the Need For ERC-4337?
ERC-4337 and EIP-7702 are not seen as competitors; EIP-7702 is designed to be forward-compatible with ERC-4337. While EIP-7702 enables smart account functionality, it is not enough for Account Abstraction. Even though it has advantages, it still requires storing private keys or seed phrases, which is not ideal for mainstream adoption, as users can’t keep them safe, and one of the main reasons why we need ERC-4337. So, we still need full Account Abstraction.
How EIP-7702 Works?
EIP-7702 enables EOAs to act like a smart contract account through a delegation indicator. Previously, EOA’s code field was empty, but now they are storing a delegation indicator (0xef0100 || address) in their code field, where the address points to a smart contract that contains features the user wants to use. Users set the delegation indicator via the setCode transaction:
https://decentralizedsecurity.es/eip-7702-ethereums-next-step-toward-a-more-flexible-account-model
To define this relationship, a data structure known as authorizationList is introduced:
chainId: Specifies the target blockchain network; if set to zero, it means that the transaction can be replayed on all EVM-compatible chains supporting EIP-7702. (But if nonce is different for different networks, it won’t work even if it is zero, and also, the same contract address on different chains may have different implementations, which means that it should be set carefully.)
address: Address of the smart contract EOA will point to. To delegate to a smart contract, that contract must already be deployed and available on-chain at the time of delegation.
nonce: Ensures transaction is unique and protects against replay attacks.
signature: Verifies that the EOA has authorized the action by signing it.
The user signs the hash of a message constructed by first concatenating a fixed prefix called MAGIC (0x05) with the RLP encoding of [chain_id, address, nonce], and it looks like this: MAGIC || rlp([chain_id, address, nonce]).
If the address is 0x0000000000000000000000000000000000000000, the delegation indicator is not written because it is clear that the account’s code is resetting to the empty code hash (0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470).
Additionally, the signer of an authorization tuple may differ from the tx.origin of the transaction, and a setCode transaction must include at least one authorization; otherwise, it will be invalid.
When a transaction targets an EOA that has a delegation indicator, the EOA runs the code located at the specified smart contract address as if the code belongs to the EOA itself, similar to the behavior of DELEGATECALL in smart contracts.
SECURITY CONSIDERATIONS
Front-running initialization
With this EIP, when delegating to a contract, there is no way to run initcode or initialize storage during the delegation process. This creates a risk: someone could try to front-run and set up the delegation using an account they control. To prevent this, developers should make sure that the initial calldata used for delegation setup is signed by the EOA’s private key. This signature can be verified using ecrecover, ensuring the delegation is only set up by the rightful account owner and with the intended values.
Storage Collision
As mentioned earlier, it works like a DELEGATECALL, meaning the smart contract code runs in the EOA’s context and uses the EOA’s storage instead of its own. This is similar to upgradeable smart contracts. Because of this, re-delegating must be done carefully to avoid storage collisions. To prevent such issues, using a standard like ERC-7201 is recommended. If there’s any doubt, it’s best to clear the account’s storage first. While Ethereum doesn’t support this directly, a custom delegate contract can be created specifically to perform this operation. It’s essential to design smart contracts for EIP-7702 carefully, as they can be vulnerable to front-running attacks and storage collisions.
Transaction Propagation
Allowing EOAs to act like smart contracts through delegation introduces new challenges for how transactions are handled and shared across the network. Normally, EOAs can only send value, and nodes can easily check if a transaction is valid just by looking at that EOA’s state. In this setup, one transaction can only invalidate other pending transactions from the same account.
However, with this EIP, delegation allows an EOA’s code to be called by anyone, which means a transaction from one account could unexpectedly affect another. For example, an EOA’s balance might be emptied through delegated code, making it hard for nodes to predict transaction outcomes ahead of time.
To reduce the risk of this happening, it is recommended that clients only allow one pending transaction at a time for any EOA that has a non-zero delegation indicator. This limits the number of transactions that a single one can invalidate.
Another approach is to extend the EIP-7702 transaction format by including a list of accounts that the caller intends to “hydrate” during the transaction. These accounts would act as delegated code only within EIP-7702 transactions that specify them in this list, enabling clients to analyze and understand pending transactions more effectively statically.
tx.origin After EIP-7702
tx.origin can no longer be assumed to come from a regular EOA, as it may be an EOA executing delegated smart contract code. It means that contracts using checks like require(tx.origin == msg.sender, “Externally owned accounts only”); to make sure it’s a transaction from directly an EOA won’t work anymore because it can be an EOA with a delegation indicator, which means it can execute an intermediary smart contract but can still tx.origin == msg.sender.
EOA Behavior Changes After EIP-7702
CALL
When a transaction is sent to an EOA and it includes a delegation indicator, it will instead call the delegated smart contract. Prior to EIP-7702, it was assumed that any call to an EOA would succeed, as EOAs could not reject ETH transfers. However, what appears to be a simple ETH transfer to an EOA might now trigger a fallback function in the delegated contract, potentially consuming additional gas or even causing the transaction to revert.
For example, if a smart contract has a code like this:
(bool success, ) = recipient.call{value: amount}(“”);
It can revert if EOA has a delegation indicator and the smart contract doesn’t have a fallback or receive function.
EXTCODESIZE
Previously, EXTCODESIZE returned 0 for EOAs, but now, it will return 23 (the size of 0xef0100 || address). Checking an address with EXTCODESIZE to determine whether it is an EOA or a smart contract can cause unintended actions. However, CODESIZE will return the size of the code residing at the address. So, during delegated execution, CODESIZE and CODECOPY behave differently from EXTCODESIZE and EXTCODECOPY on the authority contract.
For more details and a better understanding, some helpful sources are here:
EIP-7702: Ethereum’s Next Step Toward a More Flexible Account ModelEIP-7702: Set Code for EOAsCyfrin EIP and ERC Glossary: EIP-7702Walletbeat – EIP-7702 wallet adoptionhttps://medium.com/media/b4b23f60211963acb15ae268a723efb2/hrefEIP-7702: A Win for Smart Accounts in Ethereum’s Pectra Upgrade?EIP-7702: How Smart Contract Powers for Existing EOA WalletsWill EIP-7702 Affect Your Code?
https://docs.candide.dev/account-abstraction/7702/overview/
What is EIP-7702? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.