EIP-7702 and EIP-7702 Set Code for EOAs: Account Abstraction Beyond EIP-4337

EIP‑7702 gives every legacy EOA a protocol‑native path to run smart‑account code at the same address, shipping on Ethereum mainnet with the Pectra hard fork on May 7, 2025. For decision‑makers, the practical takeaway is simple: pair 7702 with ERC‑4337 to cut UX friction and costs without migrating user addresses. (blog.ethereum.org)

Who this is for (and what you’ll learn)

If you own product, platform, or wallet strategy for a startup or enterprise, this post shows exactly:

What 7702 actually shipped with Pectra (dates, tx type, gas constants). (blog.ethereum.org)
How 7702 works under the hood (authorization tuples, “delegation indicator,” origination rules). (eips.ethereum.org)
How to combine 7702 with ERC‑4337 infra you already use (EntryPoint versions, bundlers, paymasters). (github.com)
Reference patterns, step‑by‑step implementation notes, and hard numbers you can plan around. (viem.sh)
Emerging risks and the guardrails enterprises are adopting. (eips.ethereum.org)

What actually shipped in Pectra

Activation: mainnet epoch 364,032 at 10:05:11 UTC on May 7, 2025. (blog.ethereum.org)
Scope: Meta‑EIP 7600 lists 7702 among the included core EIPs (alongside 7691 blob throughput, 7251 staking cap, etc.). (eips.ethereum.org)
L2 rollout: Arbitrum adopted 7702 via ArbOS 40 “Callisto,” aligning with Pectra semantics. Expect similar enablement across other rollups. (docs.arbitrum.io)

Why this matters: 7702 is the first protocol‑level bridge from EOAs to smart‑account capabilities, reducing the need for per‑user contract deployment and letting you upgrade existing addresses in place. (eips.ethereum.org)

EIP‑7702 in one slide: the Set Code transaction

New typed transaction: type 0x04 with an authorizationList. (eips.ethereum.org)
Authorization tuple format and signing:
- Each tuple is [chain_id, address, nonce, y_parity, r, s].
- The EOA signs keccak(MAGIC || rlp([chain_id, address, nonce])) and the tx itself signs over the RLP payload. (eips.ethereum.org)
What happens on-chain:
- Clients write a “delegation indicator” to the EOA’s code slot: 0xef0100 || address. From then on, CALL/CALLCODE/DELEGATECALL/STATICCALL to that EOA execute code from the delegate address in the EOA’s context. (eips.ethereum.org)
- Clearing: delegating to the zero address resets the account’s code hash to empty, restoring a plain EOA. (eips.ethereum.org)
- Origination: EIP‑3607 is relaxed so EOAs with a valid delegation indicator can originate transactions. (eips.ethereum.org)

Developer gotchas you’ll want engineering to internalize:

EXTCODESIZE returns the 23‑byte size of the indicator, while CODESIZE/CODECOPY during delegated execution operate on the real code at the target. This mismatch is intentional; audit any code‑size assumptions. (eips.ethereum.org)
Clients follow only one hop (no infinite delegation chains). Delegations pointing at precompiles are treated as empty code. (eips.ethereum.org)

Gas, costs, and performance you can plan against

Intrinsic gas baseline follows EIP‑2930 plus per‑auth overhead:
- PER_AUTH_BASE_COST = 12,500 gas; PER_EMPTY_ACCOUNT_COST = 25,000 gas.
- Cold account lookup when resolving delegated code adds 2,600 gas; warm = 100. (eips.ethereum.org)
Compared to deploying a new smart account (>500k gas typical), 7702 lets you “upgrade in place” for tens of thousands of gas plus your actual call data, avoiding address migration. (quicknode.com)
ERC‑4337 overhead still applies when you use EntryPoint flows (tens of k gas per UserOp depending on account/paymaster logic). EntryPoint v0.7’s 10% unused‑gas penalty affects gas cap estimates; plan conservative margins. (github.com)

Bottom line: for greenfield and brownfield wallets alike, 7702 reduces cold‑start costs and lets you keep existing 4337 routes for sponsorship, batching, and custom validation. (eips.ethereum.org)

7702 vs. 4337: how they fit in real stacks

