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

Description: Pectra has just launched EIP-7702 on mainnet, offering EOAs a straightforward way to enjoy smart-account features without letting go of ERC-4337. This playbook is designed for decision-makers, guiding you through safely rolling out 7702, making the most of existing 4337 infrastructure, and achieving noticeable user experience improvements in just weeks instead of dragging it out for quarters.

---

TL;DR for decision‑makers

• EIP‑7702 has officially launched on the mainnet as of May 7, 2025. This update introduces a new transaction type (type 0x04) that allows an externally owned account (EOA) to set a “delegation indicator” that points to some deployed contract code. Essentially, this means your EOA can function as a smart account at the same address until you decide to revoke it. This was rolled out as part of Pectra (Prague × Electra). (eips.ethereum.org)
• Instead of thinking about replacing 4337, let’s look at how we can work with it. The winning formula for 2025 is combining 7702 for keeping your address consistent with 4337 (EntryPoint v0.8) which offers sponsored gas, session keys, and modular security. EntryPoint v0.8 is cool because it includes native support for 7702 and also introduces a new canonical address. (github.com)
• Keep an eye on two protocol side effects in your budget: first up is calldata repricing (EIP‑7623), which gently encourages you to refine those UserOperation payloads. Then there's the increased blob capacity (EIP‑7691) that helps reduce Layer 2 data availability costs. Both of these enhancements came along with Pectra. (eips.ethereum.org)

---

What actually changed with Pectra (wallet‑relevant only)

• Activation: Pectra got its start on the Ethereum mainnet during epoch 364032 on May 7, 2025, at 10:05:11 UTC. Check out the details here.
• EIP‑7702 (Set EOA account code):
  • There’s a new transaction type (0x04) that comes with a list of authorizations formatted as tuples: [chain_id, address, nonce, y_parity, r, s].
  • Each of these tuples is signed by the EOA, and clients will record a delegation indicator in the EOA’s code (0xef0100 || address).
  • Once delegated, this setup sticks around until you change it, but you can reset it by delegating to the null address.
  • Just a heads up: Type‑4 transactions are designed not to include blob data and won’t create contracts, keeping the focus on enhancing user experience. Dive into more details here.
• EIP‑7623 (Increase calldata cost): Heavy data transactions will now have a base cost (10/40 gas for zero/non-zero bytes), which helps stabilize block size fluctuations. If you're dealing with 4337 payloads that have a lot of calldata, make sure to re-audit them. You can read more about it here.
• EIP‑7691 (More blobs): The limit for target/max blobs per block has been increased to 6/9, which boosts Layer 2 data availability and helps manage fees. This change is partnered with EIP‑7623 to keep bandwidth in check. Check out the full scoop here.
• Tooling ripple: On May 7, 2025, Solidity 0.8.30 switched its default EVM target to “prague.” Be sure to upgrade your CI tools before rolling out any code related to 7702. For more info, head over to Solidity's blog.

---

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

• Transaction type: 4 (0x04). This payload packs in an authorization_list that contains one or more tuples. Each tuple is like a green light for an EOA (Externally Owned Account) to let contract code at a specified address on a certain chain_id and EOA nonce do its thing. It's all wrapped up with a signature from the EOA, using (y_parity, r, s over a defined hash). (ethereum.org)
• State effect: When this goes down, clients will write a "delegation indicator" into the EOA's code. This means that when a CALL happens, it will redirect to the delegate's bytecode. And no worries if things need to change later--the EOA can update or even wipe that pointer (just delegate to address(0)). (eips.ethereum.org)
• Scope constraints:
  • No contract creation allowed, and no blobs in type‑4.
  • A little tip about transaction propagation: clients should steer clear of accepting more than one pending transaction from an EOA that's got a non‑zero delegation indicator to keep static‑validity issues at bay. (eips.ethereum.org)
• Security posture expected by protocol authors: To keep things safe, dapps should avoid asking users to sign raw 7702 authorizations. Wallets need to step up by gating and auditing the delegated code, plus they should implement standardized module systems on top for good measure. (eips.ethereum.org)

What this means for you is pretty straightforward: think of 7702 authorizations like “account firmware updates.” It's best to let only your wallet app (or your enterprise policy engine) handle the generation and presentation of these updates. Make sure that these are done after running thorough checks like deterministic checksums and audits of the delegate bytecode.

---

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

