Spec Chronology
🤖 AI-Generated Content
This chronology is AI-generated from public sources (EIPs repo commit history, Ethereum Magicians forum). See the home page for the full disclaimer.
This page traces the evolution of EIP-8141 from its initial publication through the various revisions, community debates, and design shifts that shaped the spec we are implementing against. Understanding this history is essential context — it shows which design decisions were contested, what alternatives were considered, and where the spec might still be in flux.
Prehistory: The Road to EIP-8141
EIP-8141 did not emerge from a vacuum. It is the latest in a long line of account abstraction proposals, each of which informed its design:
| Year | Proposal | What it did | Why it wasn't enough |
|---|---|---|---|
| 2020 | EIP-2938 | First native AA proposal — allowed smart contracts to originate transactions with a PAYGAS opcode | Failed due to lack of protocol-level introspection. Hard to build safe mempool rules around fully arbitrary validation. |
| 2021 | ERC-4337 | User-level AA via a singleton EntryPoint contract, separate bundler network | Works but adds infrastructure overhead (bundlers), gas inefficiency, and an extra trust layer. Not truly native. |
| 2023 | EIP-3074 | AUTH / AUTHCALL opcodes for EOA delegation | Only handled authorization, not validation or payment. Superseded by EIP-7702. |
| 2024 | EIP-7702 | Set code for EOAs via authorization tuples | Tied to ECDSA for the authorization list. Low/slow adoption in practice due to wallet inertia, smart account complexity, and cross-chain deployment friction. |
| 2025 | EIP-7701 | Native AA with validation/execution phases | Informed EIP-8141's APPROVE design. Had awkward auto-propagation rules through DELEGATECALL. |
| 2026 | EIP-8141 | Frame Transaction — multi-frame execution with typed modes, native PQ path | Where we are now. |
As matt (lightclient) put it on the Magicians forum: "We have already attempted a simpler proposal than EIP-8141 when we proposed EIP-2938. It was simpler and allowed you very arbitrarily define the smart contract system to determine the validity, PAYGAS, and execute calls. But it failed due to the lack of protocol-level introspection. [...] The frame transaction is a direct response to this."
Timeline: EIP-8141 Spec Evolution
January 29, 2026 — Initial Publication
Commit: 6f46a8c by Felix Lange (fjl)
The EIP is published as a Draft. The initial version establishes the core concepts:
- Transaction type
0x06with the frames-based architecture - Three modes:
DEFAULT,VERIFY,SENDER APPROVEopcode (originally restricted to top-level call frame)TXPARAM,FRAMEDATALOAD,FRAMEDATACOPYopcodes- No EOA default code — only smart accounts
The Magicians discussion thread opens immediately and becomes very active (~100+ comments over the following weeks).
Same-day fixes: Typos (723c9ca), status field number fix (187d1ce).
Early Community Debates (late January — early February)
Several key discussion threads emerge on Ethereum Magicians:
Multiple APPROVE calls: @thegaram33 asks what happens with multiple VERIFY frames calling APPROVE. Answer: redundant approvals revert the frame but don't invalidate the transaction. Only the first approval counts.
Frames vs. simpler designs: @Helkomine argues that the same functionality is achievable with command-oriented architectures (like Uniswap's UniversalRouter) and that the protocol doesn't need multiple frames. lightclient responds that frames exist for protocol-level introspection — enabling the mempool to reason about transaction validity, something purely user-level constructs cannot do.
APPROVE propagation: @nlordell and @frangio raise questions about how APPROVE propagates through nested calls. This becomes a significant design discussion.
Terminology clash: @frangio notes that "frame" already means "call frame" in EVM terminology — the EIP is overloading the term. fjl responds that frame transactions create an opportunity for multiple top-level call frames, so it is the same concept.
February 10, 2026 — APPROVE Relaxation
Commit: c30b9c6 by lightclient
A significant design change: the requirement that APPROVE must be called in the top-level call frame is relaxed. Now APPROVE can be called from any call depth, but only when ADDRESS == frame.target. This change was driven by forum feedback about how proxy-based smart accounts (common in the ERC-4337 ecosystem) need to delegate validation logic.
fjl explains the rationale: "We decided explicitly against making it propagate automatically, because it'd be a weird and unprecedented non-local exit from an inner call frame."
March 2, 2026 — Bug Fixes and Clarifications
Commit: 52933c2 by Derek Chiang
Fixes several issues raised on the forum, including the CALLER vs ADDRESS check for APPROVE that @nlordell had identified — the original spec incorrectly used CALLER == frame.target when it should be ADDRESS == frame.target.
March 5, 2026 — Breakout Call
A dedicated breakout call is held to discuss EIP-8141, described as a "headliner" for the upcoming Hegota hard fork. This signals that EIP-8141 is being seriously considered for inclusion in a near-term upgrade, alongside FOCIL for censorship resistance.
Meanwhile, sm-stack publishes a proof-of-concept implementation using a custom geth fork + Solidity contracts, raising the issue of ERC-20 paymaster overcharging due to gas refund mechanics.
March 10, 2026 — EOA Support Added
Commit: fe43214 by Derek Chiang
A major addition: the "default code" mechanism for EOAs. This allows existing EOAs to participate in frame transactions without deploying smart account code. The default code supports:
- ECDSA (secp256k1) signature verification
- P256 signature verification (for passkeys)
- Batch calls in
SENDERmode via RLP-encoded call lists
Derek Chiang explains the motivation: "We've seen in practice that adoption for EIP-7702 has been low/slow due to the huge inertia of existing players. [...] EOAs can enjoy AA benefits consistently across all chains who are EVM-compatible, without depending on any contract deployments."
P256 debate: @shemnon pushes back on P256 as "scope creep." Derek acknowledges the concern and notes that P256 may be extracted from the default code into a separate contract spec, since some co-authors worry that "enabling native P256 EOAs with no clear path to migrate them to quantum-resistant accounts is a form of protocol tech debt."
March 12, 2026 — Frame Access Opcode Cleanup & Approval Bits
Commits: a0c3bbd, df2a272, 6b9954e by Felix Lange
A burst of refinement:
- Frame access opcodes (
FRAMEDATALOAD,FRAMEDATACOPY) are cleaned up - Approval bits are added to the
modefield — bits 9 and 10 now declare what type ofAPPROVEaVERIFYframe is allowed to call, enabling the mempool to reason about frame behavior before execution - Bit index fix follows shortly after
March 13, 2026 — Derek Chiang Added as Co-author
Commit: ee66073 — this is the version we implement against.
Ongoing Discussions (as of mid-March 2026)
Several open threads on Ethereum Magicians remain active:
Simplification Proposals
@0xrcinus proposes reducing from three modes to two (VERIFY + EXECUTE), removing APPROVE scope operands entirely, and adding frame "groups" for atomicity. These are substantial simplification proposals that could reshape the spec.
Async Execution Compatibility
@pdobacz raises concerns about compatibility with async execution proposals like EIP-7886 — frame transactions require EVM execution during validation, which complicates async block execution.
Protocol Complexity Concerns
@DanielVF voices broader concerns: "Frame transactions would make checking transaction inclusion now require access to all blockchain state and execution of a Turing complete programming language. These are not trivial things." He argues for simpler, more standardized solutions over infinite EVM-level flexibility, citing the slow adoption of EIP-7702 and ERC-4337 as cautionary tales.
Transaction Assertions
@alex-forshtat-tbk proposes using VERIFY frames for "transaction assertions" via a state diff opcode (EIP-7906). @frangio pushes back, arguing assertions are outside AA scope and dilute the case for the EIP.
Key Takeaways for Implementers
The spec is moving fast. Between January 29 and March 13 there have been 12 commits, several with significant semantic changes. Expect more.
APPROVE semantics are the most debated aspect. The calling convention, propagation rules, and scope operand have all changed at least once. This is the area most likely to change again.
EOA default code is recent and still contested. Added March 10, debated immediately. P256 support may be extracted. The default code section should be treated as particularly volatile.
Mempool strategy is unresolved. Multiple community members have flagged this as a critical gap. The addition of approval bits (March 12) is a step toward addressable mempool validation, but concrete strategies are still TBD.
The relationship with Hegota is significant. EIP-8141 is positioned as a headliner for the next hard fork, paired with FOCIL for censorship resistance. This gives it urgency but also means it is under intense scrutiny.