# Protection too expensive when some capital is locked

Carapace leverage ratio double-counts locked-capital protections, making protection pricing expensive or unbuyable despite a well-capitalized pool.

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

**Target:** ProtectionPool.sol leverage ratio / protection pricing
**Root cause:** Leverage ratio uses unlocked capital over totalProtections, but lockCapital() reduces totalSTokenUnderlying without reducing totalProtections, so protections that already locked capital are counted twice.
**Steps:**
1. Pool has $1.1M deposits and $1M in protection positions.
2. Late payments lock $1M via lockCapital(), reducing totalSTokenUnderlying to $100k while totalProtections stays $1M.
3. Leverage ratio becomes $100k/$1.1M ~ 0.09.
4. Protection pricing becomes very expensive or unbuyable despite pool being well-capitalized.
**How found:** Code reading of lockCapital() and the leverage ratio computation: noticed totalSTokenUnderlying is decreased but totalProtections is not, so locked-capital protections are double-counted.
**Insight:** When auditing ratio-based pricing or capacity logic, check that every state-mutating function updates all variables feeding the ratio consistently; a variable reduced in one path but not another creates double-counting.