7702 is protocol‑level delegation: it gives any EOA a pointer to audited wallet code and persists until changed/cleared. (eips.ethereum.org)
ERC‑4337 is the infrastructure layer: UserOperations, bundlers, paymasters, and a canonical EntryPoint on each network. v0.7 address: 0x0000000071727De22E5E9d8BAf0edAc6f37da032; v0.6: 0x5FF1…; v0.8 deployments emerging. (github.com)

What it means for you: Upgrade EOAs via 7702 to run a 4337‑compatible implementation at the same address. Keep your bundlers and paymasters; you just cut the “deploy fresh account” step and many proxy hops. (eips.ethereum.org)

Pattern A — “4337 inside” at the same address

Use 7702 to delegate an EOA to a 4337‑compatible smart account (e.g., Simple7702Account or your wallet’s implementation). You keep all 4337 capabilities and tooling, while eliminating fresh deployments.

Choose implementation: Simple7702Account (audited; ERC‑1271 support) or a production wallet implementation. (docs.candide.dev)

Sign an authorization and set code with your signer:

// viem 7702 flow
const authorization = await walletClient.signAuthorization({
  account: eoa, 
  contractAddress: delegateImpl, 
  executor: 'self' // if the EOA also executes the tx
})

const hash = await walletClient.writeContract({
  abi, 
  address: eoa.address, // call into the EOA (now delegated)
  functionName: 'initialize',
  args: [initData],
  authorizationList: [authorization],
})

(viem.sh)

Keep your EntryPoint v0.7 bundlers and paymasters unchanged. For v0.8 pilots, confirm address and simulation support with providers. (alchemy.com)

When to choose it: you already run 4337 infra; you need sponsorship, session keys, or enterprise policy engines. (eips.ethereum.org)

Pattern B — Minimal 7702 account for native batching

If you only need 1‑tx approve+use or simple multicalls, delegate to a minimal batched‑calls implementation and avoid 4337 complexity.

Ethers.js and viem both support type: 4 and authorizationList:

// ethers example: batch ETH transfers via delegated contract at the EOA address
const auth = await createAuthorization(currentNonce + 1)
const tx = await delegatedContract["execute((address,uint256,bytes)[])"](calls, {
  type: 4,
  authorizationList: [auth],
})

(quicknode.com)

Still use 4337 later by switching the delegation target to a 4337 wallet implementation. (eips.ethereum.org)

When to choose it: high‑throughput UX wins with low surface area; no sponsorship or alt‑mempool yet.

Pattern C — Policy‑driven automation with wallet‑managed permissions

Layer human‑readable permissions on top of your 7702 smart accounts using ERC‑7715 (MetaMask Smart Accounts Kit).

Request permissions from the wallet via wallet_grantPermissions; supports spending caps and periodic transfers. Requires a wallet that supports ERC‑7715 (MetaMask Flask today). (docs.metamask.io)
Combine with ERC‑7710 “delegation manager” if your app issues delegations that other agents redeem on users’ behalf. (ercs.ethereum.org)

When to choose it: subscriptions, AI‑agent automations, trading bots with escrowed allowances.

A concrete migration playbook (brownfield EOAs)

Inventory and target cohort

Identify EOA users you can safely “upgrade.” Provide an in‑wallet flow to sign a 7702 authorization that points at your audited smart‑account code. (eips.ethereum.org)

Delegate to an audited implementation

Option A: immutable wallet code deployed via CREATE2.
Option B: vetted proxy that adds external nonce tracking and validator hooks (e.g., Coinbase EIP‑7702 Proxy) to prevent replay and unsafe init. (eips.ethereum.org)

Initialize safely, atomically

Initialize state in the same transaction you set code, and verify init payloads were signed by the EOA’s key to prevent front‑run/replace of initial values. (eips.ethereum.org)

Namespaced storage to future‑proof upgrades

Use ERC‑7201 to root state and avoid storage collisions across future delegates. Codify the namespace in NatSpec. (eips.ethereum.org)

Keep 4337 infra steady

Keep EntryPoint v0.7 routes in production; test v0.8 in canaries and validate bundler simulation toolchain. (github.com)

Ship revocation and recovery

Provide a one‑click “restore to EOA” that delegates to zero address and resets code. Document incident playbooks. (eips.ethereum.org)

