February 26, 2025

EIP-7702: A Game Changer Ethereum Upgrade

Shubham Khandelwal

In a groundbreaking development for the Ethereum ecosystem, the upcoming hard fork is set to revolutionise how we interact with EVM wallets. At the heart of this transformation lies EIP-7702, a proposal that promises to bridge the gap between traditional cryptocurrency accounts and smart contract functionality.

The upgrade represents a significant milestone in Ethereum's ongoing journey toward account abstraction. By enabling Externally Owned Accounts (EOAs) to harness smart contract features, this update fundamentally reimagines what's possible with standard Ethereum wallets.

As we stand on the brink of this transformation, one thing is clear: EIP-7702 isn't just another technical upgrade – it's a fundamental shift in how users will interact with the Ethereum blockchain, paving the way for broader adoption and more sophisticated use cases.

Current Accounts Management

Externally Owned Accounts (EOAs)

At present, EOAs serve as the primary entry point for user interactions on EVM chains. These accounts, controlled by private keys, have specific characteristics that define their capabilities and limitations:

Transaction Initiation: EOAs are the only accounts capable of starting the transaction chain, acting as the genesis point for all blockchain interactions
Code Execution Limitations: Despite their fundamental role, EOAs cannot execute code directly from their address
Operational Scope: They're restricted to basic operations like sending ETH and initiating contract calls

Smart Contract Accounts (SCAs)

In contrast, Smart Contract Accounts represent Ethereum's programmable layer, offering sophisticated functionality but with their own set of constraints:

Code Execution: SCAs can contain and execute arbitrary code
Transaction Dependencies: They cannot independently initiate transactions, requiring activation by an EOA
Programmability: Offer extensive flexibility in implementing complex logic and state management

Key Features and Benefits:

EIP-7702 will merge these above two accounts by letting any EOA account act like a smart contract.
EIP-7702 enables EOAs to act as a proxy smart contract.
It is compatible with the account abstraction standard, ERC-4437.
For users, it will enable web2-like features, including account recovery and passkey sign-in for easier authentication, and web3-benefits like gas-sponsored transaction fees and paying for gas in any token, not just ETH.

Technical Details

The EIP 7702 introduces a concept: the ability for Externally Owned Accounts (EOAs) to act as proxy smart contracts. This is achieved through a new “delegation bytecode” mechanism, fundamentally changing how we think about account abstraction on Ethereum.

The proposal introduces a new transaction type (SET_CODE_TX_TYPE (0x04)) with a specific TransactionPayload structure:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, [[contract_code, y_parity, r, s], ...], signature_y_parity, signature_r, signature_s])

The authorisation_list is particularly crucial, defined as:

authorisation_list = [[chain_id, address, nonce, y_parity, r, s], ...]

The address field in the authorisation_list represents the delegated code's address, while the EOA's address can be recovered from the payload (chain_id, address,nonce) and the signature (y_parity, r, s). This decoupling of the EOA address and the EIP-7702 transaction's address allows the authorisation to be submitted on behalf of the original EOA by another EOA account, enabling more flexible delegation and sponsored transactions.

The design separates transaction authorisation from execution, allowing relayers to cover gas costs and enabling sponsored transactions while maintaining security through ECDSA signatures.

The following sections highlight a few notable features of EIP-7702 as warm-ups:

Non-Empty Authorisation List Enforcement

The authorisation_list must not be empty, ensuring that every EIP-7702 transaction includes an explicit intention to authorise a contract address. Additionally, the protocol validates the parameters of each authorisation_list tuple, including the address length and reasonable ranges for chain_id, nonce, y_parity, r, and s.

The protocol implements strict validation requirements:

Authorisation lists cannot be empty
Each tuple's parameters must be validated:

Address length verification
Chain ID validation
Nonce range checks
Signature component validation (y_parity, r, s)

Nonce Management

EIP-7702 introduces a new nonce increment mechanism:

Initial Validation: Transaction nonce must match the account's current nonce
Sequential Processing:

Transaction nonce increments first
Each authorisation in the list must use correct sequential values
Successful delegations trigger corresponding authorisation nonce increments

For transactions where the authorisation signer matches the transaction signer:

tx.nonce = account.nonce
authorisation.nonce = account.nonce + 1

This means that if a transaction includes an authorisation list and the authorisation signer is the same as the transaction signer, you must set tx.nonce to account.nonce and authorisation.nonce to account.nonce + 1. If a transaction contains multiple authorisations signed by the same EOA (which will not happen in practical use cases), the nonce of each authorisation must be incremented sequentially.

Possibly, this mechanism may create some problems for Wallet SDKs to initialise delegate transactions, especially when handling all cases.

Execution Context Management

When interacting with a delegated EOA:

Calls are forwarded to the delegation smart contract
Delegation bytecode executes within the EOA's context
All storage operations occur in the EOA's namespace

Storage Collision Prevention

To prevent storage conflicts during redelegation, EIP-7702 implements two key standards:

ERC-7201: Implements storage buckets with unique root slots
ERC-7779 (draft): Provides standardised re-delegation process:

Uses ERC-7201 for storage conflict prevention
Implements storage compatibility validation
Handles legacy wallet data cleanup

Delegation Chain Restrictions

To maintain system integrity and prevent complexity explosions, EIP-7702 enforces:

Single-level delegation only
First delegation's code execution priority
Explicit prohibition of delegation chains

This means the delegated code can not delegate to another delegated EOA.

Cross-Chain Compatibility Features

The proposal includes sophisticated cross-chain functionality:

Setting chain_id = 0 in authorisation_list enables cross-chain authorisation replay
Requires matching nonces across chains
Practical limitations for accounts with non-zero nonces

Delegation Revocation Mechanism

Users can utilise EIP-7702 to modify the authorised address. If the address field is set to zero address, the previous authorisation will be revoked. This clears the account’s code and resets the account’s code hash to the empty hash.

Real-World Use Cases

This technical infrastructure enables several critical features:

Web2-like Account Recovery:

Passkey sign-in support
Delegated recovery mechanisms

Advanced Transaction Management:

Gas fee sponsorship
Multi-token gas payment options
Sponsored transaction relay
Transaction Batching: For example, the users can perform approve and swap transactions in one transaction on UniswapV3.

Smart Contract Integration:

Direct contract interaction capabilities
Maintained EOA security properties
Enhanced programmability

Technical Considerations for Developers

When implementing EIP-7702:

Storage Management:

Implement storage buckets
Use ERC-7201 for layout management
Handle storage migrations carefully

Authorisation Handling:

Implement proper nonce sequencing
Validate authorisation chains
Manage signature components

Delegation Management:

Implement proper revocation handling
Manage storage cleanup
Handle cross-chain considerations

Conclusion

EIP-7702 represents a significant technical advancement in Ethereum's account abstraction journey. By enabling EOAs to act as proxy smart contracts while maintaining security and adding sophisticated features, it creates new possibilities for wallet functionality and user experience. Developers should pay particular attention to storage management, authorisation handling, and delegation patterns when implementing this standard.

Understanding these technical details is crucial for developers and architects working to implement or interact with EIP-7702-enabled systems. As the proposal moves toward implementation, its impact on the Ethereum ecosystem will likely be substantial, enabling more sophisticated wallet architectures while maintaining the security properties that make blockchain technology valuable.