---
# System prepended metadata

title: 'Three AA‑Adjacent EIPs, Through a Wallet Engineer''s Lens'

---

# Three AA-Adjacent EIPs from a Wallet Engineer’s Perspective

EIP‑7702 has been live for more than a year. It is arguably the most consequential EOA upgrade Ethereum has ever shipped: the ability for any existing address to temporarily behave like a smart contract. And yet: most major wallets have not integrated it in a meaningful way. Most users don't know it exists.

The popular reading of this is "wallets don't ship complex tx types, so let's keep future proposals narrow." I think that reading is exactly wrong. 7702 is underadopted because it is a primitive, not a product. It gives wallets plumbing and asks them to invent the feature. The actual lesson is that the ecosystem needs transaction types that *solve user‑visible problems end‑to‑end*, and the only proposal on the table that does that comprehensively is EIP‑8141.

This article walks through 8141, 8202, and 8223 from a wallet engineer's seat, and argues that narrow proposals are a trap. If we're serious about account abstraction, we ship frames.

## The three proposals at a glance

| | **EIP‑8141** Frame Tx | **EIP‑8202** Scheme‑Agile Tx | **EIP‑8223** Contract Payer Tx |
|---|---|---|---|
| Tx type | `0x06` | `0x05` | `0x07` |
| Core idea | Recursive frames with abstract validation and payment | Pluggable signature scheme + typed extensions | Contract at `tx.to` pays gas via registry predeploy |
| Removes EOA floor? | Yes (VERIFY frames define validity) | No | No |
| Custom validation logic | Arbitrary EVM | Scheme‑pluggable only | None |
| Batching (protocol‑level) | Yes, per‑frame receipts | No | No |
| Gas sponsorship | Paymasters, ETH or ERC‑20 | None native | ETH‑only, single payer |
| Session keys, social recovery, spending limits | Yes | No | No |
| Addresses the full AA surface | Yes | No | No |

The last row is the one that matters, and I want to start there.

## What "account abstraction" actually means

Account abstraction is not a gas‑sponsorship feature. It is not a signature‑algorithm feature. It is the proposition that *the rules for whether a transaction is valid on an account should be definable by the account itself, as code*. Everything users actually ask wallet teams for (social recovery, session keys, spending limits, multisig as the root signer, arbitrary 2FA schemes, delegated automation, cold‑master‑plus‑hot‑signer patterns) is a consequence of that one idea.

Measured against that definition:

| Use case | 8141 | 8202 | 8223 |
|---|---|---|---|
| Custom signature algorithm | Yes (VERIFY defines it) | Yes (but only from a fixed registry) | No |
| Social recovery as root signer | Yes | No | No |
| Session keys with scoped permissions | Yes | No | No |
| Spending limits / velocity caps | Yes | No | No |
| Multisig as tx authorizer | Yes | No | No |
| Quantum‑safe signing | Yes (via scheme in VERIFY) | Yes (native) | No |
| Gas sponsorship (ETH) | Yes | No | Yes |
| Gas sponsorship (ERC‑20) | Yes | No | No |
| Key rotation without asset move | Yes | No | Yes |
| Atomic batching | Yes (native frames) | No | No |
| Counterfactual account deployment | Yes | No | No |
| Multi‑sender bundled txs | Yes | No | No |

8202 covers one cell. 8223 covers two cells. 8141 covers all of them. This is not a rhetorical trick. It's what "abstract" means. You cannot be kind‑of abstract; you either let code define validity or you don't.

## A word about 4337 before we go further
Before beating up on the narrow proposals, a reminder worth holding in the back of your head: with all its issues, ERC‑4337 is already live in production and already delivers almost every cell in the table above. Custom validation, session keys, social recovery, ETH and ERC‑20 gas sponsorship, batching, custom signature schemes, counterfactual accounts. All shipping. All audited. All with real user volume across major smart wallets.

That fact reframes the case against the narrow proposals. Introducing a "smaller version" of native account abstraction is actively counterproductive if 4337 is still more feature‑complete than the protocol‑native alternative. A user looking for ERC‑20 gas sponsorship is not going to migrate to 8202 or 8223 or 8224 or 8221 or 8130 or 8175. They will simply stay on 4337, where the feature already works end‑to‑end. 

The only thing that justifies a new native tx type for AA is completeness: giving wallets a protocol‑level primitive that is strictly superior to 4337 across the full feature surface, not just on one slice of it. 8141 is the only proposal on the table that crosses that bar. Everything narrower is, for most real users, a sidegrade or a downgrade from the status quo 4337 already provides. That is the bar the narrow proposals need to clear, and the one they do not.

