# Aave's share tokens are rebasing breaking current strategy code

Sublime's Aave strategy caches rebasing aToken deposits as static shares but computes withdrawals against a rebasing total, so users lose accrued interest and collateral is undervalued.

- Payout: Audit contest
- Severity: high
- Program: Sublime
- Found by: cmichel
- Disclosed: 2022-02-14
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2021-12-sublime-findings/issues/137
- Library page: https://bugbountylibrary.com/r/c4%3A2021-12-sublime%3AH-05
- 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:share-inflation

**Target:** AaveYield strategy / SavingsAccount share accounting
**Root cause:** Deposits cache a static balanceInShares from aToken diff, but getTokensForShares divides by the rebasing IERC20(aToken).balanceOf(this), so accrued interest is never attributed to users.
**Steps:**
1. Deposit 1000 DAI via SavingsAccount.deposit; _deposit returns 1000 aDAI cached in balanceInShares[user][dai][aave]
2. Aave interest accrues; contract aToken balance rebases to 1200
3. User withdraws 1000 shares; AaveYield.unlockTokens withdraws only 1000 DAI
4. getTokensForShares(1000) computes 1200*1000/1200 = 1000, ignoring the 200 interest
**How found:** Code reading of AaveYield.lockTokens and getTokensForShares; noticed sharesReceived is static while the denominator IERC20(aToken).balanceOf(this) rebases, creating a mismatch.
**Exploitation:** No attacker action; accounting flaw causes users to forfeit accrued yield and pool collateral to be measured without interest, enabling early liquidations.
**Insight:** When a strategy caches shares from a rebasing token (aToken/cToken), the total-supply denominator must also be non-rebasing (scaledBalanceOf) or wrapped; mixing static user shares with a rebasing total silently drops yield.