EIP-7702: Ethereum Account Abstraction After Pectra
The Pectra upgrade quietly rewired what an Ethereum address can do. Here's the 2026 field guide to EIP-7702 — how smart EOAs work, what they unlock, and where the footguns are.
EIP-7702 lets any EOA sign a one-time authorization that points its address at a smart contract. For the lifetime of that authorization, the EOA executes that contract's code whenever it's called. Result: your existing wallet gets batching, gas sponsorship, session keys, and social recovery — without moving a single wei.
1. Why Pectra Mattered
Pectra (Prague + Electra) bundled together the execution- and consensus-layer upgrades that had been queuing since Dencun. Three changes stand out: EIP-7251 raised the validator max effective balance to 2,048 ETH, EIP-7691 doubled blob target throughput, and EIP-7702 — the one this guide is about — introduced a new transaction type that gives EOAs programmable behavior.
The account abstraction story on Ethereum had been stuck in a two-track stalemate: ERC-4337 delivered smart accounts but only at new addresses, while the vast majority of users and liquidity sat on EOAs. EIP-7702 collapses that divide. The address you've been using since 2017 can now behave like a Safe or a Kernel account, on demand.
2. How Delegation Actually Works
EIP-7702 introduces transaction type 0x04, which carries a list of authorization tuples. Each tuple is a signature from an EOA authorizing a specific implementation contract address, scoped to a chain ID and nonce.
When the block is processed, each authorized account has its code field set to a 23-byte pointer: 0xef0100 || implementation_address. From that moment on, any call to the EOA runs the delegate's bytecode in the EOA's storage context. The EOA is still the “from” address, still pays its own gas (unless sponsored), and still holds its own balance.
Crucially, the delegation persists across transactions until it's explicitly overwritten with a new authorization — including one that points to the zero address to revert to a plain EOA.
EIP-7702 vs ERC-4337 at a glance
- Address: 7702 keeps your existing EOA address. 4337 gives you a new contract address.
- Mempool: 7702 uses the normal mempool. 4337 uses the UserOperation mempool and bundlers.
- Upgrade path: 7702 is a signature. 4337 is a deployment.
- Revocation: 7702 can be revoked with a single authorization. 4337 accounts are immutable unless the implementation is upgradeable.
- Compatibility: 7702 and 4337 compose — a 7702-delegated EOA can itself be a 4337 entry point.
3. What It Unlocks
The UX wins are the obvious headline, but the deeper story is that app developers can finally assume programmable accounts for the 200M+ existing Ethereum EOAs. The patterns worth knowing in 2026:
- Atomic batching — approve + swap + stake in one signature, no more stuck approvals.
- Sponsored gas — apps pay fees on the user's behalf via a paymaster, enabling onboarding without ETH.
- Session keys — games and trading apps get short-lived, scoped keys for frictionless interactions.
- Passkey signing — WebAuthn delegates let users authorize txs with Face ID or Touch ID.
- Spending limits & simulation — delegate contracts can enforce per-asset caps and reject suspicious calls client-side.
- Social recovery — guardians can rotate the delegate if a key is lost, without moving funds.
4. Security Trade-offs
EIP-7702 is powerful because the delegation signature is completely off-protocol — the chain has no opinion about which contract you point at. That's also why it's dangerous. If a user is tricked into signing an authorization for a malicious implementation, the attacker gets the same power the user has: full control of the EOA's balance and allowances.
The mitigations that have emerged in practice:
- Wallet allowlists — MetaMask, Rabby, and Frame ship with curated lists of audited delegates and warn loudly on unknown targets.
- Chain-scoped authorizations — always sign with a specific chain ID, never
0(which is valid on every chain). - Nonce discipline — reuse protection prevents signature replay across re-delegations.
- Simulation first — Tenderly, Blockaid, and GoPlus now preview the post-delegation bytecode before the user signs.
- Revocation UX — every major wallet surfaces a “reset to EOA” button that broadcasts a zero-address authorization.
5. The 2026 Landscape
A year after Pectra, the ecosystem has settled into a handful of dominant delegate implementations. Safe's 7702 module is the conservative default for treasuries. Biconomy's Nexus and Alchemy's Light Account dominate consumer apps because they ship with paymasters and session keys out of the box. ZeroDev's Kernel is the plug-in framework of choice for teams that need custom validation logic. For gaming, Privy and Dynamic wrap 7702 delegation behind embedded wallet SDKs so end users never see the concept.
On the infra side, paymaster volume has exploded — Coinbase Developer Platform, Pimlico, and Alchemy together sponsor more than 40% of L2 transactions in Q1 2026, most of them flowing through 7702-delegated EOAs on Base, Arbitrum, and Optimism.
6. Builder's Checklist
- Pick an audited delegate (Safe, Nexus, Kernel, Light Account). Don't roll your own.
- Scope authorizations to a specific chain ID and a finite nonce.
- Expose a revocation path in your UI. Users must be able to undo delegation in one click.
- Simulate the post-delegation call graph before signing — surface spending risk to the user.
- If you sponsor gas, meter carefully and rate-limit by address to prevent paymaster drain attacks.
- Remember storage collisions: delegate contracts share the EOA's storage slots. Use namespaced storage (ERC-7201) religiously.