## 8223 from the wallet desk: why the narrow case is a trap

8223 is seductive. It solves "I don't want to hold ETH", a concrete and visceral user pain, with a tiny engineering surface. One new tx type, a registry predeploy, O(1) mempool revalidation, VOPS‑compatible. I understand why it polls well with wallet teams. I used to think it was the proposal most likely to ship.

Here is why I changed my mind.

**8223 does not deliver account abstraction. It delivers gas sponsorship under a specific shape.** The user still signs with an ECDSA EOA. Validity is still "an EOA produced a valid ECDSA signature." The contract at `tx.to` is a gas‑paying escrow, not a validator. Every AA feature a user actually wants (session keys, social recovery, spending limits) still has to be built as Solidity scaffolding *inside* the payer contract, invoked through the hot EOA, and gated by the EOA's root signature. You have re‑implemented 4337's pattern without the EntryPoint and without the bundler, but you haven't moved the authorization floor.

**Shipping 8223 ossifies the EOA‑as‑signer pattern for another decade.** Once wallets build around "hot EOA signer + payer contract + 7702 delegation for extras," the industry's default mental model locks in. Every future AA feature has to be bolted onto that stack. The political cost of shipping 8141 rises: "we already solved sponsorship, why do we need frames?" Narrow proposals don't just fail to solve the real problem; they make the real problem harder to solve later.

**The mempool and address‑management constraints are specific.** Two addresses per user (contract + EOA), `tx.to` must have code (no sponsored sends to EOAs, no sponsored deployments), ETH‑only gas, one sponsored tx per sender in the mempool, hot‑key drainage risk. These aren't abstract concerns; they're tickets your support team opens in month two. And the fundamental objection still holds: after solving all of them, you still don't have AA. You have a slightly nicer EOA.

**Good at one thing is worse than adequate at everything.** 8223's key rotation story is genuinely clean. Its VOPS compatibility is genuinely valuable. But "we have a clean rotation story for one specific signer shape" is not a substitute for "users can define what authorization means."

**Migration path**

For a pure EOA user, 8223 adoption is not cheap. You need a deployed smart account contract (deployment gas, audit surface, one more thing to maintain), and then you have to move every asset out of the old EOA and into the contract: ERC‑20s, NFTs, staking positions, LP positions, vesting claims, streaming payments, ENS records, delegated voting weight. Some of these do not transfer cleanly. Vesting contracts may be bound to the original beneficiary address, governance stakes may be non‑transferable, protocol‑native positions may require unstake‑and‑restake. The migration window is a security hotspot and a support‑ticket generator.

There is no *hard* dependency on 7702, but 7702 is the only realistic way to avoid the address change for existing EOA users. With 7702 you delegate the user's current EOA to smart‑account code, keep every asset in place, spin up a fresh hot EOA, and have the delegated code call `PAYER_REGISTRY.authorize(hotEOA)`. Without 7702, every adopting EOA user gets a new primary address and a new round of "please update your payout destination" work across every integration they have.

For existing smart wallets (Safe, Argent, Ambire, Etherspot, Kernel), 8223 is almost free. The contract already exists, assets are already in it, the only new work is a method to call the registry and the wallet‑side UX for sponsored‑tx signing. This is the population where 8223 adoption will actually land fast.

The skepticism answer: pitch 8223 to existing smart‑wallet users first, where the migration cost is near zero and the "no ETH" benefit is immediate. Let the EOA‑side adoption ride on 7702's curve. For a wallet team that only ships an EOA product, 8223 is a heavy lift with a modest payoff; for a team that already ships a smart wallet, it is a weekend and a new feature tile. Roadmap accordingly.

## 8202 from the wallet desk: right answer, wrong question

8202 is the most elegant of the three. I admire the design. It's a minimal diff from EIP‑1559, it preserves legacy addresses for the secp256k1 case, it ships a genuinely clever ephemeral scheme for quantum safety using Merkle trees of BIP‑44 keys, and its validation is stateless.

It is also not an account abstraction proposal. It is a signature‑scheme upgrade proposal that happens to ship in the same era as AA conversations. The sender is still an EOA. Validity is still "did this key produce this signature." The set of valid signature schemes is a fixed registry controlled by protocol upgrades, not an open set definable by the account.

If quantum safety is your goal, 8202 is the cleanest vehicle. If AA is your goal, 8202 doesn't move the needle on any of the user‑facing features that actually matter: no batching, no sponsorship, no custom validity rules, no session keys, no social recovery. The 2²⁰ key limit, the 737‑byte witness, the wallet‑side nonce‑to‑key bookkeeping, the 5,000 gas surcharge. All of that engineering investment buys you one thing: PQ‑safe signing. That is worth doing. It is not worth doing *instead of* AA.

