# VaderReserve does not support paying IL protection out to more than one address, resulting in locked funds

VaderReserve whitelists only one router for IL protection payouts, so LPs on the other router's pool revert on withdrawal, locking all liquidity permanently.

- Payout: Audit contest
- Severity: high
- Program: Vader Protocol
- Found by: TomFrenchBlockchain
- Disclosed: 2022-02-10
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-11-vader-findings/issues/37
- Library page: https://bugbountylibrary.com/r/c4%3A2021-11-vader%3AH-07
- Tags: area:web3 domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** VaderReserve / VaderRouter IL protection payout path
**Root cause:** VaderReserve stores a single allowed router address for claiming IL protection; both VaderRouter and VaderRouterV2 call it, but only one can be whitelisted and governance cannot update it.
**Steps:**
1. Deploy VaderPool and VaderPoolV2 with their respective routers.
2. VaderReserve whitelists only one router address.
3. LP on the non-whitelisted router calls removeLiquidity, which invokes VaderReserve for IL protection.
4. Reserve call reverts, blocking liquidity removal permanently.
**How found:** Code reading of VaderRouter/VaderRouterV2 calls into VaderReserve and noticing the reserve only permits a single router to claim IL protection.
**Insight:** When two contract versions coexist and both call a shared payout module, check whether that module's whitelist/state can accommodate both; single-slot configs become permanent lockups if ungovernable.
