Externally Owned Accounts (EOAs) and smart contracts in Ethereum have traditionally been distinct: EOAs are controlled by private keys and can initiate transactions, while smart contracts can execute code when triggered but cannot initiate transactions.
EIP-7702 bridges this gap by allowing EOAs to execute code, effectively blurring the lines between them and smart contracts. This proposal represents a major step toward native account abstraction, enhancing Ethereum’s usability, security, and programmability.
Ethereum Accounts Overview
Etherem accounts have a state consisting of four key fields:
- Nonce: A counter that tracks the number of transactions sent from the account, preventing replay attacks.
- Balance: The amount of ETH the account holds.
- Storage Hash: A Merkle root representing the account’s storage.
- Code Hash: A hash of the account’s associated code (empty for EOAs).
Traditionally, EOAs have an empty code hash (0x), while smart contracts have a code hash derived from their deployed bytecode. However, EIP-7702 changes this—EOAs can now have a non-empty code hash formatted as (0xef0100 ++ address). This value, known as a delegation designator, points to a smart contract that holds the executable code.
When a transaction is sent to an EOA with a delegation designator, it executes the code stored at the designated smart contract address as if it were its own, akin to how delegatecall works in Solidity. This enables EOAs to behave like smart contracts while maintaining their capabilities, such as sending transactions.
EIP-7702 vs. EIP-4337
EIP-4337 introduced account abstraction without modifying the Ethereum protocol. Instead, it relies on off-chain infrastructure to process user operations, bundle them, and execute them on-chain via an EntryPoint smart contract.
While effective, this approach has drawbacks:
- Requires migration from EOAs to smart contract wallets.
- Relies on off-chain infraestructure, including mempools and bundlers, adding complexity and trust assumptions.
- Introduces a potential single point of failure in the EntryPoint contract.
EIP-7702 addresses these issues by enabling native account abstraction within the EVM. It allows users to keep their EOAs without requiring migration, and eliminates reliance on off-chain infrastructure.
However, EIP-7702 and EIP-4337 are complementary, not competing. Wallet providers can integrate both approaches, where:
- EIP-4337 serves as a toolkit for account abstraction features
- EIP-7702 provides an adapter to apply those features to existing EOAs
This hybrid approach allows developers to leverage the strengths of both proposals, enhancing flexibility and user experience.
How EIP-7702 Works
Set Code Transaction
EIP-7702 introduces a new transaction type (0x04), called setcode, which allows an EOA to associate with a smart contract to delegate code execution. The transaction includes the following fields:
Authorization Mechanism
To establish this relationship, a structure called authorizationList is added, consisting of authorization tuples with the following fields [chain_id, address, nonce, y_parity, r, s], where:
chain_id: Identifies the blockchain network.address: Specifies the deployed smart contract which the EOA will point to for code delegation.nonce: Ensures uniqueness and prevents replay attacks.signature: Signed by the EOA, proving authorization.
When a user wishes to delegate the execution of his account to a smart contract, he generates an authorisation tuple and signs it with:
MAGIC || rlp([chain_id, address, nonce])
where MAGIC = 0x05.
This authorization declares:
“The EOA signing this authorization grants control to the code deployed at
addressonchain_id.”
The chain_id field is allowed to be 0, allowing signature to be replayed across different chains over same address and nonce. This allows EOAs to upgrade to smart account through-out all EVM-chains in just one signature.
Any user or entity may submit a setcode transaction that includes an authorisationList. When the transaction is executed, if everything is correct, the delegation designator (0xef0100 || address) is assigned to the Code Hash of the requesting EOA.
Any user can submit a setcode transaction containing this authorization list. Upon execution, the delegation designator (0xef0100 || address) is assigned to the EOA’s code. Importantly, the signer of the authorization may differ from tx.origin in the setcode transaction.
It is important to note that the signer of the authorization does not necessarily have to match the tx.origin of the setcode transaction. In addition, the authorization mechanism allows multiple EOAs to be updated in a single transaction. For example, Alice and Bob can sign authorizations for different contracts, and a service provider can send the setcode transaction with an authorizationList that includes, among others, the authorizations of both of them. This enables gas sponsorship, reduces costs and simplifies the update process for service providers and wallets.
Execution Behavior
Once an EOA is assigned a delegation designator, any code execution operation (CALL, CALLCODE, STATICCALL, DELEGATECALL) will retrieve and execute the code at the specified address.
However, code reading operations (EXTCODESIZE, EXTCODECOPY, EXTCODEHASH) will return values based on the delegation designator rather than the actual contract code.
Examples:
EXTCODESIZE(EOA)–> returns23(the size of0xef0100 || address).EXTCODEHASH(EOA)–> returnskeccak256(0xef0100 || address).CALL——————> executes the delegated code within the context of the EOA.
Use Cases and Potential Impact
Seamless DeFi Interactions
Currently, DeFi transactions often require multiple approvals and separate transaction steps, increasing friction and gas cost. EIP-7702 reduces this friction by allowing EOAs to interact with smart contracts dynamically, streamlining transactions and minimizing gas costs.
Gas Abstraction and Sponsorship
By allowing EOAs to delegate execution, gas fees can be abstracted and optimized. This enables gas sponsorship mechanisms, where third parties (such as dApps or protocols) cover transaction costs on behalf of users, improving accessibility.
Enhanced Wallet Security
EOAs can adopt smart wallet features, improving security and user control:
- Multi-factor authentication (MFA) for stronger protection.
- Transaction limits and spending caps to prevent unauthorized large transfers.
- Social recovery and guardian-based account management.
Native Programmable Multisigs
EIP-7702 enables native multi-signature functionality within EOAs, eliminating the need for separate smart contract wallets. This allows for:
- Role-based access control, defining specific permissions for different users
- Session-based authorizations, granting temporary permissions for automated actions.
Security Considerations
Code Execution Risks
If an EOA delegates execution to an insecure contract, it may lead to fund loss. Malicious delegation targets could introduce vulnerabilities, making thorough security audits essential before assigning a delegation designator.
Compatibility with Existing Contracts
Many smart contracts assume that EOAs lack code and use patterns like tx.origin == msg.sender to differentiate EOAs from smart contracts. EIP-7702 changes this assumption, potentially breaking security-critical logic in legacy contracts.
- Attackers might upgrade an EOA to bypass contract-based access controls.
- Developers should avoid using
tx.originfor authentication and instead rely on secure access control mechanisms.
receive Function Requirement
When an EOA delegates execution to a smart contract, ETH transfers to the EOA are actually redirected to the delegated contract. This means the delegated contract must be capable of handling incoming ETH payments.
If the contract does not implement a receive or fallback function, the EOA will be unable to accept ETH transfers.
receive vs fallback functions in Solidity
Key Differences:
receive()function:- Triggered when ETH is sent without data (
msg.datais empty). - Must be marked as
external payable. - If not implemented, the
fallback()function (if available) will be used instead.
- Triggered when ETH is sent without data (
fallback()function:- Triggered when ETH is sent with data or when no
receive()function exists. - Can be used for logging, forwarding calls, or handling unexpected transactions.
- Must be marked as
external, and can optionally bepayableto accept ETH.
- Triggered when ETH is sent with data or when no
Access Control and Malicious Delegation
Once an EOA delegates execution, anyone can interact with the delegated code. Therefore, to prevent unauthorized interactions:
- Implement strict access controls to protect sensitive functions.
- If a function should only be callable by the owner EOA, enforce it with:
require(msg.sender == address(this)) - Attackers may also use phishing or social engineering to trick users into delegating to malicious contracts.
Constructor Limitations and re-initialization risks
Contracts deployed as delegation targets must use initializers instead of constructors, similar to upgradeable smart contracts. This is because the constructor is executed at the time of contract deployment, when there is no active delegation yet. As a result, state changes made to the constructor affect only the contract itself, but not the EOA that subsequently delegates to it.
Therefore, to properly initialize state variables and ensure correct behavior, contracts intended for delegation must use an initializer function instead of a constructor, this allows the contract to be configured after delegation.
Initialization functions must be adequately protected to prevent unauthorized calls that modify the state of the contract after its initial configuration. An attacker could exploit a poorly protected initialization function to execute a re-initialization attack and alter the behaviour of the contract. To mitigate this risk, it is advisable to implement a mechanism that prevents the initialization from being executed more than once.
Storage Collision
An EOA can update its delegation designator as many times as it wants. So it can change the code that governs it, however we cannot forget that the storage of EOAs is persistent, even when it changes between different delegated contract implementations. This means that while the executable code can change, the underlying storage remains the same. If a newly assigned contract has a different storage layout, it may unintentionally overwrite or corrupt existing state variables.
Analogy with Upgradeable Contracts
Think of an EOA in EIP-7702 as the proxy in an upgradeable contract:
- In upgradeable contracts, the proxy holds the storage, while the logic contract contains the executable code.
- When the logic contract is upgraded, the proxy retains its storage, so the new contract must maintain the same storage layout to prevent corruption.
- Similarly, in EIP-7702, an EOA retains its storage while switching between different delegated contracts, meaning each new contract must respect the existing storage structure.
Potential Risks of Storage Mismatches
- Corrupted or lost data, breaking contract functionality.
- Unauthorized access, if access controls are overwritten.
- Loss of funds, if critical variables like balances or approvals are misaligned.
Ensuring Storage Consistency
Proper storage management and layout consistency are crucial when switching between delegated contracts, just as in upgradeable smart contracts. To mitigate storage collision, one approach is to follow EIP-7201 – Namespaced Storage Layout. This method stores state variables in custom slots derived from a unique hash, rather than using sequential storage slots, preventing conflicts between different contract implementations.
Replay & Weak Signature Attacks
Signatures are used to validate off-chain computation and authorize transactions on behalf of a signer, making them especially useful for smart accounts. With EIP-7702, EOAs can associate code with their accounts, allowing for complex configurations such as role-based access control or session-based authorizations. These configurations will likely rely on signatures for validation.
However, if signatures are not properly handled, attackers can reuse (replay) signatures from previous or pending transactions, leading to unintended executions. This makes it crucial to manage signature uniqueness and context carefully.
To prevent this risk, smart contracts must:
- Include a unique nonce that is validated for each signature.
- Set and enforce an expiration date.
- Restrict the
svalue to its lower half to maintain signature uniqueness. - Include the chain ID to prevent cross-chain replays.
Gas Costs
- 25k gas per authorization.
- 12.5k gas refund if the account already exists.
- Delegation targets are “warmed” for optimized execution.
- Additional gas costs apply when warming both the target and delegation
Conclusion
EIP-7702 represents a pivotal advancement in Ethereum’s evolution, bringing native account abstraction without migration requirements or reliance on off-chain infrastructure. By enabling EOAs to adopt smart contract capabilities, it eliminates friction in DeFi, enhances wallet security, and unlocks new possibilities for gas optimization and smart account functionality.
However, security best practices are essential to mitigate potential risks. Developers must:
- Carefully consider delegation targets.
- Implement robust access controls.
- Ensure safe storage layouts to prevent corruption.
- Secure initialization functions to prevent re-initialization attacks.
- Use structured signatures (
EIP-712) to prevent replay vulnerabilities.
By integrating these security measures, EIP-7702 can be adopted safely, paving the way for a more flexible, efficient, and secure Ethereum ecosystem, while minimizing risks and ensuring long-term network integrity.
Thanks a lot for the great post and the clear illustrations — they really help!
However, I’m a bit confused about the part that says:
“In addition, the authorization mechanism allows multiple EOAs to be updated in a single transaction.”
As far as I understand from the current EIP-7702 spec, the to field in a setcode transaction must point to a single EOA – “to” field in sponsor’s tx (i.e., it cannot be empty). So we can only set the code for one EOA per transaction.
Even though authorizationList can include multiple entries, the transaction will only apply the code to the EOA specified in the “to” field. Could it be that this part of the post is referencing an older version of the spec, or is there something I’m missing?
Again, thanks for putting this together — it’s been super helpful overall!
Thanks so much for your comment and for taking the time to read the post in detail — I really appreciate the kind words and thoughtful feedback!
You raise a great point. From what I understand of the current EIP-7702 spec, the `to` field in the outer setcode transaction doesn’t appear to play a role in the delegation process. Instead, delegation is handled entirely through the `authorizationList`, where each entry includes a signature used to recover the EOA being delegated (referred to as `authority` in the spec). The transaction then iterates over this list and updates the code of each recovered `authority` address individually — not through the `to` field, but via the mechanism explicitly defined in the spec.
This behavior is outlined in the “Behavior” section of the spec: https://eips.ethereum.org/EIPS/eip-7702#behavior
So, based on this, it seems that a single setcode transaction can indeed update multiple EOAs, each one explicitly authorized via a valid signature in the `authorizationList`.
That said, I totally agree this could be explained more clearly in the post to avoid any confusion — thanks again for pointing it out! 🙌