# isValidRefinance will approve invalid refinances and reject valid refinances due to buggy math

AstariaRouter.isValidRefinance inverted the rate comparison, approving refinances with higher rates and rejecting genuinely improved ones during lien buyouts.

- Payout: Contest reward
- Severity: high
- Program: Astaria
- Credited: hansfriese
- Disclosed: 2022-11-07
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-astaria-judging/issues/21
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-37
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:business-logic

**Target:** AstariaRouter.isValidRefinance / LienToken.buyoutLien
**Root cause:** minNewRate is computed as lien.rate - minInterestBPS but the check uses >= instead of <=, so it validates rate increases rather than decreases.
**Steps:**
1. Call LienToken.buyoutLien() with new lien terms.
2. buyoutLien calls ASTARIA_ROUTER.isValidRefinance(lienData[lienId], ld).
3. isValidRefinance computes minNewRate = lien.rate - minInterestBPS and returns newLien.rate >= minNewRate.
4. Submit a new rate higher than the original: passes validation despite being worse terms.
5. Submit a new rate decreased by >0.5%: fails validation despite being the intended improvement.
**How found:** Manual review comparing the documented refinance rule (rate must decrease >0.5%) against the implementation, spotting the min/max naming and >= direction mismatch.
**Exploitation:** A borrower or buyer submits refinance terms with a higher interest rate; the inverted comparison accepts them as valid, locking in worse terms while legitimate rate improvements are blocked.
**Insight:** When a spec defines a directional threshold (decrease/increase), diff the comparison operator and variable naming against the doc; inverted inequalities in validation helpers are a recurring high-severity class in lending/refinance logic.