• EntryPoint v0.8 has officially dropped, bringing with it some cool new features like native support for 7702 authorizations, ERC‑712 userOp hashing, and a relaxed unused-gas penalty (now under 40k ignored). Plus, it comes with a fresh official address, different from the one in v0.7. If you’re still working with 0.6 or 0.7, you might want to start planning for a staged upgrade. Check it out here.
• Here are some common addresses:
  • EntryPoint v0.7: 0x0000000071727De22E5E9d8BAf0edAc6f37da032 (this one's a multi-chain singleton)
  • EntryPoint v0.6: 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789
    Keep in mind that providers are phasing out 0.6 throughout 2026, so it's a good idea to align your roadmaps now. More info here.
• The shared mempool and ERC‑7562 validation rules are pretty much the backbone for smooth bundling operations. Make sure your bundler stays compliant to avoid any reputation issues down the line. Learn more here.
• On the ecosystem front, it's great to see that leading bundlers, like Skandha, have jumped on board with EntryPoint v0.8 and are supporting 7702-aware flows across the main EVM chains. Check out the details here.

---

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

We suggest a simple 3-phase plan that keeps production on track while highlighting some quick wins for the user experience.

Phase 0 -- Baseline upgrades (1-2 sprints)

• Time to upgrade your toolchain: Switch to Solidity 0.8.30 (EVM “prague”). Make sure to test all your deployments in forks set up with the Pectra gas rules. Also, double-check that your gas estimators are taking the 7623 calldata floor into account. (soliditylang.org)
• Let's enhance the AA infrastructure:
  • Update to EntryPoint v0.8 on the networks you support. If that’s not possible, stick with v0.7 but make sure to document the differences for QA purposes.
  • Ensure your bundler is compliant with ERC‑7562.
  • Refresh the allowlists for EntryPoint addresses in both on-chain registries and off-chain risk engines. (github.com)
• Quick L2 check: If you depend on sponsored flows on rollups, remember that 7702 support has already rolled out on major L2s (like Arbitrum through ArbOS 40). Validate your chain-id-scoped authorizations in staging. (docs.arbitrum.io)

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

Sure! Here’s a breakdown of patterns you can adopt for each product line:

1. 7702-as-gateway (most teams)

• Delegation target: A 4337-compatible smart account setup (think your current account logic) running behind a streamlined proxy tailored for 7702.
• Benefit: Users can hang on to their EOA address while enjoying 4337 perks like sponsored gas, session keys, and plugins.
• Known-good patterns: Check out EIP7702Proxy, which is an ERC-1967 proxy beefed up for 7702 initialization, offers replay-safe externally tracked nonce, and supports UUPS upgrades. (github.com)

2) Pure‑7702 Batching (Specific Flows)

• If you've got apps that really focus on atomic multi‑calls (like approve + swap + stake) or you occasionally need a sponsor-gas UX, consider using a lightweight “batcher” contract for delegation.
• Make sure there's an easy one-click option to revoke (just delegate to a zero address).
• Just a heads up: you’ll miss out on those 4337-style modules/guardians unless you explicitly put them together. (eips.ethereum.org)

3) Hybrid per-segment

• For the consumer app, it’s all about pure 7702 batching, while on the enterprise treasury side, we're looking at a 7702→4337 modular account setup.
• We’re implementing policy engines to prevent any chain_id = 0 authorizations (multi-chain) from slipping through in non-enterprise contexts. (ethereum.org)

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

• UX Hard-Stops: Always make sure that random dapps can't trigger a 7702 authorization. You should only display upgrade prompts that come from your wallet's settings or trusted in-app processes. Before you hit that sign button, show users the code hashes, semantic diffs, and audit links. This totally lines up with what the EIP recommends. (eips.ethereum.org)
• Replay & Scope Controls:
  • Try to tie authorizations to the chain_id whenever you can, and keep chain_id = 0 for those special multi-chain operations.
  • Make sure to enforce the EOA nonce binding for each tuple (that’s in the spec) and keep an external nonce tracker handy within the 7702 proxy flows to avoid any reuse issues. (eips.ethereum.org)
• Pending-Tx Policy: Your relayer should only handle one pending tx at a time for delegated EOAs--this matches what the clients are saying. Don’t let extra requests pile up until the current ones are mined. (eips.ethereum.org)
• Revocation & Rotation: Consider adding a quick one-tap delegation reset (to a null address) in your wallet’s security center and set up reminders for scheduled "rotation." Some wallets already have a good user experience for 7702 delegation revocation--use those as a benchmark for usability. (outposts.io)
• Metrics We Track for Customers:
  • The share of Type-4 (7702) tx, success rate for first-time delegation, and time to first sponsored action.
  • The acceptance rate for 4337 bundles and any 7562 rule violations by entity.
  • Gas differences for each canonical task (like “approve+swap”) compared to the old 2-tx flows across each chain.

---

A. Minimal 7702 authorization + upgrade to your 4337 account

Concept: Delegate an EOA to an Audited 7702-Hardened Proxy

Alright, let’s break this down. The idea here is to set up a mechanism where you can delegate an Externally Owned Account (EOA) to a smart contract that’s been put through the wringer--specifically, an audited 7702-hardened proxy. This proxy will link directly to your existing 4337 implementation.

