# Incorrect affordability checks admits invalid transactions allowing txpool and block building DoS

Monad txpool admits EIP-1559 txs checking only base fee, but proposal-time validation uses full gas bid, letting cheap high-tip txs stuff pools and starve block building.

- Payout: Contest reward
- Severity: high
- Program: Monad
- Credited: oct0pwn
- Disclosed: 2026-02-26
- Write-up quality: 8/10
- Original: https://code4rena.com/reports/2025-09-monad#h-03
- Library page: https://bugbountylibrary.com/r/c4%3A2025-09-monad%3AH-03
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:rust technique:source-review vuln:business-logic vuln:dos vuln:misconfiguration

**Target:** Ethereum-compatible txpool and block policy (Rust)
**Root cause:** Insert-time affordability gate compares balance only against base_fee × gas_limit, while proposal-time try_add_transaction enforces the full EIP-1559 gas bid (max_fee × gas_limit). Txs passing insert but failing proposal are returned to tracked pool instead of evicted, and are re-sampled each proposal.
**Steps:**
1. Fund ~16k addresses with ~0.0021 MON each (~34 MON total) to cover base_fee × 21k gas at 100 gwei.
2. For each funded address and each of 200 leaders, submit one EIP-1559 tx with gas_bid = base_fee + high tip but balance insufficient for full bid.
3. insert_txs admits them via base-fee-only check (`balance >= base_fee * gas_limit`).
4. Sequencer samples up to tx_limit addresses; try_add_transaction rejects on full-bid affordability; sampled addresses skipped, txs remain in tracked pool.
5. Repeat across proposals: pool stays stuffed, blocks build empty, other txs cannot be admitted.
**How found:** Code review comparing insert-time affordability check in txpool mod.rs (base_fee only) against proposal-time compute_txn_max_gas_cost and try_add_transaction (full bid), noticing the mismatch and that failed txs are returned to tracked rather than evicted.
**Exploitation:** Attacker pre-funds many addresses with just enough for base fee, submits high-tip txs that pass insert-time gate but are unaffordable at full bid. These are never included (no fee paid) yet occupy tracked pool capacity and are re-selected each proposal, causing empty blocks and txpool admission starvation across all 200 leaders via forwarding or direct submission.
**Escalation:** Scaling to all 200 leaders via tx forwarding or direct submission turns per-leader stuffing into network-wide block building and txpool DoS.
**Insight:** When a system has separate admission and execution validation paths, diff the exact cost/limit formulas each uses; any field (like priority fee) checked at one stage but not the other creates a free-to-hold resource that can be used to stuff bounded pools.