/mempool-asymmetric-dos

name: "mempool-asymmetric-dos"
description: "L1 trigger - audits mempool / transaction pool for eviction asymmetries, replacement policy abuse, blob-pool exhaustion, and DETER-class denial of service."

Injectable Skill: Mempool Asymmetric DoS

> **L1 trigger**: `L1_PATTERN=true` AND (`txpool/` OR `mempool/` OR `tx_pool` OR `blob_pool` OR `reth-transaction-pool` detected in recon subsystem map) > **Inject Into**: `depth-network-surface` or `depth-state-trace` > **Language**: Go and Rust > **Finding prefix**: `[MP-N]` > **Status**: v0.1 draft, Round 4 exemplars pending

Orchestrator Decomposition Guide

• Section 1, 2: depth-network-surface (entry cost vs eviction cost)
• Section 3: depth-state-trace (mempool state consistency)
• Section 4: depth-edge-case (boundaries of the pool)

When This Skill Activates

Recon identifies a mempool module. Mempools are uniquely exposed: every RPC client and every peer can insert transactions. The DETER paper (USENIX CCS '21) and MemPurge follow-ups showed that most production mempools had asymmetric cost models exploitable at near-zero attacker cost.

1. The Core Asymmetry Check

The DETER insight: if an attacker can **insert** transactions with lower cost than it takes to **evict** them, they can fill the pool faster than honest transactions can reclaim space.

For each mempool:

1. Identify the **insert cost** in (gas, fee, stake, or other resource): what does the attacker pay per byte of pool space occupied? 2. Identify the **eviction threshold**: when does a new higher-fee transaction kick out a lower-fee one? 3. Identify the **eviction cost to the attacker**: to evict an honest transaction, what must the attacker's replacement pay? 4. Compute the ratio: `insert_cost / eviction_cost`. If this is much less than 1, the pool is asymmetric.

**Specific patterns**:

1a. Invalid-but-accepted transactions

Transactions that are initially accepted into the pool but will later fail validation (nonce gap, insufficient balance, invalid signature for a new state root). These cost the attacker 0 but occupy space until the validator reprocesses them.

**Check**: Look for a "pending" vs "valid" split. When is validity re-checked? Can an attacker keep an invalid tx in "pending" indefinitely?

1b. Nonce-gap attacks

A transaction with a nonce 100 above the current nonce is "futureNonce" — it occupies space waiting for the lower-nonce gap to fill. Attacker sends 99 futureNonce placeholders + never sends the gap-filler.

**Check**: Is there a cap on futureNonce slots per account? What's the eviction policy when the cap is hit? Is the cap per-account or shared?

1c. Replace-by-fee (RBF) exploitation

If an attacker can replace a low-fee tx with a slightly-higher-fee tx indefinitely, they churn pool state and cost honest reorganization work. The Bitcoin `min_relay_fee_increment` and Ethereum's 10% bump rule address this — verify the implementation.

**Check**: What is the minimum fee bump for replacement? Is it enforced cumulatively (across multiple replacements) or only per-replacement?

1d. Blob pool asymmetry (post-EIP-4844)

Blob transactions have a separate gas market (`blob_gas_price`). If the blob pool eviction uses only blob-gas-price but insertion is cheap (or the pool is not strictly separated from legacy), asymmetric exploitation is possible.

**Check**: Is the blob pool size-capped independently of the main pool? Can an attacker spam blobs to evict legacy txs or vice versa?

Tag: `[MP-ASYMMETRIC:{insert-cost}:{eviction-cost}:{ratio}]`

2. Eviction Policy Correctness

When the pool is full, which transaction gets evicted?

Patterns to check

• **Purely-fee-based**: is the "cheapest" metric fee-per-gas, fee-per-byte, or absolute fee? Fee-per-gas is standard; absolute-fee allows large low-rate transactions to displace small high-rate ones.
• **Per-sender quota**: does any single sender have a hard cap? If not, one attacker fills the pool with one-sender transactions.
• **Eviction cost consistency**: does eviction correctly update all dependent state (sender's nonce tracking, per-topic indexes, reverse-lookup maps)?
• **Deterministic ordering on ties**: when two transactions have identical fee, which gets evicted? If it's random, it's non-deterministic across nodes.

Tag: `[MP-EVICT:{policy}:{gap}]`

3. Propagation Multiplier

A mempool bug is worse if the bad transaction propagates:

1. Does the node broadcast incoming transactions before validating them? 2. Is there a per-peer rate limit on transaction gossip? 3. Does the node track which peer sent which transaction to avoid re-sending? 4. What happens if a peer floods with transactions that all fail validation? Is the peer scored down?

Tag: `[MP-PROPAGATE:{behavior}]`

4. Ordering and Priority

For transactions that do make it into blocks, the ordering algorithm affects MEV and fairness:

• **Priority-fee ordering**: verify tie-break is deterministic (hash-based, not insertion-order)
• **Fee-market simulation**: if the client simulates optimal inclusion, is the simulation correctness verified?
• **Bundle / PBS integration**: if the mempool hands off to mev-boost or builder, what's the trust boundary? Any injection attack possible?

5. Blob pool specifics (Ethereum post-4844)

1. Blob transactions are large (>128KB each). The pool must cap total blob size. 2. Blob versioning: are versioned hash checks in place? 3. Blob retrieval: if blob data is requested from peers, is there a DoS vector in the retrieval path? 4. Blob expiry: 18-day retention. What happens when blobs are pruned mid-mempool-lifetime?

Tag: `[BLOB:{concern}:{bound}]`

6. Boundary conditions

| State | Test | Expected | Observed | |---|---|---|---| | Empty pool | first tx inserted | accepted | | | Full pool, same-fee tx | new tx with equal fee | rejected (no displacement) | | | Full pool, 10% higher fee | new tx with RBF-threshold fee | old tx evicted, new accepted | | | Same-sender N txs | send