Stake makes identities cost something
Creating an on-chain entity is free. A stake of roughly USD 1000 with a one-day unstake delay gives it a price. The stake is never slashed. The lock-up is the cost.
Alternative mempools for Frame Transactions
EIP-8141's public mempool says no to almost everything that needs real validation logic. ERC-8421 lets nodes say yes, by pricing abuse with stake and reputation instead of banning whole features.
Which mempool admits what
Four transactions the canonical rules struggle with, and how each mempool treats them.
| Use case | CanonicalEIP-8141 | Standard alternativeERC-8421 | Your ownoperator rules |
|---|---|---|---|
| Privacy withdrawalProof check of about 350k gas, shared sender, keyed nonces | Limited100k gas cap is too low for a proof. | Good, with stakeA staked sender gets 1M gas and no sender-wide pending cap. BUDGET-010LIFECYCLE-030 | CustomSet your own gas limit. |
| Keystore walletCredentials live outside the sender account | RejectedStorage outside the sender is third-party mutable state. | GoodSlots associated with the sender are readable. Deploying the account in the same transaction needs a staked factory. STORAGE-021STORAGE-022 | CustomTrust a keystore contract you audited. |
| Post-quantum signatureVerified in plain EVM, about 700k gas | RejectedFar above the 100k gas cap. | Good, with stakeA staked sender gets 1M gas. BUDGET-010 | CustomReplace hot Solidity with a native binary. |
| Token paymasterPays gas, collects ERC-20 tokens | RejectedNo state-writing frame, third-party storage, and one pending transaction per paymaster. | Good, with stakeA pre_verify frame collects the tokens. A staked paymaster keeps its own storage and has no pending cap. PREFIX-110STORAGE-031 | CustomAllow-list a paymaster and set your own pending limit. |
Gas figures are illustrative. Stake means at least MIN_STAKE_VALUE with a one-day unstake delay.
The canonical mempool is strict on purpose
A Frame Transaction replaces the hard-coded signature check with EVM code. That code runs in the validation prefix, and a node must run it before it may relay the transaction. Nobody pays the node for that work.
If the prefix reads state that anyone can change, one cheap write can invalidate thousands of pending transactions at once. That is the mass invalidation attack, and it is what every rule below exists to stop.
| MAX_VERIFY_GAS | 100,000 for signatures and the whole validation prefix |
|---|---|
| MAX_VERIFY_STATE_GAS | 500,000 across the prefix |
| MAX_PENDING_TXS_USING_NON_CANONICAL_PAYMASTER | 1 pending transaction per paymaster |
| Storage | The sender's own, plus the code of other contracts it calls. No third-party mutable state. |
| Trust | None to earn. No stake, no reputation. |
Only four prefix shapes get through
Each box is a frame. The hatched box stands for every frame after the prefix. Those frames are outside mempool validation.
Self relay
self_verifyexecution body
Self relay, new account
deployself_verifyexecution body
Canonical paymaster
only_verifypayexecution body
Canonical paymaster, new account
deployonly_verifypayexecution body
We can do more outside the protocol
Mempool rules need no consensus change. The canonical mempool avoids risk at any cost. An alternative mempool trades a little of that safety for features, and covers the risk with three tools.
Reputation lets trust build up
Each node counts how often an entity's transactions are seen and how often they are included. Entities that cause invalidations get throttled, then banned.
Tracing sees what validation actually did
Nodes trace the simulation and check which storage slots were touched. Slots keyed by the sender's address count as the sender's own.
How an entity earns and loses its standing
A node counts how often it has seen an entity's transactions, and how many of them were included in a block. Good behaviour builds standing. When the gap grows, the entity is limited, then removed.
The entity behaves. Its transactions are included and its standing recovers.Its transactions stop being included. Standing falls until it is banned.
BANNEDNo new transactions. Pending ones that reference it are removed.
THROTTLEDAt most 4 pending, 4 per block built, and 10 blocks in the mempool.
ACTIVETransactions are admitted. A staked entity has no cap on pending transactions.
What the standard alternative mempool relaxes
The standard mempool extends the public one rather than replacing it. A wallet that targets the public mempool needs no knowledge of ERC-8421.
| Limit | Canonical (EIP-8141) | Standard alternative (ERC-8421) |
|---|---|---|
| Validation gas | 100,000 total | 100,000 per unstaked entity 1,000,000 per staked entity BUDGET-010 |
| State gas | 500,000 cap | No cap. The payer's solvency check already reserves it. Rationale |
| Writes in the prefix | Not in the four recognized shapes | Allowed in deploy and pre_verify frames PREFIX-120 |
| Storage of other contracts | Rejected | Storage associated with the sender is allowed. A staked entity may also read any storage and write slots keyed by its own address. STORAGE-021, 031-033 |
| Balance opcodes | Banned | Allowed for staked entities OPCODES-010 |
| Pending per paymaster | 1 | 10 to start for an unstaked payer, growing with inclusions. No cap for an active staked one REPUTATION-220 |
| Payer solvency | Explicit reservation for canonical paymasters | Reserved cost tracked for every payer SOLVENCY-010 |
What you can build with that freedom
Privacy protocols
Some withdrawals need far more than 100k gas to verify. A staked sender can spend up to 1M, and a keyed nonce per user keeps their transactions independent.
Token paymasters
ERC-20 balances and allowances live in arbitrary storage. A pre_verify frame lets the paymaster collect its tokens before it commits to pay.
Keystore contracts
Credentials live in storage outside the sender account. Slots associated with the sender are readable.
Quantum cryptography
Post-quantum signatures run in plain EVM code, without precompiles. That costs gas well beyond the canonical limit.
Zero-knowledge proofs
Verifying a proof in validation needs a higher budget. Stake buys it.
Rules of your own
Trust a contract you audited. Swap hot Solidity for a Rust binary. Track reputation differently. It is your mempool.
Backwards compatibility with the ERC-4337 ecosystem
ERC-8421 keeps what ERC-7562 made possible. The contract logic carries over. The interfaces around it change.
| ERC-4337 | Frame Transactions |
|---|---|
| validateUserOp on the account | self_verify or only_verify frame |
| validatePaymasterUserOp | pay frame |
| initCode | deploy frame |
| Paymaster writes during validation | pre_verify frame, bound to the approving frame |
| EntryPoint and handleOps bundles | No EntryPoint. The transaction is validated and relayed largely as it is. |
| One ruleset, ERC-7562 | Several rulesets: the canonical one, the standard one, and any alternative, each identified by a topic. One transaction may sit in several. |
| Stake, reputation | Same ideas. Stake sits in a Staking Registry and is never slashed. Reputation is tracked per entity address and per mempool. |
ERC-8421 introduces no consensus change, requires no change to EIP-8141 or the FOCIL rules of EIP-7805, and does not modify ERC-4337 or ERC-7562.
Federated mempools, one open submission market
Nobody in the world has to agree on one set of rules. Nodes opt into the mempools they want to serve.
Reaching the mempool is only the first step
The alternative mempool rules partially satisfy the FOCIL profile for Frame Transactions. A transaction that complies may get better censorship resistance in an adversarial environment. FOCIL forces inclusion unless the transaction is invalid, so attesters need to know whether it is valid.
A mempool sidecar you can run today
The mempool sidecar is a TypeScript node for EIP-8141. It exposes eth_sendFrameTransaction, validates and simulates transactions against an execution client, relays them on-chain, and gossips them to other sidecars over libp2p.
There is no EntryPoint and no eth_sendUserOperation. It needs an execution client that implements EIP-8141. Today that is the eip8141-tracer branch of ethrex.
tx 0x9f3c…e1a7 token paymaster
pass PREFIX-010 [only_verify, pre_verify, pay]
pass SIGNATURE-010 secp256k1 valid
pass STAKING-010 payer staked
pass STORAGE-021 token slot keyed by sender
pass BUDGET-010 81,400 of 1,000,000
pass SOLVENCY-010 reserved 0.0021 ETH
fail LOCAL-010 payer is another tx's sender
→ rejected, no reputation change for peer