# Sybil on withdrawal requests can allow leverage factor manipulation with flashloans

Withdrawal requests don't lock STokens, so one deposit can be re-requested across many addresses, inflating leverage factor and gaming premiums via flashloans.

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

**Target:** ProtectionPool withdrawal request / SToken accounting
**Root cause:** requestWithdraw only checks the caller's SToken balance without locking or committing those tokens, so the same STokens can back withdrawal requests from multiple addresses.
**Steps:**
1. Deposit 10k USDC, receive 10k STokens.
2. Call `requestWithdraw()` to register a withdrawal request.
3. Transfer the same STokens to a second address and call `requestWithdraw()` again; repeat across ~10 addresses.
4. Wait ~1 cycle for requests to mature.
5. Take a 100k USDC flashloan, deposit via the 10 addresses, buy protection at the inflated leverageFactor-discounted premium, then withdraw all in the same transaction and repay the flashloan.
**How found:** Code review of the withdrawal request path: noticed balance is checked at request time but tokens are neither locked nor committed, implying the same balance can be reused across addresses.
**Exploitation:** Attacker reuses one SToken balance across many addresses to multiply pending withdrawal capacity, then in a single transaction flashloans capital, deposits through those addresses to spike leverageFactor, purchases protection at a cheaper premium, and withdraws everything to repay the loan.
**Escalation:** Chained with HIGH-02 to potentially drain the protection pool on lending pool default; also DoS by pushing leverage factor very high.
**Insight:** When a request/queue system checks a balance but doesn't escrow or lock the tokens, test whether the same balance can be replayed across multiple addresses to multiply queued capacity.