# Clearinghouse.sol#claimDefaulted()

Clearinghouse.claimDefaulted calls MINTR.burnOhm without approving MINTR to spend OHM, so the function always reverts, bricking default liquidation.

- Payout: Contest reward
- Severity: high
- Program: Cooler
- Credited: Ignite
- Disclosed: 2023-08-17
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-08-cooler-judging/issues/176
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-08-cooler%3AH-3
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** Clearinghouse.sol claimDefaulted / Olympus MINTR burnOhm
**Root cause:** Clearinghouse never approves MINTR to spend its OHM, but MINTR.burnOhm calls OHM.burnFrom which requires allowance from msg.sender (Clearinghouse).
**Steps:**
1. Call `Clearinghouse.claimDefaulted(loan)` on a defaulted loan
2. Execution reaches `MINTR.burnOhm(address(this), ohmBurned)`
3. MINTR calls `OHM.burnFrom(Clearinghouse, amount)`
4. OHM checks allowance[Clearinghouse][MINTR] which is 0, reverts
5. Whole claimDefaulted reverts; default cannot be processed
**How found:** Read the last line of claimDefaulted, traced MINTR.burnOhm into OHM.burnFrom, checked deployed OHM source confirming allowance requirement, and noticed Clearinghouse never approves MINTR; also spotted MockOhm's burnFrom incorrectly burns from msg.sender, masking the bug in tests.
**Insight:** When a protocol calls a third-party minter/burner module, verify the underlying token's burnFrom/transferFrom allowance semantics against the real deployed token, and distrust mocks that inherit _burn from msg.sender instead of modeling allowance checks.