ByAUJay
Pectra’s New Normal: What EIP-7702 Changes in Your Wallet Architecture
Summary: EIP-7702 is live on mainnet with Pectra (May 7, 2025), giving EOAs a protocol-native way to execute smart-wallet code at the same address. This post translates the spec into concrete architectural changes, integration pitfalls, and best practices for decision‑makers planning production wallets. (info.etherscan.com)
Why this matters now
The Pectra hard fork activated on Ethereum mainnet on May 7, 2025 (epoch 364,032), and it includes EIP‑7702 “Set Code for EOAs.” In practice, that means any externally owned account (EOA) can opt‑in to run smart‑wallet logic without changing its address—unlocking batching, sponsored gas, and granular permissions in the protocol itself. (info.etherscan.com)
For founders and enterprise teams evaluating blockchain UX, compliance, and cost, 7702 is not “just another EIP.” It changes wallet threat models, onboarding flows, KYC/AML observability, and the way you ship smart‑wallet features across chains.
What actually changed at the protocol layer (plain-English, spec-accurate)
- New transaction type: Type 0x04, “set code transaction,” adds an authorization_list to standard tx fields. It’s signed by the EOA and processed before calldata executes. A null destination is not valid for this tx type. (eips.ethereum.org)
- Authorizations are tuples: [chain_id, address, nonce, y_parity, r, s]. The client recovers the signer, checks a 64‑bit nonce, and then writes a delegation indicator into the EOA’s code. Multiple tuples can be processed in one tx. (eips.ethereum.org)
- Delegation indicator: The client writes 0xef0100 || address into the EOA’s code. From then on, CALL/CALLCODE/DELEGATECALL/STATICCALL to the EOA follows that pointer and runs the delegate’s code “in the EOA’s context.” This persists until you clear or change it. (eips.ethereum.org)
- Clear path: Setting the delegated address to 0x0 clears the indicator and restores the EOA to “pure EOA” semantics (a special-case in the spec to avoid persistent cold‑read penalties). (eips.ethereum.org)
- Multi‑chain signing: Each tuple’s chain_id may be 0 (wildcard) or the current chain, enabling “sign once, reuse across chains” patterns—if your delegate code addresses are canonicalized per chain. (eips.ethereum.org)
- Gas accounting: Intrinsic cost mirrors EIP‑2930 plus an added cost per authorization (PER_AUTH_BASE_COST = 12,500; PER_EMPTY_ACCOUNT_COST = 25,000). There’s an extra cold‑account read cost when resolving delegated code. (eips.ethereum.org)
- Origin semantics: Accounts with a valid 0xef0100 delegation indicator may originate transactions; 7702 also allows “self‑sponsoring” patterns that break the old invariant that tx.origin == msg.sender only in the top frame. Audit for code that relies on that check. (eips.ethereum.org)
- Code reading gotcha: EXTCODESIZE on the EOA returns the size of the indicator (23 bytes), while CODESIZE during delegated execution returns the delegate’s true runtime size. Contracts relying on EXTCODE* for detection can misbehave. (eips.ethereum.org)
- Edge cases: Precompiles targeted by delegation execute “empty code” (no‑op). Delegation loops are not recursively followed—clients stop at the first pointer. (eips.ethereum.org)
Tooling caught up the same day: Solidity 0.8.30 switched the default EVM target to “prague” (Pectra), so CI pipelines should bump compilers and re‑audit. (soliditylang.org)
What this means for wallet architecture
1) Your “account type” is now a deployment‑time decision, not an address migration
EIP‑7702 turns any EOA into a smart-wallet entrypoint by pointing it at a contract implementation. No new opcodes, no new address. The most robust pattern we see in the wild: treat the EOA as a proxy that delegates to a well-audited implementation such as an ERC‑1967 smart wallet. Coinbase’s reference 7702 proxy shows a practical, security‑minded recipe: signature‑gated initialization, external nonce tracking to prevent replay, ERC‑1967 storage slots, and safe handling of A→B→A re‑delegations. (github.com)
Takeaway for roadmaps:
- Plan “EOA upgrade” UX (one signed 7702 auth) instead of forcing users to migrate to a new contract account.
- Standardize on a canonical implementation address per chain to simplify multi‑chain 7702 flows (see chain_id=0 below).
2) Initialization cannot rely on initcode—defend against front‑running
7702 sets code without running initcode. That means your first call into the delegated wallet must initialize critical storage. The spec explicitly warns: verify that the initialization calldata is signed by the EOA via ecrecover, or an observer could front‑run your setup with hostile parameters. Design your delegate to reject any first‑call initialization not signed by the EOA’s key. (eips.ethereum.org)
3) Storage isolation is a first‑class risk
Because the EOA may delegate to different implementations over time, storage collisions between implementations can brick funds or create privilege escalation. Prefer namespaced layouts (e.g., ERC‑7201‑style storage roots) and provide a safe migration routine that clears/ports state. (eips.ethereum.org)
4) tx.origin invariants are broken—fix brittle anti‑MEV and reentrancy guards
7702 enables “self‑sponsored” execution where tx.origin can set code and then call into itself. If you rely on require(msg.sender == tx.origin) to prevent flash‑loan sandwiches or as a reentrancy guard, revisit it now. Use contemporary patterns (e.g., transient storage reentrancy guards, explicit allowlists) instead. (eips.ethereum.org)
5) Observability and indexing must recognize Type 0x04
- Etherscan and Blockscout expose 7702 transaction fields and delegation status so ops teams can audit authorizations. Update your internal indexers to parse authorization_list and flag delegation changes in real time. (info.etherscan.com)
- Contracts that gate on EXTCODE* must be regression‑tested against 7702’s code‑reading semantics difference. (eips.ethereum.org)
6) 4337 interplay: 7702 is the “on‑ramp,” not the whole highway
EIP‑7702 complements ERC‑4337 by letting any EOA delegate to a 4337‑compatible smart account implementation, so you can reuse paymasters, bundlers, and module ecosystems. Teams like MetaMask and Candide already provide SDKs and bundler/paymaster stacks that understand 7702 flows. (docs.metamask.io)
Practical guidance:
- Point your EOA to a 4337‑capable account implementation on each chain.
- Keep your 4337 “EntryPoint + Paymaster + Bundler” stack; 7702 simply changes how users reach it.
New design patterns you can ship this quarter
Pattern A: One‑transaction DEX swaps (no prior approvals)
- What: Batch ERC‑20 approval + swap into one transaction from an EOA.
- How: User signs a 7702 authorization; the delegated wallet executes approve() and exactInputSingle() atomically.
- Status: Live experiments—DeFi Saver has toggled 7702 support to do one‑transaction swaps. (help.defisaver.com)
Why enterprises care: Cuts failed swaps from missed approvals, reduces support load, and simplifies UX funnels.
Pattern B: Corporate gas sponsorship with revocable sub‑keys
- What: Treasury EOA delegates to a smart wallet that enforces per‑dApp spending limits, asset allowlists, and sponsored gas (paymaster).
- How: The delegated wallet issues time‑boxed session keys for teams/vendors; the relayer/bundler covers gas and invoices in stablecoins.
- Risk controls: Include app‑level nonce, target, calldata, value, and gas in the signed payload to prevent replay/griefing; the spec lists these as must‑cover fields. (eips.ethereum.org)
Pattern C: “HTTP 402 payments” for consumer apps
- What: A facilitator accepts a signed 7702 authorization + an EIP‑712 payment witness and submits a Type‑4 tx on the user’s behalf, pulling funds without ERC‑20 allowances.
- Why: Lower drop‑off for first‑time users with zero ETH; fits subscriptions and pay‑per‑use APIs.
- Status: Reference designs (q402) demonstrate sponsored 7702 flows with dual anti‑replay and witness binding. (github.com)
Pattern D: Seamless upgrade to a name‑brand smart wallet
- What: EOA delegates to a vetted ERC‑1967 implementation (e.g., Coinbase Smart Wallet) via a 7702 proxy.
- Why: Retain the address users know; inherit an audited codebase; gain interoperability across chains.
- How: Use a 7702 proxy that performs signature‑gated initialization and tracks a dedicated replay‑nonce; production addresses are published for all Coinbase‑supported networks. (github.com)
Security model updates you need to adopt
- Only whitelist known delegates. The spec cautions wallets not to expose a generic “delegate to arbitrary code” prompt—most users cannot audit unknown code. Maintain a curated list of audited implementations and modules. (eips.ethereum.org)
- Treat the EOA key as a root of trust—forever. Even after delegation, the EOA can re‑delegate or clear delegation; store its key offline and require guardians/multisig to move delegation. Safe’s guidance also emphasizes keeping the EOA key secure post‑authorization. (docs.safe.global)
- Replay protection at two layers. Application‑level nonces and 7702’s 64‑bit account nonce both matter; sponsors must assume authorizations can be invalidated mid‑flight (nonce increment or fund sweep). Consider bonds or reputation for relayers, as the spec recommends. (eips.ethereum.org)
- Watch for EXTCODE* heuristics. Dapps that used EXTCODESIZE/EXTCODEHASH as “is‑contract” checks will misclassify 7702 accounts; prefer explicit interfaces (ERC‑165) or allowlists. (eips.ethereum.org)
- Test precompile delegation. If someone points an EOA at a precompile address, execution is empty; ensure your wallet/relayer guards against nonsense delegates. (eips.ethereum.org)
Interop choices that reduce future lock‑in
- Adopt a modular account standard (ERC‑7579 or ERC‑6900) for your delegate implementation so you can reuse permission modules (session keys, spending limits, hooks) and swap components without rewriting the core. These standards aim for module interoperability across vendors. (eips.ethereum.org)
- Publish a canonical “delegate address per chain” map. Because 7702 supports chain_id = 0 in authorizations, teams can streamline cross‑chain UX if the same code hash is deployed consistently (or if you maintain a trusted resolver to the right address). (eips.ethereum.org)
- Align with existing explorers. Blockscout has shipped 7702 affordances; Etherscan documents 0x04 details and activation epochs. Mirror their structures in your internal observability to make forensic workflows familiar. (blog.blockscout.com)
Operational and cost implications you can quantify
- Gas: Plan for 12,500 gas per authorization entry, plus calldata and access list costs. Cold reads during delegation resolution add 2,600 gas. Benchmark your batch flows with and without 7702 to forecast savings in “two‑tx to one‑tx” approvals. (eips.ethereum.org)
- Calldata pricing: Pectra’s EIP‑7623 raised calldata cost for data‑heavy txs. If you bundle multiple authorizations or rich calldata in 7702 flows, expect a modest increase in calldata expense; offset by fewer round‑trips and avoided approvals. (soliditylang.org)
- CI and audits: Upgrade to Solidity 0.8.30 (evmVersion=prague), re‑run static analysis for tx.origin‑based guards, and add integration tests that simulate delegated execution (CODESIZE vs EXTCODESIZE differences). (soliditylang.org)
- Indexing: Extend your indexers and data warehouse schemas to:
- Parse authorization_list and attach it to the EOA’s timeline.
- Flag “delegate changed/cleared” events as high‑severity signals.
- Recompute risk scores when an EOA becomes delegated. (blog.blockscout.com)
Concrete integration playbook (cut here for your backlog)
- Choose your delegate implementation
- For fastest time‑to‑value, select a vendor wallet with 4337 support and a published 7702 proxy (e.g., Coinbase’s ERC‑1967‑based proxy). (github.com)
- If building in‑house, target ERC‑7579 compatibility from day one to access the module ecosystem. (eips.ethereum.org)
- Define initialization and migration
- On first call after delegation, require an EOA‑signed init payload (ecrecover) that sets owner keys, guardians, and policy modules; reject all others. (eips.ethereum.org)
- Use namespaced storage; publish a migration guide to future implementations (A→B) and a reversible “clear to 0x0” emergency playbook. (eips.ethereum.org)
- Harden the policy engine
- Implement spending limits, session keys, and app allowlists in modules; cover nonce, target, calldata, value, and gas in every off‑chain signature. (eips.ethereum.org)
- Add guardian‑based pause/clear mechanisms that can set delegate=0x0 under incident response.
- Wire 4337 infra
- Reuse your EntryPoint/Paymaster/Bundler; point 7702 EOAs at your 4337 smart account to enable gas sponsorship and batch ops from day one. SDKs from MetaMask and Candide already demo 7702 flows. (docs.metamask.io)
- Update developer and ops tooling
- Compiler/toolchain: solc 0.8.30; Hardhat/Foundry/Anvil with prague forks; gas benchmarks. (soliditylang.org)
- Observability: parse Type 0x04, display delegate status, diff authorization_list, and create alerts on delegation changes (explorers already do this). (blog.blockscout.com)
- Training: brief your support and compliance teams on what “EOA with code” means for investigations and customer comms.
- Pilot real UX wins
- Roll out one‑tx swaps for targeted tokens (DEX flow).
- Launch “gasless” onboarding for new users with paymasters.
- Offer enterprise sub‑keys with spending limits per app.
Pitfalls and edge cases to test before production
- Precompiles as delegates: Delegating to a precompile runs empty code; add a guard. (eips.ethereum.org)
- Delegation loops: Clients stop after the first pointer; don’t assume chainable indirection. (eips.ethereum.org)
- Sponsor griefing: If your relayer pays gas, users can invalidate authorizations or sweep balances; require bonds/reputation and fail‑closed on funding gaps. (eips.ethereum.org)
- tx.origin‑based checks: Replace them; 7702 breaks top‑frame assumptions. (eips.ethereum.org)
- Explorer heuristics: “Is contract?” checks via EXTCODE* mislead under 7702; integrate interface checks or first‑class “delegated account” labels. (eips.ethereum.org)
The ecosystem is already integrating
- Etherscan documents Pectra activation and 7702 tracking; Blockscout shipped UI for 0x04 and 7702 “EOA+code” pages you can mirror internally. (info.etherscan.com)
- Wallet vendors and infra providers are adding 7702 flows: MetaMask’s Smart Accounts Kit quickstart; Candide’s bundler/paymaster stack; Safe’s guidance for signing and security. (docs.metamask.io)
- Open‑source example repos (try‑eip‑7702 playgrounds, 7702 proxies) exist to bootstrap your experiments. (github.com)
Bottom line for decision‑makers
EIP‑7702 gives you a pragmatic path to ship smart‑wallet UX from your users’ existing addresses—no migrations, no proprietary opcodes. Use it to standardize your cross‑chain smart‑account story, compress onboarding from two transactions to one, and enable sponsored gas with enterprise‑grade controls. Just treat delegation like a production upgrade: guard initialization, namespace storage, re‑audit tx.origin assumptions, and operationalize Type 0x04 monitoring.
If you want a 4–6 week pilot plan: pick a canonical delegate on two chains, implement one‑tx swaps plus a basic paymaster, integrate explorer‑level observability, and harden with ERC‑7579 modules. From there, scale globally with chain_id=0 authorizations and a shared policy engine. (eips.ethereum.org)
7Block Labs can help you ship a 7702‑enabled smart‑wallet stack—with audited delegates, paymaster economics, and observability—without pausing your roadmap.
Like what you're reading? Let's build together.
Get a free 30‑minute consultation with our engineering team.

