# The design of wibBTC is not fully compatible with the current Curve StableSwap pool

wibBTC's rebasing balance breaks Curve StableSwap's stored reserves, causing LPs to lose value when pricePerShare rises without pool sync.

- Payout: Audit contest
- Severity: high
- Program: BadgerDAO
- Found by: WatchPug
- Disclosed: 2021-12-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-10-badgerdao-findings/issues/65
- Library page: https://bugbountylibrary.com/r/c4%3A2021-10-badgerdao%3AH-01
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity vuln:accounting-error vuln:business-logic

**Target:** wibBTC ERC20 / Curve StableSwap pool
**Root cause:** wibBTC balances change dynamically as pricePerShare rises, but Curve StableSwap tracks reserves statically with no sync() equivalent, so stored balances diverge from actual token balances.
**Steps:**
1. Deploy Curve pool with wibBTC and wBTC, pricePerShare=1, zero liquidity
2. Alice adds 100 wibBTC + 100 wBTC, owns 100% of pool
3. Wait until ibBTC pricePerShare rises to 1.2 with no pool activity
4. Alice removes all liquidity; expects 150 wibBTC + 100 wBTC but receives only 100 wibBTC + 100 wBTC
**How found:** Reading wibBTC docs (designed for Curve StableSwap) and reasoning about how a dynamically-rebasing ERC20 interacts with a pool that only updates reserves on add/remove/swap and lacks a sync() function.
**Exploitation:** LP deposits into a Curve pool holding a rebasing token; as pricePerShare increases, the pool's recorded reserves no longer match actual balances, and on withdrawal the LP cannot redeem the accrued value, effectively stranding gains.
**Insight:** When a rebasing/yield-bearing token is paired in an AMM, check whether the pool tracks reserves statically; without a sync() or rate_multiplier mechanism, accrued value silently diverges from recorded balances and is unredeemable.