Here's How It Works:

1. What’s an EOA?
   • An EOA is a basic account on the blockchain that you control with a private key. It’s like your wallet.
2. Audited 7702-Hardened Proxy:
   • This is a contract that has undergone rigorous audits, ensuring it meets the security standards outlined in the 7702 specification. Think of it as a super secure middleman.
3. Linking to 4337 Implementation:
   • The 4337 standard allows you to have some cool features like account abstraction. By pointing your hardened proxy to your current implementation, you can leverage those features while maintaining security.

Why This Matters:

• Security First: By using a hardened proxy, you're adding an extra layer of protection to your transactions.
• Seamless Integration: Your existing setup remains functional, and you get the benefits of the new standards without a complete overhaul.
• Future-Proofing: This approach positions you well for ongoing developments in the blockchain space.

Conclusion:

So, to sum it up, delegating your EOA to an audited 7702-hardened proxy that points to your current 4337 setup is a savvy way to bolster your security while keeping everything flowing smoothly. It’s like upgrading your security system without having to rebuild your whole house!

// 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?

This approach helps maintain the integrity of your 4337 account logic while allowing the proxy to handle all the 7702-specific safety features, like replay-safe nonces, initialization atomicity, and following the ERC-1967 storage discipline. Plus, you can find the reference implementation and audit trail here: github.com.

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

• The user kicks things off by signing a 7702 authorization that delegates to your “Batcher” contract.
• Next, your relayer jumps in and sends out a type-4 transaction that includes the authorization and calls batch([approve, swap, stake]); oh, and the relayer covers the L1 gas fees.
• If everything goes smoothly, you can either auto-revoke the delegation (by sending a new 7702 transaction that delegates to a zero address) or set a short-lived policy window in the batcher.
• Just a heads up: since type-4 doesn’t allow for contract creation or blobs, make sure your batcher stays stateless and is properly audited; it’s best not to count on per-transaction code deployments. (eips.ethereum.org)

C. Keep 4337 benefits after a 7702 upgrade

If you're on the hunt for sponsored gas, session keys, and plugins, here’s what you need to know:

• Assign the EOA to a 4337-compatible account, like a Simple7702Account or one that you create yourself.
• Stick with EntryPoint v0.8 at its standard address for userOps; now, your EOA basically acts as that account for validation and execution. (github.com)

---

Emerging best practices (what we’re advising customers)

• Do: Lock authorizations to specific chain_ids like 1, 8453, 42161, and so on. Only use chain_id = 0 for those times you really need to perform multi-chain operations with extra witness data. Check it out on ethereum.org.
• Do: Migrate to EntryPoint v0.8 where it’s available. You'll get the perks of native 7702 handling along with easier unused-gas rules. Don’t forget to document how you plan to handle things on v0.7 networks. More info on this can be found on github.com.
• Do: Pre-compute the exact delegate bytecode hash and show that to users; it’s a bit like a firmware hash. And hey, keep a registry of approved delegates. You can find details at eips.ethereum.org.
• Don’t: Pop up raw 7702 signature requests from dapps. The wallets should really handle this user experience according to the spec’s risk model. For more guidance, check eips.ethereum.org.
• Don’t: Allow multiple pending type-4 transactions from the same delegated EOA; stick to a “one pending” rule. You can find more about this on eips.ethereum.org.
• Optimize: Take another look at 4337 callData to balance out EIP-7623’s floor. Try to pack structs, use short revert strings, and lean towards execution-heavy flows instead of data-heavy ones to keep costs at 4/16 per byte. Check out the specifics on eips.ethereum.org.

---

Risk ledger (with mitigations)

• Front‑running initialization during first delegation
  • Mitigation: Use a 7702-aware proxy that sets the implementation and validates the state with a signature all in one go. Plus, keep track of external nonces to avoid replay issues. Check it out here.
• Delegating to malicious code
  • Mitigation: Make sure you’re only delegating to code that’s been approved by your security policy. You’ll need to present the code hash and an audited version. Don't forget to support one-tap revokes, just in case! More info here.
• Mempool propagation edge cases
  • Mitigation: Your relayer should enforce a single pending transaction per delegated EOA and retry with a backoff. Also, ensure the wallet's UI blocks any risky concurrent actions. You can dive deeper into this here.
• Calldata floor inflating 4337 costs
  • Mitigation: Upgrade to EntryPoint v0.8 for better gas behavior, compress your payloads, and if necessary, break down those data-heavy tasks across bundles. For more details, check out this link here.

---

Interop notes you can use tomorrow

• Here are 4337 addresses you might find handy for your code and dashboards:
  • EntryPoint v0.8: 0x4337084d9e255ff0702461cf8895ce9e3b5ff108
  • EntryPoint v0.7: 0x0000000071727De22E5E9d8BAf0edAc6f37da032
  • EntryPoint v0.6: 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 (check it out on GitHub)
