Wallets After Pectra: A Migration Plan from ERC-4337 Tooling to EIP-7702

Description: Pectra put EIP-7702 on mainnet, giving EOAs a standards-based path to smart-account behavior without abandoning ERC-4337. This playbook shows decision-makers how to phase in 7702 safely, reuse 4337 infra, and ship measurable UX gains in weeks—not quarters.

TL;DR for decision‑makers

EIP‑7702 is live on mainnet (May 7, 2025). It adds a new transaction type (type 0x04) that lets an EOA set a “delegation indicator” pointing to deployed contract code—effectively upgrading the EOA into a smart account at the same address until revoked. This shipped as part of Pectra (Prague × Electra). (eips.ethereum.org)
Don’t “replace” 4337—compose with it. The winning pattern in 2025 is 7702 for address continuity + 4337 (EntryPoint v0.8) for sponsored gas, session keys, and modular security. EntryPoint v0.8 adds native 7702 support and a new canonical address. (github.com)
Budget for two protocol side effects: calldata repricing (EIP‑7623) that nudges you to optimize UserOperation payloads, and higher blob capacity (EIP‑7691) that lowers L2 DA costs. Both shipped in Pectra. (eips.ethereum.org)

What actually changed with Pectra (wallet‑relevant only)

Activation: Pectra activated on Ethereum mainnet at epoch 364032 on May 7, 2025, 10:05:11 UTC. (eips.ethereum.org)
EIP‑7702 (Set EOA account code):
- New tx type (0x04) carries an authorization list of tuples: [chain_id, address, nonce, y_parity, r, s].
- Each tuple is signed by the EOA; clients write a delegation indicator to the EOA’s code (0xef0100 || address).
- Delegation persists until changed; reset by delegating to the null address.
- Type‑4 transactions intentionally do not include blob data and do not create contracts—scope is focused on UX upgrades. (eips.ethereum.org)
EIP‑7623 (Increase calldata cost): data‑heavy txs pay a floor price (10/40 gas per zero/non‑zero byte), reducing worst‑case block size variance. 4337 payloads with large calldata should be re‑audited. (eips.ethereum.org)
EIP‑7691 (More blobs): target/max blobs per block increased to 6/9, improving L2 DA capacity and fees; paired with 7623 to keep bandwidth in check. (eips.ethereum.org)
Tooling ripple: Solidity 0.8.30 switched default EVM target to “prague” on May 7, 2025—upgrade CI before shipping 7702 code paths. (soliditylang.org)

EIP‑7702: how it actually works (nuts & bolts)

Transaction type: 4 (0x04). Payload includes an authorization_list (≥1 tuples). A tuple authorizes an EOA to delegate to contract code at address on a given chain_id and EOA nonce, signed by the EOA (y_parity, r, s over a defined hash). (ethereum.org)
State effect: Clients write a “delegation indicator” into the EOA’s code so CALL behavior dispatches into the delegate’s bytecode. The EOA can later update or clear that pointer (delegate to address(0)). (eips.ethereum.org)
Scope constraints:
- No contract creation and no blobs in type‑4.
- Transaction propagation nuance: clients are advised not to accept more than one pending tx from an EOA with a non‑zero delegation indicator to avoid static‑validity issues. (eips.ethereum.org)
Security posture expected by protocol authors: dapps should not prompt users to sign raw 7702 authorizations; wallets must gate and audit the delegated code and use standardized module systems on top. (eips.ethereum.org)

What this means for you: treat 7702 authorizations like “account firmware updates.” Only your wallet app (or enterprise policy engine) should generate and present them, after deterministic checksums and audits of the delegate bytecode.

ERC‑4337 in late‑2025: what to keep, what to upgrade

EntryPoint v0.8 shipped with native support for 7702 authorizations, ERC‑712 userOp hashing, relaxed unused‑gas penalty (<40k ignored), and an official address (distinct from v0.7). If you’re still on 0.6/0.7, plan a staged upgrade. (github.com)
Common addresses:
- EntryPoint v0.7: 0x0000000071727De22E5E9d8BAf0edAc6f37da032 (multi‑chain singleton)
- EntryPoint v0.6: 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789
  Providers are deprecating 0.6 over 2026; align roadmaps now. (alchemy.com)
