# Incorrect solvency check because it multiplies collateralizationRate by share not amount when calculating liquidation threshold

Market._isSolvent multiplies collateralizationRate by collateral share instead of amount, producing an inaccurate liquidation threshold that favors the borrower.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: Koolex
- Disclosed: 2023-11-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-07-tapioca-findings/issues/1582
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-tapioca%3AH-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:liquidation

**Target:** Market.sol _isSolvent / _computeMaxBorrowableAmount solvency math
**Root cause:** The liquidation threshold multiplies collateralizationRate by collateralShare before converting to amount, while the correct LTV math (as in _computeMaxAndMinLTVInAsset) applies the rate to the converted amount. Share/amount ratio is never 1:1 due to YieldBox's +1 amount/+1e8 share offset, so results diverge.
**Steps:**
1. Borrow 745e18 via _borrow, accruing interest over 356 days so totalBorrow.elastic > base.
2. Compute solvency A using share path: `yieldBox.toAmount(collateralId, collateralShare * (EXCHANGE_RATE_PRECISION/FEE_PRECISION) * collateralizationRate, false)`.
3. Compute solvency A' using amount path: `yieldBox.toAmount(collateralId, collateralShare, false) * (EXCHANGE_RATE_PRECISION/FEE_PRECISION) * collateralizationRate`.
4. Compare A vs A' against B = borrowPart * totalBorrow.elastic * exchangeRate / totalBorrow.base; observe A != A'.
**How found:** Code review of _isSolvent noticed collateralizationRate applied to share before toAmount conversion, then cross-checked against _computeMaxAndMinLTVInAsset which correctly converts to amount first; confirmed divergence with a Foundry PoC.
**Exploitation:** Not a direct theft path described; the miscalculated threshold lets positions be considered solvent/insolvent incorrectly, enabling premature or blocked liquidations and mispriced borrow capacity.
**Insight:** When a protocol mixes rebasing shares and amounts, audit every place a rate/precision constant is applied: it must be applied after toAmount conversion, and any inconsistency between sibling functions (e.g. _isSolvent vs _computeMaxAndMinLTVInAsset) signals a bug.