# Protection sellers can bypass withdrawal delay mechanism and avoid losing funds when loans are defaulted by creating withdrawal request in each cycle

Protection sellers bypass the two-cycle withdrawal delay by re-requesting their full sToken balance each cycle, letting them exit before defaults hit.

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

**Target:** ProtectionPool.sol _requestWithdrawal
**Root cause:** _requestWithdrawal overwrites the per-cycle request amount without tracking outstanding requests across cycles, so the same sToken balance can be queued in every cycle.
**Steps:**
1. Call `requestWithdrawal(fullBalance)` in cycle N; withdrawal scheduled for cycle N+2.
2. In cycle N+1, call `requestWithdrawal(fullBalance)` again; new request scheduled for cycle N+3.
3. In cycle N+2 open period, withdraw the full balance despite the intended delay.
4. Repeat each cycle to always be able to exit before a default is realized.
**How found:** Code review of _requestWithdrawal noticed it only caches the current cycle's request amount and never accounts for prior-cycle pending requests, allowing duplicate full-balance requests.
**Exploitation:** Seller keeps full sToken balance queued for withdrawal in every cycle; when a default looms, they withdraw in the nearest open period instead of waiting the intended two cycles, avoiding loss.
**Insight:** When a delay/cooldown is implemented per-cycle or per-epoch, check whether the same balance can be re-queued in overlapping future buckets; the accounting must subtract already-pending amounts from the withdrawable balance.