• L2 Status: Arbitrum is showing off its native 7702 through ArbOS 40; a bunch of wallet SDKs are already set up with type‑4 support (just double-check per chain). (get the details here)
• CREATE2 Factory--multi‑chain deployment with 7702: Teams are getting on the same page with deterministic CREATE2 factories set up at known addresses using 7702. Keep this in mind for your multi‑chain rollouts! (more info here)

---

KPIs to validate your migration

• New users are getting started in under 30 seconds from EOA to delegated 7702 to their first batch.
• We're seeing a nice cut in gas fees with "Approve+swap" compared to the two legacy transactions (we're measuring this on a per-chain basis).
• The acceptance rate for 4337 bundles is over 99.5% across your top three chains, with less than 0.5% of userOps triggering ERC-7562 violations per 10k. (ercs.ethereum.org)
• The revocation rate for delegation is sitting at under 0.5% within the first week, which is great - if this number starts creeping up, it might point to some user experience confusion or those pesky scare prompts. (outposts.io)

---

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

RIP‑7560 dives into a native AA transaction type tailored for rollups and maybe even L1. It makes use of 4337 semantics, bringing in protocol-level validation alongside specialized mempool rules (thanks to RIP‑7711). The combination of 7702 and 4337 is definitely the right way to go. Just remember to keep those code paths modular! This way, you can direct validation to "native AA" whenever it's available, all without having to rewrite your wallet logic. Check out more details here.

---

Implementation checklist (copy/paste into your tracker)

• Platform
  • Let’s upgrade Solidity to 0.8.30 and set evmVersion="prague" in CI. (soliditylang.org)
  • We should update the gas estimators according to EIP‑7623 rules and add some tests for data-heavy transactions. (eips.ethereum.org)
  • Don’t forget to deploy and verify the EntryPoint v0.8 addresses in the config; let’s pin v0.7 where v0.8 isn't available. (github.com)
• Wallet
  • Time to add an “Upgrade this address” flow (you know, 7702 authorization → delegate to the audited proxy). (github.com)
  • We need to block any dapp-initiated 7702 popups; upgrades should only come from the wallet. (eips.ethereum.org)
  • Let’s implement one-tap revoke (delegate to the zero address) and set up reminders for scheduled rotations. (eips.ethereum.org)
• Infra
  • The bundler should pass the ERC‑7562 suites, and we’ll keep an eye on shared mempool peers. (ercs.ethereum.org)
  • Make sure the relayer is enforcing the 1-pending-tx rule for delegated EOAs. (eips.ethereum.org)
• Security
  • We need to maintain a list of allowed delegate bytecode hashes and publish audit references in the app. (eips.ethereum.org)
  • Let’s track external nonce (if we’re using the 7702 proxy) to prevent replay attacks and initialize atomicity checks. (github.com)

---

Bottom line

• So, EIP‑7702 isn’t just a new version of 4337; think of it as the key that lets you keep your users' current addresses while stepping up to a more modern wallet user experience.
• If you want to hit the ground running, the best strategy is to go with 7702→4337 delegation using a hardened proxy, paired with EntryPoint v0.8 and ERC‑7562-compliant bundling.
• Don't forget to factor in Pectra’s gas-economic adjustments (7623/7691), which encourage smart payload strategies and L2 planning; it’s a good idea to weave this into your roadmap now. (eips.ethereum.org)

If you’re looking for a migration review, 7Block Labs has got you covered! They can take a good look at your 7702 delegate code, help you stage that 0.8 roll-out, and even benchmark user experience differences against what you’re currently running--all before you dive into production traffic.

---

References

• Check out the Pectra meta‑EIP, which has the activation schedule and included EIPs. You can find it here.
• Want to dive into the EIP‑7702 spec? It covers authorization tuples, the delegation indicator, constraints, and some important security notes. Get all the details here.
• For a clearer understanding of EIP-7702, Ethereum.org has a great explainer that breaks down type‑4 and tuple fields. Check it out here.
• Don't forget about Solidity 0.8.30 “prague” as the default! You can read more about it here.
• The ERC‑4337 EntryPoint v0.8 has been released, and you can find the address here.
• If you’re still using ERC‑4337 v0.7 or v0.6, make sure to check out the addresses and the deprecation guidance here.
• For validation rules and shared mempool related to ERC‑7562, here's the link you need: click here.
• You can find details on the calldata floor for EIP‑7623 and the throughput increase from EIP‑7691 here.
• If you're looking for the 7702‑hardened proxy, including reference implementations and audits, check it out here.
• Curious about L2 readiness? Learn about Arbitrum 7702 via ArbOS 40 here.
• And don't miss the deterministic CREATE2 factory via 7702. Details are available here.