**Migration path**

Two paths, very different costs.

Scheme `0x00` (legacy secp256k1) is free: same address, same key, the wallet just emits a `0x05` envelope when it wants to. A user cannot tell the difference and neither can most integrations. This path has no friction and no benefit worth explaining to a user.

Scheme `0x01` (ephemeral) is the path that matters and it is expensive. The address is derived from the Merkle root of 2²⁰ BIP‑44 pubkeys, so every user adopting PQ safety gets a new primary address. That means a full asset sweep: tokens, NFTs, approvals (revoke‑and‑reapprove across every dApp), streaming payments, ENS, off‑chain integrations (exchanges, payroll, billing), social identity. There is no 7702 escape hatch here. 7702 delegation is rooted in the original EOA's ECDSA key, so keeping the old address means keeping the quantum‑vulnerable authorization surface, which defeats the entire point of migrating. Under 8202, PQ safety and address continuity are mutually exclusive.

The wallet also inherits permanent new state: store the seed securely, cache or regenerate 2²⁰ Merkle leaves, track the nonce‑to‑key index, produce 640‑byte proofs on every transaction. Recovery from seed phrase means rebuilding the tree before the user can sign; on a mobile device this is not instant. Every wallet team absorbs non‑trivial engineering and non‑trivial storage.

This is the proposal with the most unavoidable migration complexity of the three. The cost cannot be bypassed with 7702 or with any clever userspace trick, because the benefit is definitionally tied to moving off the secp256k1‑derived address. And the adoption pitch is the most abstract of the three: most users do not feel quantum pain in 2026, so wallet teams have little business reason to fund the migration. Realistic trajectory: adoption tracks the pace of actual cryptographic progress, not the pace of wallet roadmaps. Wallets that do ship it will ship it as an opt‑in "vault" mode for power users, not as the default.

## 8141 from the wallet desk: the case for shipping

8141 is the only proposal that treats AA as the protocol‑level problem it actually is. Frame transactions are recursive structures with three modes (DEFAULT, VERIFY, SENDER), new opcodes for frame introspection, and a protocol‑native paymaster model. The validation prefix concept formalizes what 4337 has been approximating in userspace for years.

**What wallets get**

Every AA feature in the second table above becomes expressible as Solidity in a VERIFY frame. Social recovery? A VERIFY frame that checks a multisig over guardians. Session keys? A VERIFY frame that validates a time‑bounded sub‑key against a registry in the account's storage. Spending limits? A VERIFY frame that reads a per‑period counter and rejects when exceeded. BLS‑aggregated signatures? A VERIFY frame. Passkey/WebAuthn? A VERIFY frame. These are not hypotheticals. They are each a weekend project once the primitive exists, and they are each a concrete user‑visible feature a wallet can ship and market.

Paymasters become first‑class and native. Gas sponsorship in ETH works, gas in ERC‑20 works, gas paid by a protocol for its users works. No bundler centralization. No alt‑mempool. The validation‑prefix rules keep DoS under control without delegating trust to a bundler operator.

Atomic batching with per‑frame receipts is the batching UX users have been asking for: "step 2 of your swap failed, steps 1 and 3 succeeded, here's what you owe." You can build that today by parsing logs, but you can't build it *cleanly*. 8141 makes it clean.

**What the 7702 data actually says about 8141**

The common argument against 8141 is "7702 is complex and underadopted, so 8141 will fare worse." Invert it. 7702 is underadopted because 7702 is a primitive without a product: "your EOA can run code" is infrastructure, not a feature. Wallet teams looked at it and correctly concluded that shipping the primitive didn't move their user metrics, because the features users want (batching, sponsorship, recovery) all required *additional* invention on top. Every wallet that wanted 7702‑based AA had to design its own version of a smart wallet contract, its own delegation targets, its own permission model.

8141 ships the product, not just the primitive. Paymasters are in the tx type. Batching is in the tx type. Validation abstraction is in the tx type. The wallet team's integration work is "support this tx type" rather than "support this tx type and also design the five follow‑on features that would make it useful."

The 7702 data is not evidence that complex tx types fail. It is evidence that *incomplete* tx types fail. 8223 is an incomplete tx type. 8202 is an incomplete tx type. 8141 is the one that finishes the job.

**Migration path**

