EIP-7702 Smart Accounts: What Ethereum Builders Must Know

EIP-7702 shipped with Ethereum's Pectra mainnet upgrade on May 7, 2025, and it changes the starting point for every developer building wallet-integrated features on Ethereum: an existing externally owned account (EOA) can now execute smart contract logic within a transaction without deploying a new smart contract wallet, without migrating to a new address, and without abandoning existing ERC-4337 infrastructure. The 11,000 authorizations recorded by The Block within one week of Pectra's activation signal that wallet providers moved fast. What that activation actually means for builders integrating it in 2026 — including where the security risks concentrate — takes more careful examination.

What EIP-7702 Actually Does for Ethereum Developers

EIP-7702 introduces a new Ethereum transaction type: 0x04, referred to as a Type 4 transaction. Unlike Type 0 (legacy) or Type 2 (EIP-1559) transactions, a Type 4 transaction carries an additional field — authorization_list — that the EOA's private key signs before broadcast.

The authorization_list contains one or more entries, each specifying: the target chain ID, the address of an implementation smart contract (the delegation target), a nonce, and the user's ECDSA signature components (y_parity, r, s). When the transaction executes, the Ethereum Virtual Machine (EVM) reads the first valid entry in the authorization_list and writes a delegation designator to the EOA's account — a pointer to the implementation contract address. For the duration of that transaction, any call to the EOA's address loads and runs the code at the delegated contract address, as if that code lived at the EOA's own address.

This creates what is informally called a "Smart EOA" or Connected EOA. The delegation is not permanent: it can be removed by the EOA's private key by sending another Type 4 transaction with an empty delegation target. The user's address never changes. Assets already held at that address are unaffected by the delegation state.

The key difference from ERC-4337: ERC-4337 requires deploying a separate smart contract wallet at a new address. Users must transfer assets to that new address, and developers must ensure their dApps recognise the contract wallet format. EIP-7702 bypasses both requirements — delegation happens at the existing address, and ERC-4337's bundler and paymaster infrastructure remains compatible.

Etherspot: EIP-7702 shared mempool infrastructure for UserOperation submission

The Developer Problem EIP-7702 Eliminates

Before EIP-7702, account abstraction via ERC-4337 imposed four constraints on developer teams targeting mass-market Ethereum applications.

First, deployment cost per user: each ERC-4337 smart account wallet deployment costs approximately 200,000 to 300,000 gas. At Ethereum mainnet gas prices, this ranges from $10 to $50 per user at periods of moderate demand. For applications targeting thousands or millions of users, this per-user cost is prohibitive without aggressive account-deployment-on-demand optimisation.

Second, address migration friction: asking a user who holds ETH, ERC-20 tokens, or NFTs at an existing address to move those assets to a new smart contract wallet creates user experience and trust barriers, particularly for users who verify addresses through block explorers or hardware wallets.

Third, tooling fragmentation: many dApps and infrastructure services — bridges, CEX withdrawal allowlists, staking dashboards — are calibrated for EOA addresses. A smart contract wallet at a new address may behave differently when interacting with contracts that check msg.sender or tx.origin, requiring per-integration debugging.

Fourth, multi-chain address consistency: deploying the same ERC-4337 smart wallet address across multiple EVM chains requires deterministic deployment (CREATE2), which developers must coordinate explicitly.

EIP-7702 eliminates all four. No deployment, no address change, no CREATE2 coordination. The user's existing EOA gains delegated functionality during transactions and reverts to standard EOA behaviour otherwise. Per the Openfort architecture analysis, this positions EOA + EIP-7702 as the default integration path for new consumer applications in 2026, with full ERC-4337 smart accounts retained for applications that require persistent on-chain account logic that survives across multiple transactions independently.

Web3 Builder protocol and developer tooling coverage→ /categories/web3-builder

Under the Hood: Type 4 Transactions and Delegation Mechanics

For developers writing EIP-7702 integrations, the implementation sequence involves three components: the authorization signature, the delegation contract, and the transaction broadcaster.

The authorization signature is constructed off-chain. The EOA signs a message containing: keccak256(rlp([chain_id, address, nonce])) where address is the delegation target contract and nonce is the EOA's current transaction nonce. The signature covers the chain ID explicitly — this is the replay protection mechanism. A signed authorization for Ethereum mainnet is not reusable on Arbitrum, even if the delegation contract deploys to the same address on both chains. Developers building multi-chain applications must collect per-chain signed authorizations from users for each chain they intend to activate delegation on.

