# `burnSharesToWithdrawEarnings` burns before math, causing the share value to increase

Teller's burnSharesToWithdrawEarnings burns shares before computing exchange rate, inflating share value so withdrawers get more principal than their fair share.

- Payout: Contest reward
- Severity: high
- Program: Teller
- Credited: 0x3b
- Disclosed: 2024-04-18
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-04-teller-finance-judging/issues/19
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-04-teller-finance%3AH-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:precision-loss vuln:share-inflation

**Target:** LenderCommitmentGroup_Smart.sol burnSharesToWithdrawEarnings
**Root cause:** burnSharesToWithdrawEarnings burns the caller's shares before calling _valueOfUnderlying, so sharesExchangeRateInverse is computed against the reduced totalSupply while pool value is unchanged, inflating principal per share.
**Steps:**
1. Pool has 1000 shares and 10000 principal.
2. Alice calls burnSharesToWithdrawEarnings with 200 shares (20%).
3. Contract burns 200 shares first, totalSupply becomes 800.
4. sharesExchangeRate = 10000e18*1e36/800e18 = 1.25e37; inverse = 8e34.
5. principalTokenValueToWithdraw = 200e18*1e36/8e34 = 2500e18, i.e. 25% of pool for 20% of shares.
**How found:** Code reading of the withdrawal path: noticed shares are burned before _valueOfUnderlying/sharesExchangeRateInverse is evaluated, so the rate uses post-burn supply.
**Exploitation:** Any shareholder calls burnSharesToWithdrawEarnings; the burn-before-math ordering overpays them relative to their share, draining excess principal from the pool and pushing it toward insolvency.
**Insight:** In share-based vaults, check ordering of state mutation (burn/mint) versus exchange-rate reads; any burn before price computation inflates per-share value for the withdrawer.