# Basket.sol#auctionBurn calculates ibRatio wrong

auctionBurn computes new ibRatio from stale startSupply, ignoring tokens minted in handleFees, skewing ibRatio and leaking value from basket holders.

- Payout: Audit contest
- Severity: medium
- Program: Kuiper
- Found by: 0x0x0x
- Disclosed: 2022-05-02
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-12-defiprotocol-findings/issues/144
- Library page: https://bugbountylibrary.com/r/c4%3A2021-12-defiprotocol%3AM-03
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Basket.sol auctionBurn / ibRatio accounting
**Root cause:** newIbRatio uses startSupply captured before handleFees, but handleFees mints tokens and changes totalSupply and ibRatio; the minted amount is omitted from the denominator, so ibRatio is set too high.
**Steps:**
1. Call `auctionBurn(amount)` as the auction address.
2. Observe `startSupply = totalSupply()` is read before `handleFees(startSupply)`.
3. `handleFees` mints fee tokens, increasing totalSupply and changing ibRatio.
4. `newIbRatio = ibRatio * startSupply / (startSupply - amount)` omits the newly minted tokens, yielding an inflated ibRatio.
5. Fix: read `supply = totalSupply()` after handleFees and compute `ibRatio * (supply + amount) / supply`.
**How found:** Code reading of auctionBurn: noticed startSupply is captured before handleFees, which mints tokens, so the supply used in the ratio update is stale.
**Escalation:** Repeated auctionBurn calls compound the miscalculation, accelerating value leakage from basket token holders.
**Insight:** When a function snapshots totalSupply/ratio before an internal call that mints or burns, re-read supply after that call; fee-minting paths silently invalidate pre-call denominators.