Competing Standards
TL;DR
Five general-purpose proposals sit between maximum generality (EIP-8141: arbitrary EVM in VERIFY frames) and maximum constraint (Tempo-like: fixed UX primitives). EIP-8141 and the Coinbase/Base pair EIP-8130 + EIP-8430 are the most active. In October that alternative was split into sibling standards: EIP-8430, a fixed-cost secp256k1 transaction type Base plans to ship, and EIP-8130, a Keystore that plugs into it and also names EIP-8141 frame accounts as a consumer. EIP-8130 + EIP-8430 wins on mempool simplicity; EIP-8141 wins on expressiveness, EOA defaults, and L1 status (SFI for Hegotá). Static sponsorship, shielded gas funding, and PQ-safe address derivation are complementary.
Competing vs Complementary
"Competing" is not a single relationship. The proposals on this page fall into two groups:
- Competing general-purpose proposals (EIP-8175, EIP-8130 + EIP-8430, EIP-8202, Tempo-like): these overlap with EIP-8141's scope and trade generality vs. constraint. A chain typically adopts one as its primary AA type.
- Complementary proposals (EIP-8223, EIP-8224, EIP-8215/HCA): these compose with any format. They cover static sponsorship, shielded gas funding, and PQ-safe address derivation.
EIP-8130 and EIP-8430 are sibling standards and are compared as one design throughout. Where it matters, tables note what EIP-8430 delivers without the Keystore (secp256k1 only).
Comparative Analysis
The Fundamental Tradeoff: Generality vs. Deployability
The five general-purpose proposals sit on a spectrum (alternatives, you choose one):
More General More Constrained
| |
EIP-8141 EIP-8175 EIP-8130 + EIP-8202 EIP-XXXX
(arbitrary (flat caps, EIP-8430 (flat extensions, (fixed UX
EVM in programmable (Keystore + scheme-agile auth, primitives,
VERIFY fee_auth) fixed-cost single execution) passkeys)
frames) tx type)Complementary proposals sit off the spectrum (narrower scope, compose with any of the above):
Static Sponsorship Shielded Gas Funding
────────────────── ────────────────────
EIP-8223 EIP-8224
(canonical payer registry (fflonk ZK proof against
at 0x13, one SLOAD canonical fee-note
+ balance check, contracts, ~222K gas,
no EVM in validation) bootstrap problem)EIP-8215/HCA addresses PQ-safe address derivation for new accounts.
EIP-8141 gives maximum flexibility: any account code can define any validation logic, multiple execution frames per transaction, atomic batching. The cost is mempool complexity (banned opcodes, gas caps, validation prefixes) and async execution incompatibility.
EIP-8175 provides flat capability composition with programmable gas sponsorship via fee_auth, but limits sender validation to fixed signature schemes. It started as "simpler than 8141" but evolved to include 4 new opcodes and EVM execution in the fee_auth prelude.
EIP-8130 + EIP-8430 makes validation programmable but operationally predictable. The EIP-8430 transaction type gives today's EOAs batching, sponsorship, 2D nonces, and in-band delegation with fixed-cost secp256k1 validation; the EIP-8130 Keystore adds actors whose authenticators implement a pure authenticate(hash, data) -> actorId interface, with a canonical set that gives nodes known costs. The Keystore is transport-neutral, and EIP-8397 gives EIP-8141 frames an ABI-identical AUTHENTICATOR scheme, so the pair's authority layer can also serve frame accounts.
EIP-8202 takes a different angle entirely; it doesn't try to be an AA system. Instead, it solves signature agility and feature composition at the transaction envelope level. One execution payload, flat typed extensions, no new opcodes. The cost is no batching, no programmable validation, and no gas sponsorship (yet).
EIP-XXXX (Tempo-like) takes the most constrained approach, bundling the specific UX features wallets need today (batching, sponsorship, passkeys, validity windows, 2D nonces) into a single tx type with no new opcodes and no programmable validation. The cost is a fixed feature set that requires hard forks to extend, and no PQ strategy.
ECDSA Decoupling
| Proposal | Approach | Programmable Validation |
|---|---|---|
| EIP-8141 | Arbitrary EVM in VERIFY frames. Account code defines its own sig scheme. No ECDSA dependency in the tx format. | Yes: any logic via account code + APPROVE |
| EIP-8175 | Fixed signature scheme set (secp256k1, Ed25519). New schemes require hard fork. | No: sender auth is cryptographic only |
| EIP-8130 + EIP-8430 | Keystore authenticator contracts, PQ-ready once a PQ authenticator is canonical; the EIP-8430 type alone is secp256k1 only | Yes, within authenticate(hash, data) -> actorId plus actor policy gates |
| EIP-8202 | Typed scheme_id in authorization (secp256k1, P256, Falcon-512). New schemes added per EIP. | No: fixed cryptographic check per scheme |
| EIP-XXXX | Fixed set: secp256k1, P-256, WebAuthn. New schemes require hard fork. | No |
| EIP-8223 | secp256k1 sender only. Not a decoupling proposal. | No |
| EIP-8224 | fflonk ZK proof verification. Not a decoupling proposal. | No |
EIP-8141 is PQ-ready through account code, ARBITRARY witnesses, EIP-8397 authenticators, and EIP-8288 aggregation. EIP-8130 + EIP-8430 is PQ-ready once a PQ authenticator is canonical in the Keystore. Key rotation: the EIP-8130 Keystore has native, cross-chain actor changes; EIP-8141 leaves it to account code, with ERC-8403 proposing a shared authority lifecycle. EIP-8223 rotates via authorize(newEOA).
Gas Sponsorship
| Proposal | Sponsorship Model | Canonical Paymaster |
|---|---|---|
| EIP-8141 | VERIFY frame authorizes payer. Canonical paymaster recognized by runtime code match. Non-canonical contract paymasters are limited to 1 pending tx; codeless EOA sponsors use balance-bounded aggregate exposure instead. | Yes: protocol-blessed, mempool-validated |
| EIP-8175 | Programmable fee_auth contract with RETURNETH escrow. Sponsor state persists even if main tx reverts. | No: fee_auth is per-sponsor |
| EIP-8130 + EIP-8430 | payer + payer_auth: self-pay, open (0x00), or named sponsor, authenticated through the Keystore when integrated | No |
| EIP-8202 | ROLE_PAYER reserved but not yet defined. No sponsorship today. | No |
| EIP-XXXX | fee_payer_signature field (secp256k1 only). Fee payer pays all gas. | No: direct co-signing |
| EIP-8223 | Canonical payer registry at 0x13. Static validation (1 SLOAD + balance check). tx.to pays gas. | Yes: predeploy registry |
| EIP-8224 | Shielded gas funding via ZK proofs. One-shot bootstrap, then transition to EIP-8223. | No: fee-note contract |
Transaction Batching
| Proposal | Batching Model | Atomicity Control |
|---|---|---|
| EIP-8141 | Multiple frames per tx. SENDER frames execute sequentially with isolated execution/state budgets. | Flags field bit 2 on consecutive DEFAULT/SENDER frames; VERIFY and approval scope cannot participate (#11955/#11987/#12109) |
| EIP-8175 | Typed capabilities list (CALL, CREATE). Sequential execution. | All-or-nothing: if any capability reverts, remaining are skipped |
| EIP-8130 + EIP-8430 | Call phases (array of arrays). Completed phases persist if later phases revert. | Per-phase atomicity: calls within a phase are atomic |
| EIP-8202 | Single execution payload. No native batching. | N/A: one call per tx (multicall wrappers needed) |
| EIP-XXXX | calls list of [to, value, input] tuples. | All-or-nothing: entire tx reverts on any call failure |
| EIP-8223 | Not addressed. Single call per tx. | N/A |
| EIP-8224 | Not addressed. Single call per tx. | N/A |
Developer Tooling
| Proposal | Wallet Integration Cost | Infrastructure Required |
|---|---|---|
| EIP-8141 | Implement new tx type. Default code covers EOAs with no smart account needed. | No bundlers, no relayers. Public mempool. |
| EIP-8175 | Implement new tx type. Compose capabilities + signatures. | No bundlers. fee_auth contracts for sponsorship. |
| EIP-8130 + EIP-8430 | Implement new tx type; register Keystore actors for non-secp256k1 keys. | Keystore contract, Nonce Manager and Tx Context precompiles, canonical authenticators. |
| EIP-8202 | Implement new tx type. Existing secp256k1 EOAs keep their address. | Minimal: no new contracts. |
| EIP-XXXX | Implement new tx type. P-256/WebAuthn create new addresses. | Minimal: no new contracts. |
| EIP-8223 | Implement new tx type. Payer calls authorize(sender) on registry. | Payer registry predeploy only. |
| EIP-8224 | Implement new tx type. User deposits into fee-note contract, generates ZK proof. | Fee-note contracts + proof generation tooling. |
On EVM changes: EIP-8141 requires 7 new opcodes and a frame execution model; EIP-8175 requires 4. EIP-8130 + EIP-8430 and the rest require none. EIP-8141's advantage is that default code gives EOAs AA features without deployment or registration, and ERC-7902 now exposes the frame family to apps through one EIP-5792 capability set.
Mempool Strategy
| Proposal | Validation Cost | Mempool Complexity |
|---|---|---|
| EIP-8141 | EVM execution capped at 100k execution gas plus 500k declared state gas; protocol-defined prefixes may be evaluated directly | High for custom validation: validation prefix shapes, banned dependencies, canonical paymaster |
| EIP-8175 | Crypto sig verification + fee_auth EVM prelude | Medium: stateless sigs, but fee_auth simulation needed |
| EIP-8130 + EIP-8430 | ecrecover, or one Keystore SLOAD plus authenticator STATICCALL (or native impl) | Medium: canonical authenticator set, account lock optimization |
| EIP-8202 | ecrecover / P256VERIFY / Falcon-512 verify (deterministic) | Low: purely cryptographic, no EVM |
| EIP-XXXX | ecrecover / P-256 / WebAuthn (bounded) | Low: deterministic crypto, bounded sig sizes |
| EIP-8223 | ecrecover + 1 SLOAD at 0x13 + balance check | Minimal: static reads only, no EVM |
| EIP-8224 | fflonk proof verify (~176K gas) + EXTCODEHASH check + fixed storage reads | Minimal: bounded crypto + static reads, no EVM |
On tracing: EIP-8141 requires EVM tracing for custom validation, bounded by the restrictive tier and skippable for protocol-defined prefixes. EIP-8175 traces fee_auth. EIP-8130 + EIP-8430 avoids tracing for canonical authenticators.
Other Capabilities
| Proposal | EOA Support | Account Creation | Async Execution | Cross-Chain |
|---|---|---|---|---|
| EIP-8141 | Protocol-native default code (ECDSA secp256k1; canonical low-s P256 outer signatures require account code, #11984) | DEFAULT deploy frame through any trace-compatible factory | Incompatible | Full blob support through EIP-7594 (#11985) |
| EIP-8175 | secp256k1 native; Ed25519 creates new addresses | Not addressed | Partially (fee_auth needs EVM) | Not addressed |
| EIP-8130 + EIP-8430 | Native secp256k1; no auto-delegation after the split | CREATE2 via account_changes | Compatible | Yes: Keystore chain_id = 0 replays |
| EIP-8202 | secp256k1 EOAs keep address; P256/Falcon create new | Not addressed | Compatible | Not addressed |
| EIP-XXXX | secp256k1 native; P-256/WebAuthn create new addresses | Not addressed | Compatible | Not addressed |
| EIP-8223 | EOA delegates via 7702, then authorizes sponsor | Not addressed | Compatible | Not addressed |
| EIP-8224 | Fresh EOA bootstrapping via ZK proof | Not addressed | Compatible | Cross-chain via chain_id binding |
Individual Proposals
Each proposal is covered in detail on its own page:
- EIP-8175: Composable Transaction
- EIP-8130 + EIP-8430: Keystore Accounts and AA Transaction Type
- EIP-8202: Scheme-Agile Transactions
- EIP-XXXX: Tempo-like Transactions
- EIP-8223: Contract Payer Transaction
- EIP-8224: Counterfactual Transaction
- EIP-8215: Hash-Committed Account (related PQ address derivation)
Cross-Proposal Commentary
What EIP-8175's Ecosystem Says About EIP-8141
In the Frame Transactions vs. SchemedTransactions comparison thread, Giulio2002 (post #1) argues that frame transactions impose a "smart wallet tax" of ~30,000-48,000 gas for contract dispatch, storage reads, and EVM context, making PQ verification via VERIFY frames (~63,000 gas) roughly 2x more expensive than direct SchemedTransaction verification (~29,500 gas for Falcon). The deeper argument: every real signature scheme ends up needing a precompile anyway, so frames become "an unnecessary indirection."
EIP-8141 defenders counter that the gas figure conflates ERC-4337 EntryPoint overhead with frame overhead (ch4r10t33r, post #17); that existing EOAs cannot use new crypto schemes under SchemedTransactions without changing addresses, which matt (post #15) flagged as an adoption blocker; and that hybrid classical+PQ signing is trivial in VERIFY frames but impossible in flat schemes. EIP-8175 and EIP-8202 share overlapping authors and advocate a consistent "flat composition" position against EIP-8141.
What the EIP-8130 + EIP-8430 Author Says About EIP-8141
From the Biconomy blog analysis:
"Base's position: 'We can heavily optimize this and build out performant mempool/block builder implementations,' something they can't do with EIP-8141's arbitrary validation frames."
That position held through summer: Base argued at ACDE #243 (Aug 13) that EIP-8141 is a breaking account change. At Frame Transaction Breakout #2 (Aug 25), client teams said L1 should ship primitives rather than enshrine an account model, and chunter conceded 8130 cannot approve payment after execution. After EIP-8141 went SFI (Aug 27), the convergence attempt ended in a sibling split: chunter moved the transaction type to EIP-8430 so it "can ship first", and scoped EIP-8130 to a Keystore usable "through ERC-4337, direct contract calls, or other native transports such as frame transactions". ETHLabs presented an 8130 account standard built on frames (Sep 22), and EIP-8397 gives frames an authenticator scheme ABI-identical to the Keystore's. Base lists EIP-8430 for its Everest upgrade with the Keystore to follow, and Coinbase's ERC-8168 payer service builds both EIP-8130 + EIP-8430 and EIP-8141 transactions.
EIP-8141 supporters argue authenticators are a subset of what VERIFY frames can do but not vice versa, and that default code gives EOAs AA without registration. The remaining tension is at the format level: two transaction types and two nonce managers on chains that adopt both, unless EIP-8430 shares EIP-8250's manager as proposed in its thread.
What EIP-8202's Authors Say About EIP-8141
From the spec's motivation and security considerations:
"This EIP is intentionally not a frame transaction system. [...] It intentionally forbids recursive transaction composition. That avoids drifting into frame-transaction validation complexity, where mempool validation may require richer execution-aware processing before inclusion."
EIP-8202 also explicitly acknowledges EIP-8141 as a potential extension: "An EIP-8141-style frame extension could attach nested execution frames to the same transaction envelope without requiring a new top-level transaction type." The positioning is complementary-but-skeptical: solve the envelope and signature agility problem first, add frames later if needed.
Summary
The landscape splits along two axes:
Generality vs. deployability: EIP-8141 is the most general; constraint rises through EIP-8175, EIP-8130 + EIP-8430, EIP-8202, and EIP-XXXX. More generality means richer validation at the cost of mempool complexity.
Scope: EIP-8223, EIP-8224, and EIP-8215/HCA sit off the spectrum and compose with whichever format ships.
Key practical splits:
- PQ readiness: EIP-8141 is PQ-ready through programmable validation and EIP-8288 aggregation; EIP-8130 + EIP-8430 needs a PQ authenticator in the Keystore canonical set. EIP-8215/HCA addresses PQ-safe address derivation. See PQ Roadmap.
- Mempool simplicity: EIP-8130 + EIP-8430 and the envelope-only proposals avoid EVM tracing. EIP-8141 requires it for custom validation, bounded by the restrictive tier.
- EOA support: EIP-8141's default code gives codeless EOAs the cheapest path. Other proposals require smart accounts, new addresses for new schemes, or delegation.
- Key rotation: the EIP-8130 + EIP-8430 Keystore has it natively and can also serve frame accounts. EIP-8141 delegates to account code. EIP-8223 offers it for sponsored accounts.
- Complementary stack: EIP-8141 can compose with narrower primitives such as EIP-8223, EIP-8224, and EIP-8215/HCA rather than forcing every sponsorship, privacy, or PQ-address concern into the base transaction type.
Read Next
- Current Spec — what EIP-8141 specifically does, for direct comparison with the alternatives above.
- EIP-8130 + EIP-8430 — the Coinbase/Base sibling pair, the most direct alternative.
- EIP-8223 and EIP-8224 — the complementary proposals that layer on top of any general-purpose AA.
- Developer Tooling — the wallet-adoption angle on why general vs constrained matters.