Both EIP-7702 and ERC-4337 deliver account abstraction to Ethereum. They take fundamentally different routes. ERC-4337 ships out-of-protocol with a separate transaction format and a bundler mempool — the right choice for purpose-built smart wallets. EIP-7702 ships in-protocol via a new transaction type that lets an EOA temporarily delegate its execution to a smart contract — the right choice for retrofitting smart-wallet behavior onto the 200M+ EOAs already deployed. The two are complementary, and most modern wallet stacks now support both.
​

This guide compares EIP-7702 vs ERC-4337 at the technical level, walks through what each solves, and lays out the decision framework for which path fits which product. By the end you will know how a 7702 authorization actually works, why bundlers still matter even with 7702 in the picture, and how stablecoin apps and treasury platforms in 2026 typically combine both.
​

ERC-4337 is the application-layer standard for account abstraction, finalized March 2023. It defines a parallel transaction system: users sign UserOperations, bundlers package them, and a singleton EntryPoint contract validates and executes each one against the user's smart contract account. The user's wallet is a contract — typically deployed deterministically via CREATE2 — and validation logic is whatever the contract implements.
​

The whole system is permissionless. Anyone can run a bundler. Anyone can deploy a smart account. The EntryPoint at 0x0000000071727De22E5E9d8BAf0edAc6f37da032 is the only canonical piece, and it is intentionally minimal so it can stay immutable. The full spec is at eips.ethereum.org/EIPS/eip-4337; the deeper walkthrough lives in our ERC-4337 explainer.
​

The point of ERC-4337's design is that it required no consensus changes. That meant it shipped fast, deployed everywhere EVM ran, and could iterate purely at the contract and bundler level. The cost is the architectural overhead: a separate mempool, separate gas accounting, and an extra ~60,000 gas per transaction relative to a vanilla EOA.
​

EIP-7702 is a protocol-level upgrade that landed on Ethereum mainnet as part of the Pectra hard fork on May 7, 2025. It introduces a new transaction type — SetCode (type 0x04) — that carries an authorization list. Each authorization in the list is a signed claim by an EOA giving its address temporary smart-contract code, scoped to a specific chain and nonce.
​

The mechanism in one sentence: when a SetCode transaction is executed, the EVM treats the authorizing EOA as if it ran the delegated contract's bytecode for the duration of that transaction.
​

The full spec is at eips.ethereum.org/EIPS/eip-7702. The key fields in an authorization are chain_id, address (the contract whose code the EOA delegates to), nonce, and the EOA's signature over those fields. Once an authorization is included on-chain, the delegation persists across transactions until the EOA's nonce moves past it (or the EOA explicitly revokes by delegating to the zero address).
​

EIP-7702 was designed by Vitalik Buterin and others specifically to solve the migration problem: hundreds of millions of EOAs already exist, with users who do not want to move to a new address. With 7702, those users keep their address, their on-chain history, and their relationships, while gaining smart-wallet behavior whenever they sign a delegation.
​

A SetCode transaction is a regular Ethereum transaction (carrying value, calldata, gas) plus an authorization list. The transaction's sender pays the base gas. The authorization list grants temporary code to one or more EOAs.

This structure has a useful property: the EOA's signature on the authorization is independent of the outer transaction's sender. A relayer can submit the SetCode transaction on behalf of the EOA, paying the base gas. The EOA only needs to sign the authorization itself — the EOA does not need ETH at all to be delegated. This is how 7702 stacks support gasless onboarding for existing wallets that have no chain-native token.
​

The authorization is scoped to a chain_id, which prevents cross-chain replay. It is bound to a nonce, which prevents resubmission. And it is revocable by signing a fresh authorization to the zero address.
​

Two practical observations from this matrix.
​

First, cross-chain address consistency is easier with 7702. An EOA at 0xabc... on Ethereum is the same address on Base, Optimism, Arbitrum, and every other EVM chain — that's how secp256k1 derivation works. A 4337 smart account needs to deploy at a deterministic address (CREATE2 with a fixed factory and init bytecode), which is doable but adds operational discipline. For chains where the same wallet should resolve identically, 7702 is the simpler path.
​

Second, 4337 is more flexible per chain. The smart account contract is a separate deployment, so a wallet can implement different logic on different chains, ship upgrades without touching the user's address, and use whichever signature scheme the contract supports. 7702 ties the user's experience to whichever contract they have most recently delegated to.
​

Yes. The two mechanisms compose. The most common pattern in 2026 is:
​

A 7702 delegation points the user's EOA at a smart-account implementation that also conforms to ERC-4337's validateUserOp interface. The user can then either:

This dual-mode operation means an existing wallet (MetaMask, Rabby, Coinbase Wallet) can offer both flows from the same address. A user might use 7702 delegation for batched approvals from their main EOA, and 4337 UserOps for sponsored gas-free onboarding to a new dApp. The Pectra-aware versions of these wallets are shipping exactly this pattern.
​

