# Liquidation transactions can potentially fail for all markets

BigBang.liquidate() calls Market.updateExchangeRate which reverts when oracle rate is zero, blocking all liquidations and risking protocol insolvency.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: zzzitron
- Disclosed: 2023-11-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-07-tapioca-findings/issues/1021
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-37
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:dos vuln:liquidation vuln:oracle-manipulation

**Target:** BigBang/Singularity market liquidation and Market.updateExchangeRate oracle path
**Root cause:** Market.updateExchangeRate reverts when the fetched rate is not greater than 0, but liquidation flow calls it unconditionally despite the design intent that oracle failures should not block liquidations.
**Steps:**
1. Call `BigBang.liquidate()` on an underwater position.
2. Liquidation proceeds to `Market.updateExchangeRate` (BigBang.sol L316).
3. Oracle returns rate <= 0, triggering revert at Market.sol L344.
4. Entire liquidation tx reverts; collateral cannot be seized.
**How found:** Code reading: noticed the comment at BigBang.sol L315 stating oracle failure must still allow liquidations, then traced the call into Market.updateExchangeRate and found the revert-on-zero-rate condition contradicting that intent.
**Escalation:** Applies to all markets (Singularity, BigBang) since revert lives in shared Market.sol base contract, so a bad oracle reading blocks liquidations protocol-wide, pushing insolvency.
**Insight:** When a code comment promises graceful oracle degradation, trace every downstream call in that path for hard reverts on oracle output—shared base-contract reverts propagate to all inheriting markets.