Shared mempool and ERC‑7562 validation rules are the operational backbone for reliable bundling. Keep your bundler in compliance to avoid reputation throttling. (etherspot.io)
Ecosystem signal: leading bundlers (e.g., Skandha) already support EntryPoint v0.8 and 7702‑aware flows across major EVM chains. (etherspot.io)

The migration plan: from ERC‑4337‑only to 7702 + 4337

We recommend a 3‑phase plan that preserves production reliability while surfacing quick UX wins.

Phase 0 — Baseline upgrades (1–2 sprints)

Upgrade your toolchain: Solidity 0.8.30 (EVM “prague”), test all deployments in forks configured for Pectra gas rules. Validate gas estimators now account for the 7623 calldata floor. (soliditylang.org)
Bump AA infra:
- EntryPoint v0.8 on networks you support; where not feasible, lock v0.7 and document the delta for QA.
- Confirm bundler compliance with ERC‑7562.
- Update allowlists for EntryPoint addresses in on‑chain registries and off‑chain risk engines. (github.com)
L2 check: if you rely on sponsored flows on rollups, note 7702 support already landed on major L2s (e.g., Arbitrum via ArbOS 40). Validate chain‑id–scoped authorizations in staging. (docs.arbitrum.io)

Phase 1 — 7702 for address continuity, 4337 for power features (2–4 sprints)

Adopt one of these patterns per product line:

7702‑as‑gateway (most teams)

Delegation target = a 4337‑compatible smart account implementation (e.g., your existing account logic) behind a minimal proxy designed for 7702.
Benefit: users keep their EOA address; you keep 4337 features (sponsored gas, session keys, plugins).
Known‑good patterns: EIP7702Proxy (ERC‑1967 proxy hardened for 7702 init, replay‑safe externally tracked nonce, UUPS upgrades). (github.com)

Pure‑7702 batching (specific flows)

For apps that mainly need atomic multi‑calls (approve + swap + stake) or occasional sponsor‑gas UX, delegate to a thin “batcher” contract.
Keep a one‑click revoke path (delegate to zero address).
Caveat: you lose 4337‑style modules/guardians unless you compose them explicitly. (eips.ethereum.org)

Hybrid per‑segment

Consumer app (pure 7702 batching), enterprise treasury (7702→4337 modular account).
Use policy engines to block chain_id = 0 authorizations (multi‑chain) outside enterprise contexts. (ethereum.org)

Phase 2 — 7702 authorization UX, risk, and observability (ongoing)

UX hard‑stops: Never allow arbitrary dapps to prompt a 7702 authorization. Only show upgrade prompts initiated from your wallet’s settings or verified in‑app flows. Present code hashes, semantic diffs, and audit links before signing. This aligns with the EIP’s explicit guidance. (eips.ethereum.org)
Replay & scope controls:
- Bind authorizations to chain_id where possible; reserve chain_id = 0 for specialist multi‑chain ops.
- Enforce EOA nonce binding per tuple (the spec’s field) and maintain an external nonce tracker inside 7702 proxy flows to prevent reuse. (eips.ethereum.org)
Pending‑tx policy: your relayer should accept at most one pending tx for delegated EOAs (mirrors client guidance). Back‑pressure additional requests until mined. (eips.ethereum.org)
Revocation & rotation: implement one‑tap delegation reset (to null address) in wallet security center; add scheduled “rotation” reminders. Some wallets already expose 7702 delegation revocation UX—use that as a usability bar. (outposts.io)
Metrics we track for customers:
- Type‑4 (7702) tx share, first‑time delegation success rate, time‑to‑first‑sponsored‑action.
- 4337 bundle acceptance rate and 7562 rule violations by entity.
- Gas delta per canonical task (e.g., “approve+swap”) vs legacy 2‑tx flows on each chain.

Practical examples (cut‑and‑adapt)

A. Minimal 7702 authorization + upgrade to your 4337 account

Concept: delegate an EOA to an audited 7702‑hardened proxy that points to your current 4337 implementation.

// Pseudocode using viem-like utils
import { keccak256, encodeRlp, sign, sendTx } from "./sdk";

