# Too many active protections can cause the ProtectionPool reach the block gas limit

ProtectionPool loops over unbounded activeProtectionIndexes in lockCapital and _accruePremiumAndExpireProtections; stuffing protections with tiny buys can push these critical functions past the block gas limit.

- Payout: Contest reward
- Severity: high
- Program: Carapace
- Credited: ctf_sec
- Disclosed: 2023-02-01
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-carapace-judging/issues/63
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-carapace%3AH-9
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** ProtectionPool.sol (lockCapital, _accruePremiumAndExpireProtections)
**Root cause:** Both functions iterate the full unbounded activeProtectionIndexes set; no cap or batching on lockCapital, so array growth makes the loop exceed the block gas limit.
**Steps:**
1. Buy many small protections for a lending pool to grow activeProtectionIndexes.
2. Trigger lockCapital() (or _accruePremiumAndExpireProtections()) which loops over all active protections.
3. Loop cost exceeds block gas limit; transaction reverts, blocking capital locking and premium accrual/expiry.
**How found:** Code review of ProtectionPool loops over activeProtectionIndexes; recognized SWC-128 unbounded loop pattern and that any user can inflate the array with small protections.
**Exploitation:** Attacker stuffs activeProtectionIndexes with cheap small protections; when the lending pool defaults, lockCapital() reverts on gas, so buyers' deposited tokens cannot be locked and coverage fails.
**Insight:** When a protocol claims batching mitigates an unbounded loop, check every other function touching the same array — lockCapital here had no batching, and per-lending-pool scoping does not bound array size since any user can add entries.