TL;DREIP-7702 is the Ethereum upgrade — live on mainnet via Pectra in May 2025 — that lets any Externally Owned Account (EOA) temporarily set its own code by delegating to a smart contract. The result is a 'smart EOA': the same address, the same private key, but with batched transactions, gas sponsorship, session keys, and granular permissions. Unlike full account migration, no asset transfer or address change is required. EIP-7702 is complementary to ERC-4337, not a replacement: 7702 upgrades the account, 4337 standardizes how that account interacts with bundlers and paymasters. This post covers what EIP-7702 is, the on-chain mechanism (the 0x04 set-code transaction), the smart-account features it unlocks, how to detect and integrate it in a dApp via EIP-5792, the security model, and a 2026 production checklist.
EIP-7702 went live on Ethereum mainnet on May 7, 2025 as part of the Pectra hardfork. It is the most consequential change to the Ethereum account model in years: every existing EOA can now temporarily set its own code, gaining the capabilities of a smart contract without changing addresses. This post is the canonical reference for what EIP-7702 is, how it works, how it relates to ERC-4337 and EIP-3074, and how to ship it in production.
What is EIP-7702?
EIP-7702 is an Ethereum Improvement Proposal — now part of the protocol — that allows a standard wallet (EOA) to set its own smart contract code for the duration of a transaction or persistently across transactions. This "supercharges" traditional accounts: a user keeps their existing address and private key but gains the ability to batch multiple operations, have their gas fees sponsored by a third party, run session keys, and implement granular permission controls.
EIP-7702 is designed to be complementary to ERC-4337. It does not replace account abstraction — it makes account abstraction available to every existing wallet. An EOA upgraded via 7702 can plug directly into ERC-4337 bundlers and paymasters with no address migration.
Genesis and purpose
EIP-7702 was proposed by Vitalik Buterin and the co-authors of EIP-3074 in May 2024 as a more forward-compatible alternative to EIP-3074. Where 3074 introduced opcode-level delegation per call, 7702 lets an EOA be a smart contract for as long as it wants. EIP-3074 was withdrawn; EIP-7702 was finalized and shipped in Pectra one year later.
The fundamental idea is straightforward: any EOA can adopt the functionality of an existing smart contract. As the EIP puts it, 7702 "gives superpowers to EOAs" by letting them "set their code based on any existing smart contract." That single sentence collapses the historical separation between EOAs and smart contracts.
EIP-7702 vs EIP-3074 vs ERC-4337
| Standard | What it changes | Live on mainnet | Use case |
|---|---|---|---|
| EIP-7702 | Lets an EOA set its own code by delegating to a smart contract | Yes (Pectra, May 2025) | Upgrade existing EOAs to smart accounts without migration |
| EIP-3074 | Adds AUTH/AUTHCALL opcodes for per-call delegation | Withdrawn | (Superseded by EIP-7702) |
| ERC-4337 | Standardizes bundlers, paymasters, and UserOperations off-protocol | Yes (March 2023) | Account abstraction infrastructure for both new smart accounts and 7702-upgraded EOAs |
The key insight: 4337 is infrastructure, 7702 is protocol. They compose. A 7702-upgraded EOA is the smart account that 4337 then routes through bundlers and paymasters.
Technical architecture
EIP-7702 introduces a new transaction type, 0x04 — commonly called the "set-code" transaction. The payload includes a novel field, the authorization_list, containing the signatures and data that authorize the EOA to delegate to a smart contract implementation:
_10rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit,_10 destination, value, data, access_list, authorization_list,_10 signature_y_parity, signature_r, signature_s])
Each entry in the authorization_list is a tuple:
_10authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
Each tuple is a signature authorizing the EOA to adopt the code of a specific smart contract address. The signature is over the keccak256 hash of the components, ensuring integrity and authenticity.
When an EOA owner wants smart-contract behavior, they sign an authorization designating a specific contract as their implementation. From that point, the EOA executes code from that contract while keeping its identity and storage. The designation persists until replaced by another authorization.
At the bytecode level, an upgraded EOA stores a special prefix 0xef0100 followed by the 20-byte implementation address — effectively a delegatecall proxy. Calls to the EOA execute the implementation contract's code in the EOA's own context.
Smart-account features unlocked
Transaction batching
Multiple operations bundled into a single atomic transaction. The canonical DeFi flow — approve followed by swap — collapses from two transactions to one. Batches can include dependencies, where the output of one call feeds the next. ERC-7821 standardizes the batch interface; most production 7702 delegators implement it.
Gas sponsorship
A third party pays for the user's gas — through ERC-4337 paymasters, ERC-2771 forwarders, or wallet-native sponsorship. This removes the requirement that users hold native ETH (or the equivalent) to transact. Users can pay in stablecoins, app operators can subsidize onboarding, or sponsorship can be feature-conditional.
Session keys
Time-bounded sub-keys with restricted scope. Common patterns: a session key valid for one hour, scoped to a single contract, with a max ETH value of 0.1. The user signs once to authorize the session; the dApp signs subsequent transactions with the session key without prompting the user again. EIP-7715 (Permission Tree) provides a standard way for dApps to query and request permissions.
Granular permission management
Beyond session keys, 7702 enables sophisticated privilege de-escalation: subkeys that can only spend specific tokens, interact with specific contracts, or access a fraction of the account balance. Each implementation can define its own policy structure.
Cross-chain authorization
A 7702 signature with chain_id = 0 is valid on every EVM chain that supports the standard. One signature, every chain. This is particularly powerful for cross-chain agents and intent-based systems.
How EIP-7702 integrates with ERC-4337
A 7702-upgraded EOA can point to an ERC-4337-compatible implementation. The flow:
- A user initiates a transaction in a dApp.
- The dApp creates a
UserOperationwithuserOp.senderset to the EOA address. - The UserOperation is sent to a bundler.
- The bundler packages multiple UserOperations and submits them to the EntryPoint contract.
- The EntryPoint calls the upgraded EOA for validation and execution.
- The EOA, now executing the delegated implementation, processes the UserOperation per its 4337-compatible logic.
The result: existing wallets and infrastructure built around ERC-4337 work seamlessly with EOAs upgraded via 7702. No new accounts. No asset migration. No address changes.
The Openfort Delegator Account
Openfort ships a production-ready 7702 delegator contract that includes WebAuthn-based session keys, atomic batching, gated session-key access, and full ERC-4337 compatibility. For the contract architecture, the security model, and the integration recipe, see What the Openfort Delegator Account includes.
Integration guide for dApp developers
Detect EIP-7702 support
Use wallet_getCapabilities from EIP-5792 to check whether the connected wallet supports 7702 before exposing 7702-only flows:
_10async function check7702Support(provider) {_10 try {_10 const capabilities = await provider.request({ method: 'wallet_getCapabilities' })_10 return capabilities.includes('eip7702')_10 } catch {_10 return false_10 }_10}
Fall back to standard EOA flows when eip7702 capability is absent.
Send a batch via EIP-5792
_12async function sendBatch(provider, calls) {_12 return provider.request({_12 method: 'wallet_sendCalls',_12 params: [{ calls }],_12 })_12}_12_12const calls = [_12 { to: tokenAddress, data: approveData },_12 { to: swapAddress, data: swapData },_12]_12const result = await sendBatch(provider, calls)
Request session-key permissions via EIP-7715
_10await provider.request({_10 method: 'wallet_requestPermissions',_10 params: [{_10 target: tokenAddress,_10 selector: '0xa9059cbb', // transfer(address,uint256)_10 valueLimit: 0,_10 expiration: Math.floor(Date.now() / 1000) + 3600,_10 }],_10})
Display batched transactions
A 7702 batch surfaces in block explorers as a single transaction with multiple internal calls. Use ERC-7821's CallOperation events to extract individual operations and display them as expandable details under a single "Approve + Swap" entry rather than a confusing one-line transaction.
Adoption landscape
Adoption splits cleanly along wallet type:
- Embedded wallets (built into dApps) are the fastest adopters. They control the full UX and benefit immediately from 7702 — seamless onboarding, gasless transactions, and session keys with no extension prompts.
- Standalone wallets vary. Some embraced 7702 immediately (Ambire, Trust Wallet, MetaMask via opt-in), others waited for security audits and regulatory clarity, others still treat 7702 as opt-in per-transaction.
- Open dApps (Uniswap, Aave) detect 7702 support via
wallet_getCapabilitiesand gate features accordingly. AI trading agents can refuse to operate without 7702; on-chain games degrade gracefully to EOA mode. - Closed dApps (consumer apps, games) typically default to 7702 for everyone, often combined with passkey-based authentication via RIP-7212 for a fully native UX.
Security considerations
Persistent delegation
Unlike EIP-3074's per-call AUTH, EIP-7702 delegations persist until replaced. A malicious authorization can compromise the account long-term. Mitigation: wallets restrict 7702 authorizations to a vetted set of implementation contracts and provide clear UI for managing active delegations.
tx.origin checks
Some legacy contracts use tx.origin == msg.sender to detect EOAs. A 7702-upgraded EOA can break that assumption. Mitigation: dApp developers should update EOA-detection logic to handle the 0xef0100 code prefix.
Storage layout collisions
When an EOA switches between different implementation contracts, storage slots from one implementation may collide with another. EIP-7201 (Namespaced Storage Layout) defines a standard for namespacing storage to avoid this. Use 7201-compliant implementations.
Frontrunning
To prevent an attacker from frontrunning a 7702 deployment, smart-account factories enforce require(msg.sender == entryPoint.senderCreator()), and the userOpHash includes the delegate address so users sign over the 7702Auth object explicitly.
2026 production checklist
Before shipping EIP-7702 in production:
- Pick an audited delegator implementation. Openfort's, MetaMask's, Ambire's, and a few others have undergone formal verification and third-party audits. Don't deploy your own.
- Restrict authorizations to vetted implementations. Wallet UX should not let users sign 7702 authorizations to arbitrary contracts. Maintain an allowlist.
- Use 7201 namespaced storage. Future-proof against collision when users switch implementations.
- Plan the EOA-detection migration. If your contracts check
tx.origin == msg.senderto gate functionality, document the exposure and plan an update path. - Wire up EIP-5792 capability detection. Don't assume 7702 — check
wallet_getCapabilitiesand degrade gracefully. - Handle batched transaction display. Use ERC-7821
CallOperationevents. Don't surface raw transaction hashes for a batched approve+swap — users will read it as one action and your UI should match. - Audit your sponsorship policy. If you offer paymaster sponsorship, define spend limits, anti-abuse rate limiting, and a kill switch.
- Test with multiple wallet implementations. Different 7702 delegators have subtly different policy semantics. Verify against at least Openfort, MetaMask, and Ambire before shipping.
Looking forward
EIP-7702 is a transition step, not the destination. The long-term Ethereum roadmap still aims at full native account abstraction (RIP-7560 and successors), where EOAs disappear entirely and every account is a smart account from the protocol's perspective. EIP-7702 is the bridge: it gives every existing user the smart-account experience now, and it lets builders ship the UX patterns that will define account abstraction for the next decade.
For builders, the practical path is clear: pick an audited delegator, wire up EIP-5792 capability detection, and ship 7702 features with graceful EOA fallback. The infrastructure is mature, the standards are stable, and the user expectation — gasless, batched, session-key-based UX — is now table stakes.
Related reading
- What the Openfort Delegator Account (7702) includes — contract architecture and the integration recipe
- EIP-3074 vs EIP-7702: how account abstraction got here — the standards history
- Understanding native account abstraction in RIP-7560 — what comes after 7702
- EOA vs Smart Wallet — the higher-level architectural picture