Summary

EIP-8141 Frame Transactions is the proposed native account abstraction mechanism for Ethereum’s Hegotá hard fork (H2 2026). Unlike ERC-4337 (application-layer AA), Frame Transactions are a first-class transaction type that decomposes a transaction into sequenced “frames” with explicit validation, payment, and execution roles. The design supports sponsored transactions, ephemeral key rotation, post-quantum migration, encrypted transactions, and FOCIL enforcement — all without a separate bundler infrastructure.

Three Axioms

Frame Transactions are built on three core operations:

  1. FRAME — Subdivide the transaction into units of execution. A transaction is a sequence of frames; each frame has a mode, a target, calldata, and gas limit.

  2. APPROVE — A frame can call APPROVE to designate a payer. This separates identity (sender) from payment (payer), enabling sponsorship without trust.

  3. INTROSPECT — Frames can read the current execution state (who has approved, what gas remains, etc.) to make conditional decisions.

These axioms cover all account abstraction use cases: sponsored execution, social recovery, multi-sig, batched calls, and more.

Frame Modes

ModePurpose
VERIFYValidation prefix: authenticate sender and establish payer. Must precede DEFAULT and SENDER frames.
SENDERExecute as the sender account.
DEFAULTStandard call execution.
PAYHandle payment.

A typical AA transaction: [VERIFY (authenticate), DEFAULT (execute), PAY (pay gas)]

Canonical Structure

FrameTx = {
  sender: address,
  frames: [Frame],  // ordered list
  nonce: uint,
  max_fee_per_gas: uint,
  max_priority_fee_per_gas: uint,
  ...
}

Frame = {
  mode: Mode,       // VERIFY | SENDER | DEFAULT | PAY
  to: address,      // target contract
  data: bytes,      // calldata
  gas_limit: uint,
  value: uint       // ETH to send
}

Default Account

A key design choice: EIP-8141 includes a default account contract that mimics current EOA behavior. An account that has no custom validator logic just uses the default account, which checks ECDSA/secp256k1 signatures. This means:

  • The upgrade is backward-compatible: existing EOA behavior is preserved.
  • No user needs to deploy a custom validator unless they want custom logic.
  • Wallets can migrate incrementally.

Statelessness Compatibility

Frame transactions interact with Ethereum’s statelessness roadmap (Verkle trees, stateless clients) through three mempool policy strategies:

StrategyDescriptionMEV surface
1 (Conservative)VERIFY reads only sender state (balance, nonce)None beyond EOA
2 (AA-VOPS)VERIFY can access N storage slots (N=2–4, cached per account)Small; bounded by cache
3 (Unrestricted)VERIFY can access arbitrary statePotentially large; private mempool only

AA-VOPS (Validity Operation Vouching) is the planned standard: validators cache a small number of storage slots per account (N=2–4), enabling smart wallet validation patterns (nonce in slot 0, owner in slot 1, etc.) while keeping witness sizes small.

Strategy 1/2 transactions are public-mempool eligible. Strategy 3 transactions go through private orderflow channels (ERC-4337 style bundlers, private mempools) — their omission is always excused by FOCIL.

FOCIL Integration (Thomas Thiery, Mar 2026)

FOCIL (EIP-7805) enforces inclusion of valid public-mempool transactions. For Frame Transactions, the standard nonce/balance proxy doesn’t work because the payer may differ from the sender (discovered only during VERIFY execution).

Three-tier eligibility check:

  • Tier 1 (static): VERIFY-first ordering, bounded VERIFY gas (MAX_VERIFY_GAS_PER_FRAMETX ≈ 100,000), IL budget (MAX_VERIFY_GAS_PER_INCLUSION_LIST ≈ 250,000), basic sanity.
  • Tier 2 (post-state reads): nonce match, gas fit.
  • Tier 3 (bounded validation prefix replay): execute VERIFY frames against post-state; check payer solvency; check N-slot bounded state access (constraint 5).

A FrameTx that fails any tier is excused — its omission is not a FOCIL violation.

Note: PQ signatures (Falcon, Dilithium) exceed MAX_VERIFY_GAS_PER_FRAMETX and are therefore FOCIL-ineligible at launch. They propagate via alternative channels; omission is always excused.

Builder Complexity

The iterative append loop for FOCIL-eligible FrameTxs is O(k²) in the worst case, where k = excluded eligible FrameTxs. With 16 unique excluded txs and the proposed parameters, this is ~22.7% of the block gas limit in VERIFY-gas — a significant builder overhead that needs benchmarking.

Ephemeral Key Rotation

Frame Transactions enable per-transaction key rotation via a singleton registry contract:

  • A user registers a master key and a chain of ephemeral keys.
  • Each transaction is signed with the current ephemeral key.
  • The VERIFY frame checks the signature and rotates to the next key.
  • Post-quantum mitigation: even if secp256k1 is broken, each key is used only once, minimizing exposure.
  • Compatible with BIP44 HD key derivation.

Encrypted Frame Transactions

A variant where the execution frames are encrypted and decrypted within the same slot:

  • KEM-DEM split: Key Encapsulation Mechanism wraps a symmetric key; the symmetric key encrypts the frame body.
  • The VERIFY frame proves the commitment without revealing the contents.
  • The execution commitment is made at ordering time; decryption happens after the block producer has committed.
  • Prevents front-running and sandwiching.
  • Free-option problem: if users can withhold decryption keys, they get a free option on execution. Solved via slashable commitments.

Roadmap Position

EIP-8141 is a confirmed Hegotá (H2 2026) inclusion alongside LUCID and FOCIL. The three are designed as a complementary package:

  • FOCIL: censorship resistance via inclusion lists
  • LUCID: pre-execution privacy via encrypted mempool
  • Frame Transactions / EIP-8141: flexible account validation enabling all of the above

Open Questions

  • Will AA-VOPS be finalized with N=2, 3, or 4 slots? (Needs benchmarking against real smart wallet patterns.)
  • How does the O(k²) builder complexity affect slot timing in practice?
  • Should PQ signatures be FOCIL-eligible from day one (requiring a higher gas budget) or start in private mempool mode?
  • How do witnesses for expanded reads (beyond N-slot cache) interact with stateless client assumptions?

Key Sources

  • The Case for Frame Transactions (2026) — advocacy; three axioms; default account concept
  • Frame Transactions Through a Statelessness Lens (Mar 2026) — Strategy 1/2/3; AA-VOPS
  • FOCIL + Native AA (Thomas Thiery, Mar 2026) — eligibility constraints; three-tier check; O(k²) analysis
  • Native Ephemeral Key Rotation (2026) — singleton registry; BIP44; PQ mitigation
  • Encrypted Frame Transactions (Mar 2026) — KEM-DEM split; free-option problem