# DoS Vulnerability in send_raw_deposit_transaction Allowing Unlimited Deposit Mempool Growth

Citrea sequencer's send_raw_deposit_transaction RPC accepted duplicate deposits into an unbounded VecDeque mempool, enabling memory exhaustion and blocking legitimate bridge deposits.

- Payout: Contest reward
- Severity: high
- Program: Citrea
- Credited: lian886
- Disclosed: 2025-10-21
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_citrea_jul2025.pdf#3.1.2
- Library page: https://bugbountylibrary.com/r/cantina%3Acitrea_jul2025%3A3.1.2
- Tags: domain:web3 impact:dos kind:contest platform:cantina sev:high tech:rest technique:source-review vuln:business-logic vuln:dos

**Target:** Sequencer JSON-RPC endpoint citrea_sendRawDepositTransaction (crates/sequencer/src/rpc.rs)
**Root cause:** The RPC validates deposit data against pending EVM state but never checks for duplicates or bounds the DepositDataMempool VecDeque, so identical submissions are all accepted.
**Steps:**
1. Obtain valid deposit transaction data from the Bitcoin chain.
2. Repeatedly call `citrea_sendRawDepositTransaction` with the same bytes via RPC.
3. Each call passes evm.get_call validation against the same latest-block state and is appended to accepted_deposit_txs.
4. Repeat until memory grows unbounded; with deposit_mempool_fetch_limit=10, 100k duplicates delay legit deposits ~10,000 blocks.
**How found:** Code review of the sequencer RPC: noticed validation uses pending state so duplicates all pass, and that DepositDataMempool is a plain VecDeque with no dedup or size cap, combined with the low deposit_mempool_fetch_limit.
**Exploitation:** Anyone with RPC access floods the endpoint with identical valid deposit payloads; no funds or permissions needed. Duplicates accumulate in the unbounded VecDeque, exhausting memory and starving the per-block fetch limit of 10, delaying or blocking all legitimate cross-chain deposits.
**Insight:** On sequencer/bridge RPCs, check whether admission validation is state-dependent (pending state) rather than identity-based; a mempool that validates against unchanged state will accept unlimited duplicates unless explicitly deduped or bounded.