// 1) Build authorization tuple for chain_id=1 (Ethereum)
const tuple = {
  chainId: 1,
  delegate: "0x7702cb554e6bFb442cb743A7dF23154544a7176C",  // EIP7702Proxy singleton
  nonce: await getEoaNonce(eoa),
};
// Per EIP-7702 spec: hash = keccak(0x05 || rlp([chain_id, address, nonce]))
const authHash = keccak256(
  "0x05" + encodeRlp([tuple.chainId, tuple.delegate, tuple.nonce]).slice(2)
);
const sig = await sign(eoa, authHash); // returns {yParity,r,s}

// 2) Submit type-4 tx with authorization_list = [tuple + sig]
//    and calldata to EIP7702Proxy.setImplementation(newImpl, initCalldata, validator, sig2)
await sendTx({
  type: 4,
  from: eoa.address,
  authorization_list: [{ ...tuple, ...sig }],  // [chain_id, address, nonce, y_parity, r, s]
  to: tuple.delegate,
  data: encodeSetImplementation({
    newImplementation: "0x000100abaad02f1cfC8Bbe32bD5a564817339E72", // example impl
    initCalldata: initAccountCallData,
    validator: "0x79A33f950b90C7d07E66950daedf868BD0cDcF96",
    signature: await sign(eoa, hashInitParams),
    allowCrossChainReplay: false
  }),
  gas: estimateGasPrague(),
});

Why this pattern? It keeps your 4337 account logic intact while the proxy absorbs 7702‑specific safety (replay‑safe nonces, init atomicity, ERC‑1967 storage discipline). Reference implementation and audit trail exist. (github.com)

B. Sponsored “approve+swap” in one click using pure 7702 batching

User signs a 7702 authorization delegating to your “Batcher” contract.
Your relayer sends a type‑4 tx with the authorization and calls
```
batch([approve, swap, stake])
```
; the relayer pays L1 gas.
On success, auto‑revoke delegation (send new 7702 tx delegating to zero address) or set a short‑lived policy window in the batcher.
Caveat: because type‑4 forbids contract creation and blobs, keep batcher stateless and audited; don’t rely on per‑tx code deploys. (eips.ethereum.org)

C. Keep 4337 benefits after a 7702 upgrade

If you want sponsored gas, session keys, and plugins:

Delegate the EOA to a 4337‑compatible account (Simple7702Account or your own).
Keep using EntryPoint v0.8 at its canonical address for userOps; your EOA now “is” that account for validation/execution. (github.com)

Emerging best practices (what we’re advising customers)

Do: lock authorizations to specific chain_ids (1, 8453, 42161, …). Use chain_id = 0 only for intentionally multi‑chain operations with additional witness data. (ethereum.org)
Do: migrate to EntryPoint v0.8 where available to benefit from native 7702 handling and friendlier unused‑gas rules. Document your fallback on v0.7 networks. (github.com)
Do: pre‑compute and display the exact delegate bytecode hash to the user; treat it like a firmware hash. Maintain a registry of approved delegates. (eips.ethereum.org)
Don’t: surface raw 7702 signature popups from dapps. Wallets should own this UX per the spec’s risk model. (eips.ethereum.org)
Don’t: queue multiple pending type‑4 txs from the same delegated EOA; enforce a “one pending” rule. (eips.ethereum.org)
Optimize: revisit 4337 callData to offset EIP‑7623’s floor. Pack structs, use short revert strings, and prefer execution‑heavy flows over data‑heavy ones to stay at 4/16 per‑byte pricing. (eips.ethereum.org)

Risk ledger (with mitigations)

Front‑running initialization during first delegation
- Mitigation: 7702‑aware proxy that atomically sets implementation + validates state with a signature; external nonce tracker to defeat replay. (github.com)
Delegating to malicious code
- Mitigation: only allow delegation to code signed off by your security policy; present code hash + audited version; support one‑tap revoke. (eips.ethereum.org)
Mempool propagation edge cases
- Mitigation: relayer enforces single pending tx per delegated EOA and retries with backoff; wallet UI blocks concurrent high‑risk actions. (eips.ethereum.org)
Calldata floor inflating 4337 costs
- Mitigation: upgrade to EntryPoint v0.8 (smarter gas behavior), compress payloads, and split extremely data‑heavy tasks across bundles if needed. (github.com)

Interop notes you can use tomorrow

