# HPB may be incorrectly bankrupt due to use of unscaled value in `_forgiveBadDebt`

Ajna's _forgiveBadDebt uses unscaled depositRemaining in bankruptcy check, wrongly marking HPB bankrupt and zeroing user LPs.

- Payout: Contest reward
- Severity: medium
- Program: Ajna
- Credited: 0xkaden
- Disclosed: 2023-09-26
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-09-ajna-judging/issues/25
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-09-ajna%3AM-3
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** SettlerActions.sol _forgiveBadDebt bankruptcy check
**Root cause:** depositRemaining is an unscaled value but is compared against scaled bucketLP in the bankruptcy threshold check, off by the bucket's scale factor.
**Steps:**
1. Call forgiveBadDebt path in SettlerActions._forgiveBadDebt on an HPB bucket with a scale factor > 1
2. Observe check `depositRemaining * WAD + collateral * price <= bucketLP` uses unscaled depositRemaining
3. With small unscaled depositRemaining the inequality holds though scaled value would not
4. Bucket marked bankrupt: lps=0, bankruptcyTime set, user LPs wiped
**How found:** Code review of the bankruptcy check in _forgiveBadDebt, noticing depositRemaining is unscaled while bucketLP is scaled, making the comparison off by the scale factor.
**Exploitation:** Trigger forgiveBadDebt on a bucket with scale > 1 where unscaled depositRemaining is small enough to satisfy the bankruptcy inequality; bucket is marked bankrupt and all LP becomes unclaimable, causing user fund loss.
**Insight:** In scaled/unscaled accounting systems, audit every comparison mixing a raw amount with a scaled LP/share value; the scale factor silently biases threshold checks toward false positives.