# Block gas limit can be hit due to loop depth

MANTRA farm-manager claim() runs nested P*F*E loops over positions, farms and epochs, exceeding block gas limit and bricking claim/close_position.

- Payout: Audit contest
- Severity: high
- Program: MANTRA
- Credited: carrotsmuggler
- Disclosed: 2025-03-31
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2024-11-mantra-dex#h-04
- Library page: https://bugbountylibrary.com/r/c4%3A2024-11-mantra-dex%3AH-04
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:dos

**Target:** farm-manager claim/close_position reward calculation (CosmWasm contract)
**Root cause:** claim() iterates positions, then farms per lp_denom, then every epoch since first deposit in nested loops of order P*F*E with no batching or checkpoint accounting.
**Steps:**
1. User opens up to 100 positions across many lp_denoms (P up to MAX_ITEMS_LIMIT=100).
2. Each lp_denom has up to max_concurrent_farms (~10) farms (F).
3. First claim has start_from_epoch at first deposit, so epoch loop runs E (~100s) iterations.
4. Call `claim` -> nested P*F*E ~ 100_000 iterations plus reward math and transfers.
5. Transaction exceeds block gas limit and reverts; same path runs in `close_position`, forcing emergency withdraw.
**How found:** Code reading of claim() in commands.rs, tracing the three nested loops (positions -> farms -> epochs) and reasoning about worst-case iteration count versus block gas limit.
**Exploitation:** Not an attacker-driven exploit; a user with many long-lived positions across farms triggers OOG on their own claim/close_position, losing rewards and deposits via emergency withdraw.
**Insight:** When auditing reward-claim loops, count the multiplicative nesting depth (positions x farms x epochs) and check whether epoch iteration is bounded by first-deposit time; unbounded epoch loops with no batching are a DoS vector even without an attacker.