L2 rollout plan

Track each L2’s Pectra‑compat release (e.g., Arbitrum ArbOS 40) before toggling 7702 by default on that network. (docs.arbitrum.io)

Security realities and the controls to adopt

7702 empowers—but also expands—the blast radius of a bad signature. Adopt the following as non‑negotiable:

Only allow delegations to a short allowlist of audited code; do not prompt users to sign raw 7702 authorizations in the dapp. This aligns with 7702’s guidance to keep delegation flows in wallets, not sites. (eips.ethereum.org)
Replay safety and external nonces in your delegate contract. Without them, signatures can be replayed; your sponsor can be griefed. (eips.ethereum.org)
tx.origin invariants: 7702 breaks assumptions like require(msg.sender == tx.origin) as a reentrancy guard or sandwich‑attack mitigation. Audit those patterns. (eips.ethereum.org)
SOC detections for “sweeper” code hashes: post‑Pectra, researchers report large shares of on‑chain delegations pointing to sweeper bytecode clusters used to drain compromised EOAs. Monitor and block known indicators. (holder.io)
Educate: users should only accept “upgrade to smart account” prompts from their wallet’s native UI, not web pop‑ups. Multi‑chain authorizations with chain_id=0 can be replayed on other EVM chains—warn users and default to chain‑specific authorizations. (frameworks.securityalliance.org)

Wallet and infra builders: if you sponsor 7702 txs, require bonds or reputation for relayers to avoid unreimbursed gas when authorizations get invalidated mid‑flight. (eips.ethereum.org)

Developer details your team will ask about

EIP constants and validation: SET_CODE_TX_TYPE=0x04, MAGIC=0x05; tuple bounds and processing order (nonce increment before authorization processing). (eips.ethereum.org)
Affected opcodes: code‑executing ops load delegate code; code‑reading mismatches are by design. (eips.ethereum.org)
Mempool behavior: once an account is delegated, other pending txs can become stale; node propagation rules account for this. Don’t assume static validity. (eips.ethereum.org)
Tooling support:
- viem: signAuthorization(), send type‑4 with authorizationList; full guides available. (viem.sh)
- ethers.js: Type 4 examples exist; v6 issues tracked/resolved in repo. (quicknode.com)
- Alchemy/Candide SDKs: EntryPoint addresses, Simple7702Account, and deployment references. (docs.candide.dev)

Governance context: 7702 replaced 3074

EIP‑3074 (AUTH/AUTHCALL) was withdrawn; core devs moved to 7702 for better forward‑compatibility with “endgame AA” while reducing opcode surface. If you still rely on 3074 docs, update roadmaps to 7702. (eips.ethereum.org)

Reference architecture: 7702 + 4337 for production

Delegation layer (7702): EOA → audited wallet implementation (e.g., Simple7702Account or your brand wallet). (docs.candide.dev)
Execution/validation (4337): UserOps via EntryPoint v0.7, bundlers simulate and sponsor via paymasters; enforce ERC‑7562 validation rules. (docs.erc4337.io)
Permissions (optional): ERC‑7715 wallet‑mediated grants; ERC‑7710 for redeemable delegations across agents. (docs.metamask.io)

KPIs to watch after rollout: upgrade success rate, median 7702 authorization gas, time‑to‑first‑sponsored‑UserOp, paymaster rejection reasons, and sweeper‑hash detection rate.

Example: upgrading an EOA and batching immediately

User signs a 7702 authorization in‑wallet pointing to your wallet implementation.
Your app sends a type‑4 tx with authorizationList and data that calls initialize().
Immediately batch approve+swap in the same delegated call path (no separate approve tx):

// 1. authorize + 2. initialize delegated account
const auth = await walletClient.signAuthorization({
  account: eoa, contractAddress: walletImpl, executor: 'self'
})
await walletClient.writeContract({
  abi: walletAbi,
  address: eoa.address,
  functionName: 'initialize',
  args: [initParams],
  authorizationList: [auth],
})

// 3. batched approve+swap through the EOA address (now delegated)
const batch = [
  { target: USDC, value: 0n, callData: approveData },
  { target: router, value: 0n, callData: swapData },
]
await walletClient.writeContract({
  abi: walletAbi,
  address: eoa.address,
  functionName: 'executeBatch',
  args: [batch],
})