For existing EOA users, 8141 has a quietly generous default. The EOA signs with its ECDSA key, the default VERIFY logic handles secp256k1 and P256, and the user can send frame transactions without deploying anything. Basic AA affordances (batching, canonical‑paymaster sponsorship, P256 passkey signing) are reachable immediately with zero asset migration. This is underappreciated in most 8141 write‑ups.

Full custom validity (session keys, social recovery, spending limits, BLS, anything that needs a real VERIFY frame beyond the defaults) requires a smart account contract. For a pure EOA user that means either deploy‑and‑migrate (painful, same cost as 8223) or 7702 delegation (smooth). Unlike 8202's ephemeral scheme, 7702 works as a genuine escape hatch here. You delegate the existing EOA to a VERIFY‑frame‑compatible account implementation, keep the address, keep the assets, unlock the full feature surface. 7702 is not a hard dependency for 8141, but it is the migration rail that makes 8141 viable for the installed base. Every EOA wallet that shipped 7702 support is already one delegation transaction away from protocol‑level AA.

For existing smart wallets (including every 4337‑based wallet), 8141 migration is a contract upgrade: express your current `validateUserOp` logic as a VERIFY frame, keep everything else. Assets do not move. Users stop routing through bundlers and start using the public mempool. This is a code migration rather than an asset migration, which is the cheap kind.

**Migration complexity at a glance**

| | Existing EOA user (no 7702) | Existing EOA user (with 7702) | Existing smart wallet user |
|---|---|---|---|
| 8223 | Deploy contract + full asset sweep + two‑address UX | Delegate EOA, spin up hot key, authorize. No asset move | Add `authorize` call + UX update. Nearly free |
| 8202 (`0x00`) | Zero migration. No benefit either | Zero migration. No benefit either | Swap signer envelope type. No benefit either |
| 8202 (`0x01` ephemeral) | Full asset sweep to new address. Permanent wallet state growth. **No 7702 escape** | Same. 7702 does not help here | Per‑signer asset move for each signer adopting PQ |
| 8141 basic (default VERIFY) | Zero migration. Immediate access to batching + canonical paymasters | Same, plus delegation unlocks richer features | N/A (already have smart wallet) |
| 8141 full (custom VERIFY) | Deploy new smart account + full asset sweep | Delegate EOA to frame‑aware code. No asset move | Upgrade contract to expose VERIFY frame handler |

The row that jumps out is 8202's ephemeral scheme: it is the only migration that is both expensive *and* un‑softenable by 7702. Every other migration path has a 7702‑shaped cheat code that keeps the user's address and assets intact. 8202's PQ path does not, by construction.

The skepticism answer for 8141: the reason a wallet team will fund this integration, when they did not fund 7702, is that 8141 pays off across the full feature list in a single migration. One contract upgrade (or one 7702 delegation target) unlocks session keys, social recovery, batching with per‑frame receipts, native paymasters, ERC‑20 gas, and custom validity rules. A skeptical wallet team can sanity‑check that list against their own support tickets: every item is something users have been asking for since 2021. The ROI of "one integration, six marketable features" is categorically different from "one integration, one abstract capability." That difference is what breaks the 7702 pattern instead of repeating it.

## Addressing the objections

**"8141 is VOPS‑hostile."** True by default, solvable by design. A mandatory validation access list (EIP‑2930 applied to VERIFY frames), pre‑execution witnesses for declared slots, and a registry‑predeploy pattern for the canonical paymaster case together reduce 8141's validation footprint to something a VOPS node can witness. The engineering work is real but bounded, and the direction aligns with where Verkle/stateless clients are heading anyway.

**"The implementation surface is enormous."** It is large. It is also the surface area of *every* AA feature combined. The alternative (ship 8223 for sponsorship, 8202 for PQ, a future EIP for batching, another for session keys, another for ERC‑20 gas) is a larger surface area integrated across more tx types with more edge cases between them. Concentrated complexity in one proposal is cheaper than distributed complexity across five.

**"Mempool rules are restrictive."** The non‑canonical paymaster cap (1 pending tx per payer) is a real constraint, but it is a rate limit, not a censorship vector. Wallets that hit the limit will do what high‑frequency users already do: route through builders. This is not new centralization; it is the same centralization that already exists for MEV‑sensitive flows. The canonical paymaster pattern, which covers the vast majority of consumer wallet cases, has no such limit.

**"Users won't understand it."** Users don't need to understand it. Users need to understand "I can recover my account if I lose my phone," "I don't need ETH," "I can set a daily spending limit," "my game can use session keys." These are UX surfaces the wallet builds on top of 8141. Users never saw 1559's fee market directly either.

