ERC-8141 — Native Account Abstraction Study/Demo

Goal: understand and showcase EIP-8141 ("Frame Transactions"), Vitalik + the Geth team + EF Account Abstraction team's proposal to move account abstraction into Ethereum's base layer, and how it relates to rabbit's existing application-layer AA work (§3 ERC-7702/7715, agentic-aa.md).

Source: jay's request, 2026-08-03 (no source file).

1. What it is

A new EIP-2718 transaction type (0x06). A transaction is no longer one call but a sequence of execution frames:

• VERIFY frame — signature validation + fee authorization (replaces the implicit ECDSA check every legacy tx does).
• EXECUTE frame(s) — the actual call(s), one tx can carry several.
• Payment Frames — fees can be paid in supported ERC-20 tokens, not only ETH.

Existing EOAs keep their 0x address, balance, and history when they migrate — this is not a new account type replacing EOAs, it's a new transaction shape they can opt into.

Status (as of the 2026-03-27 All Core Devs call): Considered for Inclusion (CFI) for the Hegotá fork (planned late 2026). Not live on any public testnet yet.

2. Why it matters for rabbit

It's the protocol-native version of what rabbit already demos at the application layer:

• §3 (ERC-7702 delegation + ERC-7715 session keys) — an EOA temporarily runs smart-account code today; a Frame tx could express the same scoped permission natively, with the VERIFY frame doing what a 7715 session-key check does now.
• agentic-aa.md (4-pillar AA demo) — pillars 1–3 (scoped delegation, gas independence, atomic intent) are exactly what Frame Transactions bake into the protocol.

3. Constraint — this can't be a live demo yet

Unlike §3/agentic-aa (deployable via a smart-contract wallet + existing mainnet/testnet EIPs), EIP-8141 needs client/execution-layer support for the new tx type. No wallet or RPC can send a 0x06 tx today. Until a public devnet ships it, this has to be a knowledge/explainer page (same shape as the §18–§20 knowledge pages), not a working demo.

4. Design (explainer page)

• Diagram: legacy tx (single call) vs Frame tx (VERIFY → EXECUTE frame(s)) — before/after comparison, same visual language as ../knowledge/merkle-vs-verkle.html.
• "Subsumes 7702/7715" explainer: show how a Frame tx expresses what a 7702 delegation + 7715 session-key grant do today, without an EOA borrowing contract code.
• Comparison table: EIP-7702 (delegation, live on mainnet) vs ERC-4337 (bundler-based AA, live) vs EIP-8141 (protocol-native, CFI/pending) — maturity, who runs verification logic, fee flexibility.
• Follow-up trigger: once a public devnet with 0x06 support exists, revisit for a real demo (send one Frame tx, decode VERIFY + EXECUTE frames in the UI).

5. Open questions (jay)

• Page-only for now, or wait for devnet support before building anything?
• Where it lives — new /etc subpage vs a docs/knowledge/*.html reference page like §18–§20.

Sources

• EIP-8141: The Era of Programmable Validity
• What EIP-8141 Means for Developers
• A Decade of Account Abstraction, Finally Solved? EIP-8141 in 5 Minutes

Status

Backlog / to do — not yet scheduled.