EIP-7702: How to Merge EOA and Contract Account Functions

By DeFi Intel Research · Reviewed 2026-07-02 · 8 min read · advanced

EIP-7702 account abstraction represents a paradigm shift in Ethereum's account model, allowing externally owned accounts (EOAs) to borrow the functionality of smart contract wallets through a delegation mechanism. This proposal aims to bridge the gap between simple EOAs and feature-rich contract accounts without requiring a full migration to an entirely new account type.

By enabling an EOA to set a delegation designator that points to a smart contract, EIP-7702 effectively merges the simplicity of an EOA (one key pair) with the programmability of a contract account (sponsorship, batching, gas abstraction). This guide dives deep into the technical workings, compares it with ERC-4337, and explores how it reshapes user experience in decentralized applications.

What is EIP-7702? The Delegation Mechanism Explained

EIP-7702 introduces a delegation designator that an EOA can set through its authorization list. When a transaction originates from an EOA, the protocol allows the account to temporarily act as if it were a smart contract wallet by delegating its execution logic to a specified contract address. The delegation is expressed as authorization_list = [[chain_id, address, nonce, v, r, s], ...] signed by the EOA. The contract’s code is then used to determine the behavior of the account for that transaction only. This mechanism is sometimes called contract-bound account because the EOA’s authority is bound to a contract during execution.

Critically, the delegation is persistent—after the transaction completes, the EOA keeps the delegated code and continues to behave as a smart account until it sets a new delegation or clears it. This preserves the core property of an EOA (private key control) while adding smart contract capabilities. The delegation designator is stored as the account’s code (the prefix 0xef0100 followed by the delegate address), and it remains in state until the EOA points to a different contract or to the zero address. For example, a user holding ETH in a standard MetaMask wallet could use EIP-7702 to submit a batched transaction that swaps tokens and then stakes the remainder, all in a single operation, without leaving their existing wallet.

How EIP-7702 Works: Deep Dive into Authorization and Execution

The EIP-7702 workflow begins when the EOA signs an authorization tuple that includes the target contract address and its own nonce. The signed authorization is included in the transaction’s authorization_list. During transaction validation, the protocol checks the signature, extracts the target contract, and sets the EOA’s code to the target contract’s code. The transaction then executes using the contract’s logic, which can include calls to other contracts, balance checks, or even self-destruct operations.

Key implementation details: The contract code must be compatible with the EVM’s account abstraction interface—specifically, it must expose an executeUserOp-like entry point that receives the transaction calldata. The contract can implement gas abstraction (paymaster), batching, and signature verification. For instance, a Safe smart contract could be the target, allowing an EOA to use Safe’s multi-signature recovery or daily spend limits without migrating to a Safe address. EIP-7702 introduces a new transaction type (SET_CODE_TX_TYPE, 0x04) rather than a new opcode; processing it writes a delegation designator into the account’s code, which persists across transactions until the EOA changes or clears it.

EIP-7702 vs ERC-4337: A Detailed Comparison

While ERC-4337 provides a mature, flexible framework for account abstraction entirely off-chain, EIP-7702 offers a more seamless integration for existing EOA users. For example, a user with funds in a traditional EOA can immediately benefit from features like sponsored transactions without deploying a new contract wallet. However, ERC-4337’s bundler network and paymaster ecosystem (e.g., StackUp, Pimlico) are more battle-tested. EIP-7702’s delegation persists as the account’s code once set, so an EOA can keep smart-account behavior across transactions until it changes or clears the delegation.

Impact on User Experience: One Address, Many Capabilities

From a UX perspective, EIP-7702 eliminates the need for users to choose between an EOA and a smart contract wallet. They can keep their existing address (no migration), continue using their favorite wallet interface (MetaMask, Rainbow, etc.), and still enjoy features like gasless transactions, batched token approvals, and social recovery. For example, a DeFi farmer could use a single EIP-7702 transaction to: approve a token, swap on Uniswap, deposit into Aave, and stake the yield token—all in one atomic operation.

The delegation contract can be as simple or complex as needed. Real implementations could include a sponsorship module (like Gelato’s relay) where a third party pays the gas, or a session key module that allows limited use of the account without full private key exposure. This lowers the barrier for dApps to offer premium UX without requiring users to onboard to new wallets. For instance, a gaming dApp could prompt a user to sign a one-time delegation that enables automated in-game purchases, then resets after the session.

However, there are nuances: the delegation signature must be carefully crafted; if the replay protection is weak, a delegated transaction could be replayed on another chain. Because the delegation persists, the account keeps its smart-account behavior across transactions once it delegates, though setting up automation like session keys still depends on what the delegate contract implements.

Technical Implementation: Sponsorship, Nonce, and Gas Abstraction

EIP-7702 supports various advanced patterns through the delegation contract logic. Sponsorship (gas abstraction) is achieved by the delegation contract implementing a paymaster interface: it can deduct fees from the EOA’s balance or from an external sponsor’s balance. For example, the delegation contract could check if the transaction is signed by a sponsor and then use the sponsor’s ETH to pay gas.

