# P can be updated to zero which can cause a DOS when liquidating troves

Stability Pool product P can round to zero across successive small liquidations, tripping assert(newP>0) and reverting liquidations, blocking bad-debt clearing.

- Payout: Contest reward
- Severity: medium
- Program: Ethos Reserve
- Credited: koxuan
- Disclosed: 2023-05-02
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-02-ethos-findings/issues/338
- Library page: https://bugbountylibrary.com/r/c4%3A2023-02-ethos%3AM-10
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:dos vuln:precision-loss

**Target:** StabilityPool _updateRewardSumAndProduct liquidation accounting
**Root cause:** SCALE_FACTOR of 1e9 is too small; repeated small newProductFactors multiply P down until even the scale-up branch yields a value below DECIMAL_PRECISION, producing zero.
**Steps:**
1. Liquidation 1: newProductFactor=1e2, P=1e18*1e2*1e9/1e18=1e11
2. Liquidation 2: newProductFactor=1e3, P=1e11*1e3*1e9/1e18=1e5
3. Liquidation 3: newProductFactor=1e3, P=1e5*1e3*1e9/1e18=1e17 < 1e18, so P=0
4. Next liquidation calls _updateRewardSumAndProduct, hits `assert(newP > 0)` and reverts
**How found:** Code-reading of _updateRewardSumAndProduct's assert(newP>0) and SCALE_FACTOR branch; noticed 1e9 scaling insufficient to keep P above DECIMAL_PRECISION under repeated small product factors.
**Exploitation:** Attacker triggers a sequence of small liquidations to drive P to zero; subsequent liquidations revert, preventing bad debt from being cleared and risking protocol insolvency.
**Insight:** When a fixed-point accumulator has a scale-up branch guarded by a threshold, test whether repeated minimal increments can still underflow past the precision floor before the scale-up applies; the assert then becomes a DoS.