# Mistake while checking LTV to lender accepted LTV

Inverted LTV comparison in AbraNFT _lend() lets a lender's lower accepted LTV be overridden by the borrower's higher asking LTV, stranding the lender.

- Payout: Audit contest
- Severity: high
- Program: Abracadabra Money
- Credited: catchup
- Disclosed: 2022-07-18
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-04-abranft-findings/issues/55
- Library page: https://bugbountylibrary.com/r/c4%3A2022-04-abranft%3AH-05
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:business-logic

**Target:** NFTPairWithOracle.sol _lend() LTV validation
**Root cause:** The check `params.ltvBPS >= accepted.ltvBPS` is reversed; it should require the borrower's asking LTV to be no greater than the lender's accepted LTV (`params.ltvBPS <= accepted.ltvBPS`).
**Steps:**
1. Borrower submits lend request with `params.ltvBPS = 8600` (86%).
2. Lender submits accepted offer with `accepted.ltvBPS = 8000` (80%).
3. `_lend()` evaluates `8600 >= 8000` as true and executes at 86% LTV instead of reverting.
4. Lender is bound to a loan riskier than their accepted terms.
**How found:** Code reading of the `_lend()` function against its own comment stating lender-accepted conditions must be at least as good as the borrower's ask; the comparison direction contradicted the documented intent.
**Exploitation:** A borrower sets a high asking LTV; a lender whose accepted LTV is lower still gets matched because the comparison is inverted, forcing the lender into a position beyond their risk tolerance.
**Insight:** When a function's comment states an ordering invariant, verify the comparison operator matches the stated direction — inverted inequalities in bid/ask matching logic silently bind the wrong party.