Nonce management is critical: the EOA’s standard nonce is used for authorization list ordering, but the delegation contract can also maintain its own nonce to prevent replay of internal actions. A well-designed delegation contract should check both the EOA nonce and its own internal nonce for security. Gas estimation with EIP-7702 is more complex because the delegation contract’s code is not on-chain beforehand; wallets need to pre-fetch the target contract code or rely on known implementations. Wallets like MetaMask and Frame have started adding experimental EIP-7702 support, generating the delegation signature automatically when a dApp requests a function call that requires account abstraction.

For developers, integrating EIP-7702 means modifying the transaction construction flow. Libraries like ethers.js or viem may need updates to support the authorization_list field. The Ethereum JS ecosystem already has reference implementations (e.g., @ethereumjs/tx v5) that include EIP-7702 transaction types.

Use Cases: From DeFi to Gaming and Beyond

• DeFi Batching: A user can bundle multiple DeFi operations (swap, provide liquidity, stake) in one transaction using a delegation contract that executes them sequentially. Example: using a Uniswap V3 multicall contract as the delegation target.
• Gasless Transactions: A dApp like Lens Protocol could sponsor user actions by having users delegate to a contract that only allows specific function calls (like posting a publication) and covers gas costs.
• Social Recovery: A Safe-like delegation contract can allow an EOA to be recovered if the user loses access, by having trusted guardians sign a recovery transaction; the delegation enables the recovery process without migrating funds.
• Session Keys for Gaming: A game like Axie Infinity could request a short-lived delegation that authorizes in-game purchases up to a certain limit, without giving the game full access to the user’s wallet.
• Cross-Chain Messaging: A delegation contract could forward messages through a bridge like LayerZero, allowing an EOA on Ethereum to control a contract on Arbitrum in a single atomic operation.

These use cases illustrate how EIP-7702 brings account abstraction to the masses without requiring users to adopt new wallets or migrate their existing addresses.

Security Considerations: Replay, Revocation, and Trust

EIP-7702 introduces new attack surfaces. Replay attacks occur if the authorization list does not include a chain ID or if the nonce implementation is insufficient. The specification mandates that chain_id be included to prevent cross-chain replay. Still, the delegation contract must also enforce its own nonce for operations within the transaction.

Delegation revocation is not automatic. An active delegation stays in effect until the EOA submits a new EIP-7702 authorization pointing to a different contract or to the zero address (which clears the delegated code). A pending authorization signature that has not yet been used is bound to a specific nonce, so it becomes invalid once that nonce is consumed. Simply sending ordinary transactions does not remove an active delegation, so wallets should let users review and explicitly clear delegations they no longer trust.

Trust in the delegation contract: Users delegate execution to a contract; if that contract is malicious or buggy, it could drain funds. Users should only delegate to audited contracts from trusted sources (e.g., Safe, OpenZeppelin). Because the delegation persists until it is changed, a malicious contract could keep performing harmful actions across many transactions, not just one. Therefore, dApps must provide clear disclosures about the delegation contract’s behavior.

The Path to Mainnet: Current Status and Ecosystem Adoption

EIP-7702 was originally proposed in 2024 and was refined through several iterations. It was included in the Pectra upgrade, which activated on Ethereum mainnet in May 2025. The Ethereum core developers supported it due to its minimal invasiveness and backward compatibility. It was tested on testnets like Sepolia (including by client teams such as Nethermind) before mainnet activation.

Wallet providers including MetaMask have rolled out EIP-7702 (smart account) support in their products, and other wallets have added EIP-7702 transaction signing. On the infrastructure side, bundler services like StackUp are exploring hybrid solutions that combine ERC-4337 UserOperations with EIP-7702 delegations. Libraries like ethers and viem have opened PRs for the new transaction type. For developers, now is the time to experiment with EIP-7702 by writing delegation contracts and testing them on local devnets or testnets. The potential is immense: it could finally unify the EOA and smart wallet worlds, bringing account abstraction to the default Ethereum user.

Common mistakes to avoid

• Confusing EIP-7702's in-place delegation of an existing EOA with ERC-4337's separate, deployed contract accounts
• Failing to include chain ID in the authorization list, leading to cross-chain replay vulnerabilities
• Assuming the delegation contract is always code on-chain; the contract address must be deployed beforehand or be a known implementation
• Assuming a delegation is temporary or per-transaction; it persists as the account's code until you set a new delegation or clear it to the zero address
• Using the same delegation contract for all transactions without verifying its security, risking malicious execution
• Ignoring the gas cost of the authorization itself, which is charged per authorization tuple in the transaction

Frequently asked questions

Related reading

• Account Abstraction
• Smart Contract
• Account Abstraction Explained
• How To Audit Smart Contract Yourself
• How To Read Smart Contract Etherscan
• How To Set Up Multisig Wallet Gnosis Safe
• How To Understand Smart Contract Upgradeability Risks
• Smart Contract Security Audits