# Precision differences when calculating userCollateralRatioMantissa causes major issues for some token pairs

userCollateralRatioMantissa divides raw debt by raw collateral without normalizing decimals, so mixed-precision pairs like USDC/SHIB yield zero ratio and become unliquidatable.

- Payout: Contest reward
- Severity: high
- Program: Surge
- Credited: 0x52
- Disclosed: 2023-02-18
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-02-surge-judging/issues/122
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-surge%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:liquidation vuln:precision-loss

**Target:** Pool.sol borrow/liquidate collateral ratio calculation
**Root cause:** userCollateralRatioMantissa divides debt value in loan-token precision by collateral balance in collateral-token precision without normalizing both to 18 decimals, so large precision gaps truncate the ratio to zero.
**Steps:**
1. Pick a pair with mismatched decimals, e.g. USDC (6) collateral vs SHIB (18) loan.
2. User deposits 100,001e18 SHIB collateral and borrows 1e6 USDC.
3. Compute ratio: `1e6 * 1e18 / 100,001e18 = 0`.
4. Observe ratio returns 0, so liquidation logic cannot process the position.
**How found:** Code reading of the ratio formula in Pool.sol; noticed debt and collateral left in native precision and reasoned about extreme decimal pairs like USDC/SHIB producing a zero ratio.
**Insight:** When auditing ratio/health-factor math, check whether numerator and denominator are normalized to a common precision; construct extreme-decimal pairs (6 vs 18) to force truncation to zero and test liquidation invariants.