# Unupdated totalBorrow After BigBang Liquidation

BigBang liquidation reduces userBorrowPart but never decrements global totalBorrow, corrupting all subsequent interest and debt accounting.

- Payout: Contest reward
- Severity: high
- Program: Tapioca
- Credited: bin2chen
- Disclosed: 2024-02-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-02-tapioca-judging/issues/49
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-4
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** BigBang/SGL market liquidation (BBLiquidation.sol)
**Root cause:** _updateBorrowAndCollateralShare decrements userBorrowPart[user] and userCollateralShare[user], and _liquidateUser updates totalCollateralShare, but totalBorrow.elastic/base are never reduced after burning the debt.
**Steps:**
1. Call liquidate on a BigBang market for an underwater user with a liquidator receiver.
2. _updateBorrowAndCollateralShare computes borrowPart and does `userBorrowPart[user] -= borrowPart` without touching totalBorrow.
3. _liquidateUser burns borrowAmount USDO and updates totalCollateralShare only.
4. Observe totalBorrow.elastic/base still reflect pre-liquidation debt; subsequent toElastic/toBase interest math is inflated.
**How found:** Code review of the liquidation path: traced every state mutation in _liquidateUser and _updateBorrowAndCollateralShare and noticed totalCollateralShare was updated but totalBorrow was not, unlike normal repay paths.
**Insight:** When auditing liquidation/repay forks, diff the state mutations against the standard repay function; global aggregates (totalBorrow, totalCollateralShare) are easy to miss in a separate liquidation module.