(viem.sh)

Choosing between options (decision matrix)

You must keep user addresses: 7702 is table stakes; delegate to your chosen smart‑account code. Use 4337 if you want sponsorship and mature tooling. (eips.ethereum.org)
You already operate a 4337 stack: add 7702 to cut cold‑start overhead; keep bundlers/paymasters. (alchemy.com)
You need human‑readable, revocable automation: add ERC‑7715 for permissioned flows. (docs.metamask.io)

Final takeaways for decision‑makers

Pectra made 7702 real on May 7, 2025; L2s are following suit. Treat 7702 as an address‑preserving upgrade rail. (blog.ethereum.org)
Best results come from 7702 + 4337 together: keep the infra (EntryPoint, bundlers, paymasters), but drop the per‑user deployment friction. (alchemy.com)
Invest in controls: wallet‑side allowlists, namespaced storage, replay‑safe init, and SOC detections for sweeper code. The UX win is real—but so is the new attack surface. (eips.ethereum.org)

Sources and specs worth bookmarking

EIP‑7702 spec (type 0x04, authorizationList, gas constants, security). (eips.ethereum.org)
EF Pectra mainnet announcement and EIP‑7600 meta. (blog.ethereum.org)
ERC‑4337 spec + bundler docs; EntryPoint v0.7 address and provider support. (eips.ethereum.org)
Viem 7702 APIs and examples; QuickNode ethers guide. (viem.sh)
Arbitrum ArbOS 40 docs (7702 on L2). (docs.arbitrum.io)
ERC‑7201 namespaced storage. (eips.ethereum.org)
ERC‑7715 permissions and ERC‑7710 delegation. (docs.metamask.io)

7Block Labs helps teams plan, ship, and harden 7702/4337 stacks across L1 and the major L2s. If you want a threat‑model‑driven rollout with audited delegates, migration tooling, and SOC detections ready on day one, we’re happy to help.

EIP-7702 and EIP-7702 Set Code for EOAs: Account Abstraction Beyond EIP-4337

Who this is for (and what you’ll learn)

What actually shipped in Pectra

EIP‑7702 in one slide: the Set Code transaction

Gas, costs, and performance you can plan against

7702 vs. 4337: how they fit in real stacks

Pattern A — “4337 inside” at the same address

Pattern B — Minimal 7702 account for native batching

Pattern C — Policy‑driven automation with wallet‑managed permissions

A concrete migration playbook (brownfield EOAs)

Security realities and the controls to adopt

Developer details your team will ask about

Governance context: 7702 replaced 3074

Reference architecture: 7702 + 4337 for production

Example: upgrading an EOA and batching immediately

Choosing between options (decision matrix)

Final takeaways for decision‑makers

Sources and specs worth bookmarking

Like what you're reading? Let's build together.

Related Posts

Ethereum.org Run a Node Hardware Requirements 2026 and Base Node Requirements for New Validators

Ethereum Full Node Disk Size 2026, Ethereum Full Node Storage Requirements 2026, and Ethereum Full Node Size 2026

EIP-7702 and EIP-7702 Set Code for EOAs: Account Abstraction Beyond EIP-4337

Who this is for (and what you’ll learn)

What actually shipped in Pectra

EIP‑7702 in one slide: the Set Code transaction

Gas, costs, and performance you can plan against

7702 vs. 4337: how they fit in real stacks

Practical implementation patterns we recommend

Pattern A — “4337 inside” at the same address

Pattern B — Minimal 7702 account for native batching

Pattern C — Policy‑driven automation with wallet‑managed permissions

A concrete migration playbook (brownfield EOAs)

Security realities and the controls to adopt

Developer details your team will ask about

Governance context: 7702 replaced 3074

Reference architecture: 7702 + 4337 for production

Example: upgrading an EOA and batching immediately

Choosing between options (decision matrix)

Final takeaways for decision‑makers

Sources and specs worth bookmarking

Like what you're reading? Let's build together.

Related Posts

Ethereum.org Run a Node Hardware Requirements 2026 and Base Node Requirements for New Validators

Ethereum Full Node Disk Size 2026, Ethereum Full Node Storage Requirements 2026, and Ethereum Full Node Size 2026