The Ethereum Foundation's smart-account spec WG has been iterating on a unified ERC-7579 modular account standard that both 4337 and 7702 implementations can target, so the dual-mode path is increasingly the default.
​

By April 2026:

The big retrofit story is MetaMask. With 30+ million monthly active users, MetaMask's adoption of EIP-7702 in late 2025 unlocked smart-wallet UX for the largest existing EOA user base. Users can opt into delegation, get batched approvals, sponsored gas, and session keys, without needing to move funds to a new address.
​

The big new-wallet story is Coinbase Smart Wallet. Built natively on ERC-4337 with passkey signatures, deployed deterministically across chains via CREATE2, and integrated directly into Coinbase's bundler and paymaster infrastructure. Coinbase Smart Wallet has surpassed many EOA-based wallets in new-account creation rate as of Q1 2026.
​

The infrastructure mix has settled into a clear pattern. Pimlico and Alchemy dominate the bundler-as-a-service category, processing roughly 65% of all UserOperations as of Q1 2026 according to BundleBear's operator dashboard. ZeroDev leads the modular account framework category for ERC-4337-native deployments. Safe remains the dominant treasury account, with Safe{Core} adapters that bridge into both 4337 UserOps and 7702 delegations. Biconomy and Stackup round out the bundler set with strong gas-sponsorship products. The fact that the same six vendors serve both 4337 and 7702 traffic confirms the dual-mode story: from the SDK side, the two paths are converging on a unified developer surface.
​

A practical decision tree.
​

Use ERC-4337 if:

Use EIP-7702 if:

Use both if you are building infrastructure that needs to interop with the broadest possible wallet set — meaning bundler operators, paymaster services, and SDK vendors should support both flows. The full SDK landscape is in Best Smart Wallet SDKs for Developers.
​

For stablecoin apps the choice between 7702 and 4337 mostly comes down to where users already are.
​

A new stablecoin product onboarding fresh users will typically pick a 4337 smart wallet — Coinbase Smart Wallet for retail, Safe for treasury — because it gives the cleanest deterministic-address, paymaster-friendly experience. Gas paid in USDC, batched approve-and-swap, no chain-native token required. The deeper integration pattern is in Account Abstraction for Stablecoin Apps.
​

A treasury team retrofitting an existing operational wallet — say, a multisig EOA that's been holding USDC for two years and has a long history of approved counterparties — will lean on EIP-7702. The address stays the same, the counterparty whitelists stay valid, and the team gains batched operations and policy enforcement without rotating keys or re-onboarding integrations. Eco Routes works with both shapes; an intent submitted from a 7702-delegated EOA looks identical to one submitted from a 4337 smart account, and the routing layer (CCTP, Hyperlane, LayerZero) selects the destination rail the same way.
​

One concrete example: a stablecoin payroll product paying contractors in USDC across Base, Arbitrum, and Polygon can use a 7702-delegated treasury EOA to batch 200 transfers into a single SetCode transaction, paying gas in ETH at the outer-tx layer while the authorization itself costs nothing for the contractor recipients. If the same product later wants to add new contractors who have never held a wallet, those onboarding flows route through a 4337 smart account with passkey signatures — no seed phrase, no chain-native token. Both flows settle into the same USDC liquidity, and Eco Routes handles the cross-chain leg whenever a payment needs to land on a chain other than where the funds sit.
​

No. The Ethereum Foundation and major wallet teams have been explicit that 7702 and 4337 are complementary, not competitive. 4337 is for new smart wallets where the account is a contract from day one. 7702 is for upgrading existing EOAs to smart-wallet behavior. Most production stacks now support both flows from the same wallet implementation.
​

Yes, if the contract it delegates to implements the ERC-4337 validateUserOp interface. This dual-mode pattern is the most common deployment shape in late 2025 and 2026 — one wallet contract supports both regular Ethereum transactions (via 7702) and bundler-relayed UserOperations (via 4337).
​

Not yet. EIP-7702 requires the Pectra hard fork or an equivalent upgrade. Ethereum mainnet enabled it on May 7, 2025, and most major L2s (Base, Optimism, Arbitrum) followed within weeks. A handful of sidechains and smaller L2s still trail. ERC-4337, by contrast, works on every EVM chain because it requires no consensus change.
​

An authorization is bound to chain_id and nonce, so it cannot be replayed on a different chain or after the EOA's nonce moves past it. The signature is over those fields; tampering invalidates the signature. The standard pattern is to sign an authorization just before submitting the SetCode transaction, minimizing the window where the authorization is unused.
​

Only when you opt in. Wallets that support EIP-7702 typically expose it as a "smart account" or "upgrade" flow — you sign one authorization and your EOA gains batched-tx, sponsored-gas, and session-key behavior. The default for most wallets remains plain EOA mode for backward compatibility.
​

Sign a fresh authorization that delegates to the zero address (0x000...000). Submit a SetCode transaction carrying that authorization. Once mined, the EOA returns to plain EOA behavior. Wallets typically expose this as a "remove smart account upgrade" UI flow.
​