Mempool Strategy
TL;DR
EIP-8141 separates what is consensus-valid (programmable, broad) from what the public mempool propagates (constrained, opinionated). The proposed strategy uses two tiers in parallel:
- Restrictive mempool ships in clients first. Covers status-quo accounts plus PQ signatures, P256, and gas sponsorship via canonical paymasters. This is the public mempool policy already specified in the current spec.
- Expansive mempool develops in parallel, opt-in per node. Built on the ERC-7562 lineage. Handles privacy protocols and complex validation. FOCIL nodes default to the restrictive set and may add expansive channels at their discretion.
For state, the proposal extends the VOPS baseline to include nonce, balance, code, and the first 4 storage slots per account. Use cases outside this extension pay an explicit cost: a merkle branch (4-8 kB today, 1-2 kB after binary tree migration) per extra-VOPS state item. See the AA-VOPS thread for origin.
The framing is borrowed from Bitcoin: let consensus rules do a lot, but restrict at the mempool layer. Bitcoin Core's policy rules are upgradable without hardforks, which is why Bitcoin has evolved for 15+ years while keeping the consensus footprint narrow. EIP-8141 applies the same pattern.
A consequence: the proposal claims frame transactions remove the need for off-chain relayers. Privacy rebroadcasters and permissionless (onchain) ERC-20 gas-fronting flows are designed to be expressible as pure onchain smart contracts, with no live third-party actors required in the transaction supply chain. These onchain flows run through the expansive tier or a private mempool rather than the public restrictive mempool; the separate live (offchain) ERC-20 paymaster pattern keeps a signing service in the loop and is restrictive-mempool-compatible. See ERC-20 gas repayment: two paymaster patterns.
Two Tiers in One Mempool
Note: The restrictive tier is in the current EIP-8141 spec. The expansive tier is a proposed framework, not a shipped feature.
A frame transaction that does not match the mempool rules is still consensus-valid on-chain. It just cannot be gossiped through the public p2p network. This separation makes the two-tier strategy possible.
| Tier | What it carries | Validation cost | Status |
|---|---|---|---|
| Restrictive | Status-quo accounts, PQ sigs, P256, canonical paymaster, non-canonical (1 pending tx) | Bounded: 4 prefix shapes, 100k gas, banned opcodes, sender-only reads | Specified in EIP-8141 |
| Expansive | Privacy protocols, multi-paymaster, arbitrary VERIFY policies | Higher: ERC-7562 staking/reputation, full simulation | Proposed, opt-in per node |
Restrictive Mempool: What Ships First
The restrictive tier covers a small surface:
- Self relay: account validates itself and pays its own gas
- Canonical paymaster sponsorship (ETH-funded): a paymaster matching the canonical runtime code pays gas from its own ETH balance
- Account deployment: deterministic deployment as the first frame
- Non-canonical paymaster: bounded to 1 pending tx per paymaster
Validation constraints: one of four prefix shapes, gas 100k, banned opcodes (ORIGIN, TIMESTAMP, BLOCKHASH, CREATE, BALANCE, SSTORE, etc.), storage reads only on tx.sender, no calls to non-existent contracts.
What this enables: secp256k1, P256/passkeys, PQ signatures fitting the validation budget, ETH-funded gas sponsorship via the canonical paymaster, smart account validation reading only its own storage.
ERC-20 gas repayment: two paymaster patterns
"Pay gas in ERC-20" is not a single pattern under EIP-8141. The spec supports two distinct paymaster shapes that interact with the restrictive and expansive mempools very differently. The canonical paymaster handles neither; it only covers ETH-funded sponsorship. Both shapes below are native EIP-8141 patterns and do not depend on any ERC-4337 infrastructure.
| Dimension | Live ERC-20 paymaster (offchain) | Permissionless ERC-20 paymaster (onchain) |
|---|---|---|
| VERIFY logic | Checks a signature from the paymaster's offchain service; reads only the paymaster's own storage | Introspects the next SENDER frame and reads the ERC-20 contract's storage to confirm the transfer |
| Offchain service | Paymaster signing service required | None |
| Mempool tier | Restrictive (public), as a non-canonical paymaster subject to MAX_PENDING_TXS_USING_NON_CANONICAL_PAYMASTER = 1 per paymaster | Expansive, private mempool, or direct-to-builder submission |
| VOPS-compatible | Yes | No (reads state outside the VOPS+4 slice) |
| Trust model | Paymaster absorbs front-run risk; user has no rational incentive to exploit, since executing the front-run also burns their own gas | Trustless; frame introspection makes the contract enforce the transfer before approving payment |
| Unique to EIP-8141 | No (any signature-checking paymaster works this way) | Yes (enabled by frame introspection) |
Example 5 in the spec (EOA Paying Gas in ERC-20s) is the permissionless onchain variant.
The restriction on the permissionless onchain pattern is deliberate. The restrictive tier forbids arbitrary external storage reads during validation in order to preserve VOPS compatibility (see VOPS Compatibility): a node running with a partial-statelessness slice cannot safely validate a transaction whose inclusion depends on state outside its slice. Active design directions for bringing this pattern onto the public mempool in a future revision include AMM paymaster contracts (liquidity providers absorb the front-run risk in exchange for a fee), ERC-7562-style validation rules allowing narrowly-scoped shared-state reads under staking or reputation constraints, and guarantor payers (open in PR #11555, Apr 22) where a guarantor commits to paying gas even if sender validation fails, letting mempool nodes skip sender simulation entirely and admit VERIFY frames that read shared state. These are open, not specified.
Expansive Mempool: What Develops in Parallel
For use cases exceeding restrictive policy. Principal examples: privacy protocols that must read state outside tx.sender to verify nullifiers, and permissionless (onchain) ERC-20 paymasters whose VERIFY frames introspect the next SENDER frame and read the ERC-20 contract's storage to authorize payment (see ERC-20 gas repayment: two paymaster patterns).
The expansive tier accepts ERC-7562-style validation with staking/reputation, paymaster-extended policies, and arbitrary VERIFY logic subject to the node's resource budget. It is not a precondition for shipping EIP-8141. Clients ship restrictive first; the privacy/complex-validation community develops expansive independently. No hardfork dependency between the two.
Transactions that do not fit the restrictive tier are still consensus-valid on-chain. They just do not propagate through the public p2p network and must reach a block builder through private channels (direct submission, bundled relays, opt-in expansive-tier peers).
The State Side: VOPS + 4 Slots
The proposed extension for frame transactions:
| State item | Per account | Notes |
|---|---|---|
| Nonce | Already in VOPS | Standard EOA validation |
| Balance | Already in VOPS | Standard EOA validation |
| Code | Already in VOPS | Needed to detect smart accounts |
| First 4 storage slots | New | Covers most common AA validation reads |
A small constant-factor increase over the VOPS baseline, covering the validation reads of well-designed AA wallets (signer set, sequencer key, replay-protection counter).
The Merkle Branch Escape Hatch
For use cases reading state outside VOPS+4, the transaction includes a merkle branch proving the state items it reads.
| Property | Today (MPT) | After binary tree |
|---|---|---|
| Branch size per item | 4-8 kB | 1-2 kB |
| Items typically proved | 1-2 | 1-2 |
Status-quo and AA-VOPS-friendly transactions pay zero extra. Privacy protocol transactions pay one or two branches. The infrastructure already exists in clients (witness machinery for sync, standardized RPC methods for users to obtain witnesses).
Resolving the Trilemma
The "choose 2 of 3" trilemma (Frames + FOCIL + VOPS) resolves under this strategy:
| Transaction class | Restrictive? | FOCIL? | VOPS+4? | Extra cost |
|---|---|---|---|---|
| Status-quo accounts | Yes | Yes | Yes | None |
| AA wallets reading 4 own slots | Yes | Yes | Yes | None |
| AA wallets reading > 4 own slots | Yes | Yes | Yes (witness) | 1-2 branches |
| Canonical paymaster (ETH-funded) | Yes | Yes | Yes | None |
| Non-canonical, low volume | Yes (1 pending) | Yes | Yes | None |
| Non-canonical, high volume | No (expansive) | Opt-in | N/A | Expansive tier |
| Live ERC-20 paymaster (offchain) | Yes (1 pending) | Yes | Yes | Non-canonical cap |
| Permissionless ERC-20 paymaster (onchain) | No (expansive/private) | Opt-in | Yes | Expansive tier or private mempool |
| Privacy protocol | No (expansive) | Opt-in | Yes (witness) | Branches + expansive |
Frames + FOCIL + VOPS coexist for the majority of traffic. Edge cases pay per-tx cost or move to the expansive tier.
Why Frame Transactions Don't Need Relayers
Anything a relayer does for EIP-4337 can be expressed as a pure onchain smart contract under EIP-8141.
Privacy rebroadcasters become onchain contracts observing the canonical mempool and repackaging transactions with witness branches. ERC-20 gas fronting takes two independent shapes under EIP-8141: a permissionless ERC-20 paymaster (onchain) that replaces the relayer entirely via frame introspection (expansive-tier or private-mempool only), and a live ERC-20 paymaster (offchain) that keeps a signing service in the loop and propagates through the restrictive mempool as a non-canonical paymaster. See ERC-20 gas repayment: two paymaster patterns.
This is the structural argument against EIP-4337 + EIP-7702: in those designs, the relayer is required because validation does not run in-protocol. EIP-8141 brings validation in-protocol, which the proposal claims removes the structural need for out-of-protocol actors. Whether on-chain substitutes match bundlers' operational properties in practice is an open question.
The practical implication is central to the Developer Tooling bull case: the wallet adoption cost reduces to "implement a new transaction type."
Open Questions
Mempool Health and Censorship Resistance
Nodes that cannot validate frame transactions cannot maintain healthy mempools, propagate them, or enforce FOCIL inclusion lists covering them. This degrades to reliance on specialized infrastructure. The two-tier architecture mitigates this: the restrictive tier is validatable by minimal nodes, and FOCIL nodes default to that tier. Whether this is sufficient depends on FOCIL adoption breadth.
Canonical Paymaster Adoption
The restrictive tier relies on a canonical paymaster recognized by runtime code match. If wallets prefer non-canonical paymasters (richer features, multi-token payment), those transactions are limited to 1 pending tx each and cannot be enforced by FOCIL. Historical precedent: ERC-4337 paymaster diversity is high, with no dominant canonical variant. The expansive tier is the proposed long-term answer, but it is opt-in. This remains market-driven, not protocol-enforceable.
Encrypted Mempool Compatibility
Encrypted mempools (like LUCID/EIP-8184) encrypt transaction contents before inclusion. Nodes cannot check even minimal fields for DOS prevention. The proposed answer routes encrypted transactions through the expansive tier and onchain rebroadcasters, not the restrictive tier. See also PQ Roadmap → Stage 4.
Transaction Propagation Fragility
The restrictive tier's propagation guarantee rests on every client implementing the same policy rules. If implementation drift occurs (one client ships early, another is slow, a third adds tweaks), the effective propagation surface shrinks to the intersection. This is a well-known failure mode for non-consensus policy rules. Mitigations are social: reference implementations, conformance tests, client-developer consensus on canonical paymaster bytecode.
Privacy Pools and the Three Gates
Nero_eth's Three Gates to Privacy (Apr 16 2026) argues that shielded-pool withdrawals must pass three independent validation gates to reach a block under current rules, and all three reject them by default:
| Gate | What it checks | Why privacy withdrawals fail |
|---|---|---|
| Public mempool | VERIFY ≤ 100k gas, reads bounded to tx.sender storage, banned opcodes | Groth16 pairing check ~250k gas exceeds cap; nullifier slots live in the pool contract, not tx.sender |
| FOCIL enforcement | Per-tx 100k cap and per-IL 250k budget | Cumulative budget fits ~2 frame transactions; append-loop builder compliance imposes quadratic overhead |
| VOPS / AA-VOPS node validation | Nodes carry only balance/nonce (VOPS) or a few slots per account (AA-VOPS) | Nullifier lookups are hash-keyed slots in an external contract; no fixed N suffices, AA-VOPS cannot help |
What frame transactions already give privacy flows: invalid-proof and replayed-proof cases both cause VERIFY to revert before gas is charged, so a sponsor can be paid from the withdrawn amount itself with zero trust assumption and no out-of-protocol relayer. The gates, not the flow itself, are what block inclusion today.
The post proposes five protocol changes to create a viable inclusion path:
- Extend the canonical-contract code-hash exemption to recognized privacy pools.
- Raise the per-transaction
VERIFYgas cap to ~400k for canonical frames. - Adopt validation-index FOCIL enforcement: builders publish
(tx_hash, claimed_index)pairs and attesters validate once at the claimed state, breaking the append-loop quadratic. - Raise
MAX_VERIFY_GAS_PER_INCLUSION_LISTto 2^20 (1M gas). - Relax the bounded state-access rule for canonical privacy pools so nullifier reads are propagatable.
Tradeoff acknowledged in the post: under the validation-index model, attesters absorb up to ~28% of block gas in the worst case within the 4-second attestation deadline. Whether that remains feasible under stressed network conditions is open. The proposal also assumes PS (partially stateful) nodes voluntarily track privacy pools, an infrastructure coordination problem that protocol changes alone do not solve.
See VOPS Compatibility → Status for the state-side row on privacy-pool reads.
Summary
- Two-tier mempool (proposed): Restrictive (in spec, common case) and Expansive (parallel, opt-in, privacy and complex validation).
- VOPS extension (proposed): nonce, balance, code, first 4 slots per account.
- Merkle branch escape hatch (proposed): 4-8 kB today, 1-2 kB after binary tree. Cost falls on transactions that need it.
- Trilemma: Frames + FOCIL + VOPS coexist for majority of traffic. Edge cases pay per-tx cost or use the expansive tier.
- Bitcoin pattern (analogy): permissive consensus + restrictive mempool gives upgradability without hardforks.
- No relayers (proposed claim): privacy rebroadcasters and permissionless (onchain) ERC-20 paymasters are expressible as onchain contracts running through the expansive tier or private mempool. The live (offchain) ERC-20 paymaster pattern keeps a signing service in the loop but does propagate through the restrictive public mempool. Whether onchain variants match bundler operational properties is open.
- Open questions: canonical paymaster adoption (market-driven), propagation fragility (cross-client alignment), encrypted mempool routing (expansive tier), mempool health (FOCIL adoption), privacy pools and the three gates (canonical-pool exemption + validation-index FOCIL + raised VERIFY caps proposed).
Read Next
- VOPS Compatibility — the state-side view of the same trilemma, with plain-English definitions of VOPS, FOCIL, and validation state.
- Current Spec → Mempool Policy — the restrictive tier as it appears in the spec itself.
- PQ Roadmap — how the mempool strategy interacts with encrypted mempools and the longer PQ arc.