The delegation contract is a standard Solidity smart contract deployed to any address. When an EOA activates it via EIP-7702, the contract's functions become callable at the EOA's address for the transaction duration. The contract author controls which functions are exposed and what logic they execute. A well-structured delegation contract might implement executeBatch(Call[] calldata calls) for transaction batching, validateSessionKey(address key, bytes calldata proof) for session key validation, and paymaster compatibility hooks for gas sponsorship.

A critical implementation detail: msg.sender within the delegation contract, when called via the EOA, is set to the entity calling the EOA — not the EOA itself. This means access control patterns that check msg.sender == owner (where owner is the EOA address) need to use address(this) instead of msg.sender when verifying that calls originate from the EOA's own context. Getting this wrong produces access control failures that can be exploited.

The Remix IDE documentation confirms EIP-7702 template support is available in the Template Explorer. Foundry's testing environment supports local EIP-7702 testing via cheatcodes without requiring a testnet deployment.

QuickNode: EIP-7702 implementation guide with Foundry examples

How to Start Building With EIP-7702 Today

The fastest path to testing EIP-7702 locally uses Foundry. Fork Ethereum mainnet locally using anvil --fork-url $RPC_URL, then use Foundry's vm.signDelegation cheatcode to sign an authorization for a test EOA without requiring a live Type 4 transaction. This lets developers test batch execution logic against forked mainnet state before any production deployment.

For wallet integration, the most mature infrastructure today is the Etherspot shared mempool, which accepts EIP-7702 UserOperations on Ethereum and Optimism with Arbitrum, Base, Linea, and World Chain integrations staged. Etherspot's mempool is compatible with existing ERC-4337 bundlers, so teams that already run bundler infrastructure can route 7702 UserOps through the same pipeline.

Wallet-as-a-Service providers including Dynamic and Openfort have published dashboard-level toggles for activating EIP-7702 on embedded EOA wallets. For dApps that need to detect whether a connected wallet supports EIP-7702 capabilities at runtime, EIP-5792 provides a wallet_getCapabilities RPC method that returns the wallet's supported feature set — including whether batch transactions and paymaster sponsorship are available without additional prompts.

For production deployments, use the CAIP-222 authentication standard when requesting EIP-7702 authorizations from users, which provides a human-readable signing context that hardware wallets like Ledger and Trezor can display meaningfully. This matters because blind signing a delegation authorization is functionally equivalent to handing the delegation contract control over your EOA for a transaction — users who do not understand what they are signing carry real financial risk.

Ethereum Pectra mainnet coverage and EIP-7702 adoption metrics→ /news/ethereum-pectra-mainnet-11-eips-builders

Limitations and What EIP-7702 Does Not Yet Solve

EIP-7702 is a significant step in account abstraction, but four real limitations constrain what builders can deploy in production today.

First, no persistent state across transactions. Because delegation is activated per-transaction, any state the delegation contract writes to storage at the EOA's address is only guaranteed to persist if the next transaction also activates the same delegation. Applications that require reliable cross-transaction state — subscription models, continuously active session keys — need to store state in a separate contract, adding back some of the complexity EIP-7702 removes.

Second, delegation contract auditability. The security posture of any EIP-7702 integration is entirely dependent on the delegation contract's code quality. As Ledger's security team noted, delegating to a malicious or buggy 7702 contract is as dangerous as signing a malicious ERC-20 approval — potentially worse, because a well-crafted delegation contract can batch-drain all approved tokens in a single transaction. Builders should only deploy audited delegation contracts and should communicate clearly to users what contract they are delegating to, at what address, and what actions that contract can perform.

Third, cross-chain authorization management. Per-chain signed authorizations cannot be reused across chains. Multi-chain applications must collect separate authorizations for each chain, creating UX friction for users on five or more EVM chains.

Fourth, forward compatibility with EIP-6900. The Ethereum community is developing EIP-6900, a modular smart account standard that would define how delegation contracts structure their interfaces for composability. Delegation contracts built without EIP-6900 compatibility may require migration when the standard solidifies, creating technical debt for teams building EIP-7702 integrations today. Builders should track EIP-6900 specification progress and, where possible, structure their delegation contracts against the draft interface.

Ledger Academy: EIP-7702 security tradeoffs for hardware wallet users

The concrete milestone to track for teams building on EIP-7702 in 2026 is EIP-6900's progression through the Ethereum Improvement Proposal process and whether Glamsterdam — the upgrade following Fusaka on Ethereum's roadmap — incorporates any protocol-level standardisation of modular account interfaces that would affect how delegation contracts should be structured today.