4337 addresses you likely need in code and dashboards:
- EntryPoint v0.8: 0x4337084d9e255ff0702461cf8895ce9e3b5ff108
- EntryPoint v0.7: 0x0000000071727De22E5E9d8BAf0edAc6f37da032
- EntryPoint v0.6: 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 (github.com)
L2 status: Arbitrum exposes native 7702 via ArbOS 40; many wallet SDKs already wire type‑4 support (verify per chain). (docs.arbitrum.io)
CREATE2 factory—multi‑chain deployment via 7702: teams are standardizing on deterministic CREATE2 factories deployed with 7702 at known addresses; plan for this if you do multi‑chain rollouts. (eips.ethereum.org)

KPIs to validate your migration

Time‑to‑first‑action for new users (EOA → delegated 7702 → first batch) under 30 seconds.
“Approve+swap” gas cut vs two legacy txs (measure per chain).
4337 bundle acceptance rate >99.5% across your top three chains; <0.5% ERC‑7562 violations per 10k userOps. (ercs.ethereum.org)
Delegation revocation rate <0.5% within 7 days (higher suggests UX confusion or scare prompts). (outposts.io)

Looking ahead: preparing for native AA (RIP‑7560)

RIP‑7560 explores a native AA transaction type for rollups and potentially L1, reusing 4337 semantics with protocol‑level validation and dedicated mempool rules (RIP‑7711). Your 7702 + 4337 architecture is the correct stepping stone—keep code paths modular so you can route validation to “native AA” where available without rewriting wallet logic. (docs.erc4337.io)

Implementation checklist (copy/paste into your tracker)

Platform
- Upgrade Solidity to 0.8.30; set evmVersion=“prague” in CI. (soliditylang.org)
- Update gas estimators for EIP‑7623 rules; add tests for data‑heavy transactions. (eips.ethereum.org)
- Deploy/verify EntryPoint v0.8 addresses in config; pin v0.7 where v0.8 not available. (github.com)
Wallet
- Add “Upgrade this address” flow (7702 authorization → delegate to audited proxy). (github.com)
- Block dapp‑initiated 7702 popups; only wallet‑initiated upgrades. (eips.ethereum.org)
- One‑tap revoke (delegate to zero address) + scheduled rotation reminders. (eips.ethereum.org)
Infra
- Bundler passes ERC‑7562 suites; shared mempool peers monitored. (ercs.ethereum.org)
- Relayer enforces 1‑pending‑tx rule for delegated EOAs. (eips.ethereum.org)
Security
- Maintain allowlist of delegate bytecode hashes; publish audit references in‑app. (eips.ethereum.org)
- External nonce tracker (if using 7702 proxy) to thwart replay; init atomicity checks. (github.com)

Bottom line

EIP‑7702 is not a replacement for 4337—it’s the unlock that lets you keep users’ existing addresses while adopting modern wallet UX.
The fastest route to value is 7702→4337 delegation via a hardened proxy, combined with EntryPoint v0.8 and ERC‑7562‑compliant bundling.
Pectra’s gas‑economics tweaks (7623/7691) reward payload discipline and L2 strategy; bake this into your planning now. (eips.ethereum.org)

If you want a migration review, 7Block Labs can audit your 7702 delegate code, stage your 0.8 roll‑out, and benchmark UX deltas against your current flows—before you touch production traffic.

References

Pectra meta‑EIP, activation schedule, included EIPs. (eips.ethereum.org)
EIP‑7702 spec (authorization tuples, delegation indicator, constraints, security notes). (eips.ethereum.org)
Ethereum.org 7702 explainer (type‑4 and tuple fields). (ethereum.org)
Solidity 0.8.30 “prague” default. (soliditylang.org)
ERC‑4337 EntryPoint v0.8 release and address. (github.com)
ERC‑4337 v0.7/v0.6 addresses and deprecation guidance. (alchemy.com)
ERC‑7562 validation rules; shared mempool. (ercs.ethereum.org)
EIP‑7623 calldata floor and EIP‑7691 blobs throughput increase. (eips.ethereum.org)
7702‑hardened proxy (reference impl/audits). (github.com)
L2 readiness (Arbitrum 7702 via ArbOS 40). (docs.arbitrum.io)
Deterministic CREATE2 factory via 7702. (eips.ethereum.org)