# Approved spender can spend too many tokens

Rebasing ibBTC token's approve() stores shares while transferFrom() uses rebalanced amounts, letting an approved spender drain more tokens as pricePerShare grows.

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

**Target:** rebasing ibBTC ERC20 token contract (approve/transferFrom)
**Root cause:** approve() was not overridden and stores allowance in internal shares, while transfer(From) operates on rebalanced token amounts; the two units diverge as pricePerShare increases.
**Steps:**
1. Owner calls `approve(spender, X)` — X is stored as shares in `_allowances`.
2. As pricePerShare grows, the rebalanced value of X shares exceeds X tokens.
3. Spender calls `transferFrom(owner, recipient, amount)` where amount is interpreted in rebalanced units, allowing transfer of more than X tokens.
4. Repeat/observe allowance effectively growing with pricePerShare.
**How found:** Code review comparing the units used by approve (shares) versus transferFrom (rebalanced amount), spotting the missing override and unit mismatch.
**Exploitation:** An approved spender waits for pricePerShare to rise, then calls transferFrom to move a rebalanced amount larger than the nominal approved value, extracting extra tokens from the owner's balance.
**Insight:** In rebasing/share-based tokens, audit every ERC20 entrypoint for unit consistency: allowance, balance, and transfer amounts must all use the same unit or allowances silently inflate with the exchange rate.