**"Wallets won't ship it."** They won't ship it if it's delivered as a primitive. They will ship it if it's delivered as a complete AA solution, which is exactly what 8141 is designed to be. The counterexample is 4337: despite its centralization issues and userspace kludginess, it *did* see adoption, precisely because it was a complete solution. 8141 is 4337 done correctly at the protocol level.

## The composition trap

One more angle. Suppose we reject 8141 and ship 8202 + 8223 + 7702 instead. What does a wallet team actually have to build?

| Capability | How you deliver it in 8202/8223/7702 world |
|---|---|
| Custom signature algo | Wait for 8202 to add your scheme, or approximate via 7702 with EOA outer sig |
| Social recovery | 7702‑delegated wallet code + outer EOA sig (root of trust is still the EOA) |
| Session keys | 7702‑delegated wallet code + permission tables in storage + outer EOA sig |
| Gas sponsorship ETH | 8223 payer contract + registry authorization + hot EOA |
| Gas sponsorship ERC‑20 | Not achievable; wait for another EIP |
| Batching | 7702‑delegated batch executor + outer EOA sig over the whole batch |
| Key rotation | 8223 `authorize(newKey)`, genuinely clean |
| Quantum safety | 8202 ephemeral scheme, per signer key |
| Spending limits | 7702‑delegated wallet code + storage‑based counters + outer EOA sig |

Each row is its own integration. Each row has its own security edge cases. Each row leaks the EOA outer signature as the ultimate root of trust, so every feature is structurally a *suggestion* the smart contract code enforces, not a rule the protocol enforces. The wallet team that takes this on is signing up for a multi‑year program of building and maintaining what 8141 delivers in one tx type.

Under 8141:

| Capability | How you deliver it |
|---|---|
| All of the above | One VERIFY frame pattern per feature, one standard paymaster model, one tx type |

## The appeal

This is the part of the article where I stop writing as a wallet engineer and write as someone who cares about where Ethereum ends up in five years.

To the core developers making the call on which of these ships first: please choose 8141.

I know the instinct in the room is to ship what is cheapest to reason about. 8223 is small. 8202 is elegant. Both are easier to argue for in a meeting than a proposal with new opcodes, frame composition, paymaster modes, and a mempool story that will take real engineering to get right. I understand the gravity of that pull. Every protocol change lands on the shoulders of client teams who have already shipped too much this year, and "the simple one first" is a rational default.

But the simple ones do not get us to account abstraction. They get us to a better EOA, and a better EOA is not what the last decade of AA research was for. The whole point, from the earliest account abstraction sketches through ERC‑4337 through 7702, was to let users define what authorization means on their own accounts. 8223 moves the gas payer. 8202 moves the signing algorithm. Neither moves the authorization floor. Only 8141 does.

I also want to name the path‑dependence honestly. If 8223 ships first, the ecosystem will build around "EOA signer plus payer contract plus 7702 delegation" as the canonical wallet shape. Tooling will assume it. Indexers will assume it. Security audits will assume it. And when 8141 is proposed two years later, the response in the room will be: "we already solved this, why are we adding frame opcodes now?" The narrow win today becomes the political blocker tomorrow. This is not a hypothetical pattern; it is what happened to every ambitious AA proposal that lost the sequencing battle to a smaller one.

The objections to 8141 are real, and I do not want to wave them away. VOPS compatibility is a genuine engineering problem. The mempool rules for non‑canonical paymasters need refinement. The opcode surface is large, and every opcode added to the EVM is a decade‑long commitment. I am asking for this work to be done, not pretending it isn't work. What I am arguing is that the work is worth doing because the outcome is worth reaching, and because the alternative (a decade of incremental narrow proposals, each solving one cell in the AA matrix) is more total work spread across more actors with less coherent results.

There is also a version of this I am hopeful about. Pick 8141 as the north star. Let 8223's registry‑predeploy pattern live inside it as the canonical fast path for the common paymaster case: that design is too good to throw away, and it slots into a frame world cleanly. Let 8202's ephemeral scheme ship inside a VERIFY frame as the recommended PQ‑safe signer. The narrow proposals don't have to disappear; they can become the well‑lit paths *within* the full AA primitive, rather than substitutes for it. That is the version of this conversation where everybody wins and the ecosystem ends up with a coherent story.

And to the core dev reading this who is weighing the tradeoffs on a Tuesday morning: I know 8141 is the harder call. I know the cost lands on your team. I am asking anyway, because this is the decision that determines whether Ethereum's account model is actually abstract a decade from now, or whether we spend that decade building around a floor we should have removed when we had the chance. The narrow proposals will still be there to ship as optimizations. The window to ship a real AA primitive does not stay open forever. Please take it.