EIP-8141 Frame Transaction

Appearance

Frequently Asked Questions ​

1. General ​

1.1. What is EIP-8141?

A new transaction type (0x06) that splits a transaction into multiple frames - each with a purpose (verify, execute, deploy), giving every account programmable validation and native batching at the protocol level. Read the spec overview →

1.2. What problem does it solve?

Today, advanced transaction features (gas sponsorship, batching, custom signatures) require off-chain infrastructure and smart contract middleware. EIP-8141 moves these capabilities into the protocol itself.

1.3. What are frames?

Ordered steps within a single transaction. Each frame has a mode - VERIFY (authenticate), SENDER (execute), or DEFAULT (deploy/post-op) - that tells the protocol what the frame does. See frame modes →

1.4. Is EIP-8141 live on mainnet?

No. It is a draft EIP under active development targeting a future hard fork. Track progress on GitHub →

1.5. What new opcodes does it introduce?

Five: APPROVE (authorize execution/payment), TXPARAM (read tx parameters), FRAMEDATALOAD and FRAMEDATACOPY (read frame data), FRAMEPARAM (read frame metadata like mode and flags). Details →

2. ERC-4337 & Bundlers ​

2.1. Does EIP-8141 replace ERC-4337?

In the long run, yes. EIP-8141 is the native protocol successor, moving account abstraction into the transaction layer and eliminating bundlers, the EntryPoint contract, and off-chain UserOperation infrastructure for new flows. In the short term, EIP-8141 is still a draft and ERC-4337 remains the production AA stack; existing 4337 wallets do not stop working when 8141 ships.

2.2. Why are bundlers no longer needed?

The protocol itself handles validation, gas payment, and execution ordering through frames. There is no separate UserOperation mempool - frame transactions use the standard public mempool.

2.3. What about existing ERC-4337 wallets?

Smart accounts built for ERC-4337 can migrate their validation logic into VERIFY frames. The core verification code (signature checks, access policies) is reusable - what changes is how it's invoked.

2.4. Does this affect ERC-4337 paymaster contracts?

Yes. EIP-8141 introduces its own canonical paymaster mechanism at the protocol level, replacing ERC-4337's paymaster interface.

2.5. What happens to bundler operators?

The bundler role is absorbed by the protocol and standard block builders. There is no separate bundler market or infrastructure to maintain.

3. EIP-7702 & Account Delegation ​

3.1. Does EIP-8141 replace EIP-7702?

For most use cases, yes. EIP-7702 requires EOAs to permanently delegate to a smart contract, a persistent on-chain state change. EIP-8141 gives EOAs native AA without any delegation, code deployment, or state change. See EOA default code →

3.2. Can 7702-delegated accounts still use EIP-8141?

