EIP-7702: Ethereum's Next Step Toward a More Flexible Account Model

11 min read

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 address on chain_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) –> returns 23 (the size of 0xef0100 || address).
EXTCODEHASH(EOA) –> returns keccak256(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.origin for 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.data is empty).
- Must be marked as external payable.
- If not implemented, the fallback() function (if available) will be used instead.
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 be payable to accept ETH.

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 s value 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.