# Broken safety cap in liquidate.rs causes permanent DoS of liquidation engine during market crashes, leading to insolvency.

Safety cap of 1e26 in Jupiter Lend's liquidate.rs exceeds TickMath MAX_RATIOX48 bound, so debt_per_col in [4.62e25,1e26] reverts liquidations and freezes vault operations.

- Payout: Contest reward
- Severity: medium
- Program: Jupiter Lend
- Credited: ranzo
- Disclosed: 2026-07-11
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2026-02-jupiter-lend#m-01
- Library page: https://bugbountylibrary.com/r/c4%3A2026-02-jupiter-lend%3AM-01
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** Solana vault program (liquidate.rs / operate.rs)
**Root cause:** The debt_per_col/exchange_rate cap of 1e26 was derived from the inverse raw_col_per_debt path, but the liquidation_ratio path multiplies by 2^48/1e15 before applying the threshold, so values above ~4.62e25 exceed TickMath::MAX_RATIOX48 and revert.
**Steps:**
1. Set vault LT=900, LML=950.
2. Drive debt_per_col into [4.62e25, 1e26], e.g. 7e25 via price divergence.
3. Cap at 1e26 does not trigger.
4. liquidation_ratio = 7e25 * 2^48 / 1e15 ≈ 1.97e25.
5. threshold_ratio = 1.97e25 * 900/1000 ≈ 1.77e25 > MAX_RATIOX48 (1.30e25).
6. get_tick_at_ratio reverts with LibraryTickRatioOutOfBounds; liquidations and check_if_position_safe fail.
**How found:** Developer's inline comment showed the safe-boundary math was verified for raw_col_per_debt (the inverse) at 4e25, but the cap was set at 1e26 for debt_per_col; the auditor recomputed the forward liquidation_ratio path and found it overflows MAX_RATIOX48 before the threshold multiplier is applied.
**Insight:** When a protocol caps a value to avoid precision loss, verify the cap against every downstream consumer's bound, not just the one used in the developer's comment—inverse and forward conversions have different safe limits.