Yes, but with a caveat. A 7702-delegated account sends frame transactions like any other, yet the protocol's default code does not run; the delegated contract's code runs instead. If that contract does not implement the APPROVE opcode, the account loses the signature-verification path default code would have given it. This is a real interoperability gap flagged by DanielVF (posts #120, #122). EOAs that want default-code behavior should not 7702-delegate.

3.3. Why is removing the 7702 dependency important?

EIP-7702 relies on ECDSA for its authorization list, making it incompatible with post-quantum signature schemes. EIP-8141 has no authorization list - accounts choose their own cryptography. See competing standards →

4. Users ​

4.1. What does EIP-8141 mean for regular users?

Users get gas sponsorship, atomic batching, and passkey/biometric signing without needing to deploy smart contracts, migrate to new addresses, or rely on third-party relayers.

4.2. Can I keep my existing EOA address?

Yes. EOAs work natively with frame transactions - no code deployment, no delegation, no address change. Your account stays codeless before, during, and after the transaction.

4.3. Can I pay gas in ERC-20 tokens?

Yes, via one of two independent EIP-8141 paymaster patterns. A live ERC-20 paymaster (offchain) runs a signing service that pre-validates your transaction and returns a signature; the VERIFY frame just checks the signature, so the transaction propagates through the public mempool as a non-canonical paymaster (one pending tx per paymaster). A permissionless ERC-20 paymaster (onchain) is a self-contained contract that introspects the next SENDER frame to confirm the ERC-20 transfer without any offchain service; that introspection reads external contract state, so it is consensus-valid but does not propagate through the public mempool today and routes through the expansive tier, a private mempool, or direct-to-builder submission. Neither pattern relies on ERC-4337 infrastructure. See Mempool Strategy → ERC-20 gas repayment: two paymaster patterns →

4.4. Can I batch multiple actions in one transaction?

Yes. Multiple SENDER frames execute sequentially, and consecutive frames with the atomic flag revert together if any fails. See atomic batching →

4.5. Do I need a smart contract wallet to use this?

No. The protocol has built-in default behavior for codeless accounts - ECDSA and P256 signature verification, and multi-call decoding in SENDER frames. Details →

4.6. Is this compatible with passkeys / biometrics?

Yes. The EOA default code supports P256 signatures natively, which covers Apple/Google passkeys and WebAuthn without any contract deployment. Tradeoff flagged by frangio and shemnon during review: P256 accounts do not support key rotation, so an account set up with a passkey cannot later migrate to a PQ-secure scheme without additional EIPs.

4.7. How do I send ETH to someone with a frame transaction?

Build a SENDER frame with target = destination and value = amount; no payload encoding needed. The per-frame value field was added by PR #11534 (Apr 16). Non-zero value is only valid in SENDER frames; DEFAULT and VERIFY frames must set value = 0. See current spec →

5. Wallet Developers ​

5.1. How does EIP-8141 reduce wallet development overhead?

Bundler infrastructure, UserOperation formatting, EntryPoint ABI compatibility, and ERC-4337 paymaster integration all go away. Wallets construct a standard transaction with frames instead.

5.2. Do wallets still need to run or depend on bundlers?

Not for frame transactions. They enter the public mempool like any other transaction, with no separate bundler endpoint, selection, or availability concerns. Wallets that still serve ERC-4337 UserOperations continue to need bundler infrastructure for that path; 8141 and 4337 can coexist during migration.

5.3. Does this reduce vendor dependency?

Yes. Today, wallets depend on bundler providers (Pimlico, Alchemy, etc.) for AA functionality. With EIP-8141, the protocol is the infrastructure - any Ethereum node can validate and propagate frame transactions.

5.4. What about gas sponsorship infrastructure?

For ETH-funded sponsorship (the sponsor pays the user's gas from its own ETH balance), wallets interact with the canonical paymaster directly at the protocol level. No paymaster service API, no vendor SDK, no third-party uptime dependency. For ERC-20 gas repayment the wallet picks a pattern: a live (offchain) paymaster service keeps a vendor dependency but propagates through the public mempool as a non-canonical paymaster; a permissionless (onchain) paymaster removes the service but routes through the expansive tier, a private mempool, or direct-to-builder submission. See 4.3 →

5.5. Can wallets still build custom validation logic?

Yes. VERIFY frames execute arbitrary account code - wallets can implement multisig, social recovery, session keys, or any scheme. The mempool policy constrains what's publicly relayable, but custom logic is valid on-chain.

5.6. What's the migration path from ERC-4337?

Move validation logic from validateUserOp into VERIFY frame code that calls APPROVE. Replace bundler submission with standard transaction broadcasting. Replace EntryPoint paymaster calls with canonical paymaster VERIFY frames.

5.7. Can I give an AI agent or session a scoped key that expires?

Yes, via account code. Default code covers only secp256k1 and P256 on the primary key; richer policies (expiry, per-call caps, allowlists) live in the account's own VERIFY logic and remain valid on-chain. Whether such a transaction propagates publicly depends on the mempool tier it fits.

6. Post-Quantum Readiness ​

6.1. Is EIP-8141 post-quantum safe?

The transaction format itself has no ECDSA dependency. Accounts choose their own signature scheme in VERIFY frames - any PQ algorithm can be used without protocol changes.

6.2. How does this compare to other proposals?

EIP-8141 offers the most flexible PQ path (arbitrary schemes). EIP-8202 now includes native Falcon-512 support (updated from its original ephemeral-k1 design). EIP-8130 requires deploying PQ verifier contracts. Full comparison →

7. Mempool & Network Health ​

7.1. How do nodes validate frame transactions?

Nodes execute the VERIFY frames and check that APPROVE is called. The mempool policy restricts validation to recognized prefixes with bounded gas and banned opcodes.

7.2. What is the canonical paymaster?

A standardized paymaster contract recognized by mempool policy. Nodes verify it by runtime code match and track reserved balances for pending transactions. Spec details →

7.3. What if wallets don't adopt the canonical paymaster?

Transactions using non-canonical paymasters cannot propagate through the public mempool or be enforced by FOCIL inclusion lists - degrading censorship resistance for those users. See open question →

7.4. Does this affect censorship resistance?

Potentially. Mempool health is censorship resistance - if minimal nodes can't validate certain frame transactions, those transactions lose public propagation guarantees. See open question →

8. Statelessness & Scalability ​

8.1. How does EIP-8141 interact with statelessness goals?

Frame transaction validation requires more state access than legacy transactions (~100k gas vs ~3k gas). This tensions with VOPS (Validity-Only Partial Statelessness) nodes that carry minimal state. Details →

8.2. What is the "choose 2 of 3" trilemma?

The observation that current designs cannot simultaneously deliver Frames/Native AA, Public Mempool/FOCIL, and Statelessness/VOPS - you can have at most two. Details → The proposed resolution under a two-tier mempool + VOPS+4 + merkle escape hatch is detailed in Mempool Strategy.

8.3. Is there a workaround for VOPS compatibility?

Yes. The proposed VOPS extension covers nonce, balance, code, and the first 4 storage slots per account, which handles most AA validation reads. Use cases that exceed this baseline include a merkle branch (4-8 kB today, 1-2 kB after binary tree).

8.4. What about encrypted mempools?

Encrypted mempools (e.g., LUCID protocol) are fundamentally incompatible with the public restrictive mempool. The proposed framework routes them through the expansive tier and onchain rebroadcaster contracts instead. See open question →

8.5. How much extra state do nodes need?

At full AA adoption with 4 cached storage slots per account, VOPS nodes would need ~72 GB total - an 8x increase from today's ~10 GB floor. Details →

8.6. Can privacy pools use frame transactions today?

Not through the public mempool or FOCIL. Frames structurally remove relayer trust (invalid or replayed proofs revert in VERIFY before gas is charged), but Groth16 verification exceeds the 100k VERIFY cap, per-IL gas budgets fit only ~2 frame transactions, and nullifier slots live outside VOPS+4. See the three gates →

9. Competing Proposals ​

9.1. What are the alternatives to EIP-8141?

Four competing proposals: EIP-8175 (composable capabilities with programmable fee_auth), EIP-8130 (declared verifiers, no EVM in validation), EIP-8202 (scheme-agile flat transactions), and a Tempo-like proposal (fixed UX primitives). Full comparison →

9.2. Which is most likely to ship?

Unclear. EIP-8141 is the most comprehensive but also the most complex. EIP-8130 has strong Base/Coinbase backing. EIP-8175, EIP-8202, and Tempo are earlier stage. See activity comparison →

9.3. Can EIP-8130 be built on top of EIP-8141?

In principle yes. Declared verifiers are a subset of what VERIFY frames can do, while the reverse is not true. This is a key argument from EIP-8141 proponents. EIP-8130 authors contest the framing: their case is that a narrower primitive with no EVM in validation is better suited to performance chains regardless of whether it can be rebuilt on 8141. Both proposals remain active.

9.4. What is EIP-8223 and how does it relate to EIP-8141?

A new proposal (PR #11509, Apr 11 2026) for static gas sponsorship via a canonical payer-registry predeploy at 0x13. Its author explicitly frames it as complementary to EIP-8141 and EIP-8175, covering the narrow case where validation needs only an SLOAD plus a balance check. See EIP-8223 →

9.5. What is EIP-8224 and how does it relate to EIP-8141?

A follow-up proposal (PR #11518, Apr 12 2026) for shielded gas funding via fflonk ZK proofs against canonical fee-note contracts. Solves the bootstrap problem of funding a fresh EOA without traceable on-chain links. Composes with EIP-8223 (one-shot bootstrap, then sponsored txs). See EIP-8224 →

10. Implementation & Timeline ​

10.1. Is implementation complexity a concern?

Yes. Frame transactions touch consensus, mempool policy, p2p propagation, client state management, and wallet infrastructure simultaneously. This breadth is a contributing factor to Glamsterdam delays. Details →

10.2. Where can I follow the spec development?

For VOPS and statelessness details, see VOPS Compatibility →. For mempool open questions, see Mempool Strategy →.