# L1->L2 token deposits can be DoS’ed by purposefully providing a large data field in MsgInitiateTokenDeposit

Unbounded data field in MsgInitiateTokenDeposit lets attacker create an L2 MsgFinalizeTokenDeposit too large to relay, halting all subsequent L1->L2 deposits.

- Payout: Contest reward
- Severity: high
- Program: Initia
- Credited: RadiantLabs
- Disclosed: 2025-04-10
- Write-up quality: 7/10
- Original: https://code4rena.com/reports/2025-01-initia-rollup-modules#h-02
- Library page: https://bugbountylibrary.com/r/c4%3A2025-01-initia-rollup-modules%3AH-02
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high technique:source-review vuln:business-logic vuln:dos

**Target:** Cosmos L1/L2 bridge (ophost/opchild) deposit relay
**Root cause:** MsgInitiateTokenDeposit's data field is unrestricted in size; when relayed, the resulting MsgFinalizeTokenDeposit (with extra fields) can exceed L2 RPC/mempool tx size limits, and strict sequence ordering blocks all later deposits.
**Steps:**
1. Craft MsgInitiateTokenDeposit with data ~1MB (below L1 RPC/mempool limits) via `initiad tx ophost initiate-token-deposit 1 <to> 1uinit <dataLen>`
2. Broadcast on L1; tx accepted (bisect size: 749667 ok, 749668 rejected by RPC)
3. Executor relays to L2 as MsgFinalizeTokenDeposit; L2 rejects with `http: request body too large`
4. Subsequent deposits queue behind the stuck sequence and cannot finalize
**How found:** Noticed strict sequence check in FinalizeTokenDeposit and compared field sets of MsgInitiateTokenDeposit vs MsgFinalizeTokenDeposit, hypothesizing the extra BaseDenom field plus unrestricted data could push relayed message over L2 size limits.
**Exploitation:** Attacker submits a deposit with data sized just under L1 limits but over L2 limits; the off-chain executor's relay tx fails simulation/size check, and because FinalizeTokenDeposit enforces strict sequence ordering, all later L1->L2 deposits are blocked.
**Escalation:** Attacker as validator can bypass RPC limit via block proposal, forcing mempool maxTxBytes (consensus param) coordination to mitigate; DoS persists during volatile markets causing user fund loss.
**Insight:** When a bridge relays a message with a different schema than the source, compare field sizes and per-chain tx/RPC limits: a payload valid on L1 can exceed L2 limits, and strict sequence ordering turns one stuck message into a full channel DoS.