DeFi risk case study
Reading an On-Chain Lending Health Factor
A health factor compresses several moving inputs into one number. This case unpacks the number so a reader can see which assumptions create the apparent buffer.
Evidence boundaries are reviewed against the primary references listed at the end. Read our editorial methodology.
The situation
Start with the facts available to the reader
A fictional lending dashboard shows $20,000 of collateral, $12,000 of debt, an 80% weighted liquidation threshold, and a health factor of about 1.33. The collateral then falls by 15% while the debt value is unchanged. The displayed health factor falls to about 1.13.
A user asks whether the position is safe. That question cannot be answered from a single threshold or a universal rule. The useful task is to reconstruct the metric, test sensitivity to its inputs, and identify risks that the number does not capture, including oracle behavior, market liquidity, transaction execution, and protocol-specific liquidation rules.
The figures are simplified and hypothetical. They illustrate dashboard reading, not a recommended collateral ratio, borrowing strategy, or instruction to modify a position.
Evidence sheet
What each observation can and cannot support
The last column is deliberately strict. It prevents a useful signal from being stretched into a conclusion that needs different evidence.
| Observation | Useful for | Not proof of |
|---|---|---|
| Collateral value is displayed as $20,000. | Identifying the current oracle-valued assets included in the account calculation. | The amount that could be sold instantly without price impact, fees, or failed execution. |
| Debt value is displayed as $12,000. | Reconstructing the denominator and checking which borrowed assets and accrued interest are included. | A fixed future liability, because interest and the debt asset's reference price can change. |
| The weighted liquidation threshold is 80%. | Understanding how protocol parameters convert eligible collateral into liquidation capacity. | An 80% probability, an 80% loss limit, or a promise that liquidation will occur at exactly one market price. |
| Health factor declines from about 1.33 to 1.13. | Showing that the modeled buffer has narrowed after the collateral price change. | How much time remains before liquidation or the final economic loss if liquidation occurs. |
Analysis path
Work from mechanism to conclusion
Reconstruct the metric before interpreting it
Which values and protocol parameters produce the displayed number?A common health-factor form compares collateral value adjusted by a liquidation threshold with debt value. In the simplified starting state, $20,000 multiplied by 80% produces $16,000 of adjusted collateral; dividing by $12,000 of debt gives about 1.33. After a 15% collateral decline, $17,000 multiplied by 80% gives $13,600; divided by $12,000, the result is about 1.13.
Reconstruction catches category errors. The liquidation threshold is not the same as loan-to-value, and an account with multiple collateral assets may use a weighted threshold. A dashboard may also treat supplied, borrowed, isolated, efficiency-mode, or non-collateral assets differently.
Test more than one moving input
What happens if collateral falls, debt rises, or both move together?The first sensitivity test changes collateral price while holding debt constant. A second test should consider accrued borrowing interest or a rise in the debt asset's reference value. Correlated assets can sometimes move together, but assuming correlation will persist is itself a risk assumption.
The point is not to forecast a particular shock. It is to identify which input has the most influence and how quickly a modest change can consume the displayed buffer. A health factor near a threshold is a ratio, not a countdown timer.
Inspect the oracle and update path
Which price reaches the protocol, and when?The account calculation depends on the protocol's accepted price source and update rules. A wallet screen, exchange ticker, and on-chain oracle may show different values at the same moment because they use different markets, aggregation methods, delays, or safeguards.
A reader should locate the protocol's oracle documentation and parameter definitions. A displayed health factor is only as current as the inputs used to compute it. This does not mean an oracle is necessarily wrong; it means the data path is part of the interpretation.
Separate eligibility from execution outcome
What does crossing below the threshold actually trigger?In many overcollateralized lending systems, a health factor below one makes a position eligible for liquidation. It does not guarantee an instantaneous, complete, or single-price transaction. Liquidator incentives, close factors, network conditions, available liquidity, slippage, and protocol rules affect execution.
Liquidation eligibility and realized economic loss are therefore different concepts. The dashboard can identify a rule boundary, while the eventual outcome depends on the mechanism and market conditions around the transaction.
Reasoned conclusion
Say what is supported, then preserve uncertainty
The position's modeled buffer has materially narrowed: the simplified health factor moves from about 1.33 to about 1.13 after the collateral decline. The number communicates proximity to a protocol-defined liquidation boundary under current inputs. It does not justify calling the position safe, nor does it predict the time or final price of liquidation.
A complete reading records the formula, asset-level inputs, weighted thresholds, debt accrual, oracle source, liquidation rules, and available liquidity. That evidence allows a reader to explain why the metric changed without turning a dashboard ratio into personalized risk advice.
Claim boundaries
Keep the finding inside the evidence
This method can show
- How current oracle-valued collateral compares with current debt under protocol parameters.
- Which price or debt changes would narrow the modeled buffer.
- Whether a protocol-defined liquidation eligibility threshold has been crossed.
- Which assets and thresholds contribute most to the account-level ratio.
This method cannot show
- A universal safe borrowing level that applies to every user or market.
- The exact time, execution price, or total loss of a future liquidation.
- Tradable market depth from an oracle price alone.
- Smart-contract, governance, bridge, custody, or operational risk outside the ratio.
Reader checklist
Repeat this process on another document
- Find the exact formula and identify every included collateral and debt asset.
- Distinguish loan-to-value, liquidation threshold, and health factor.
- Recalculate the ratio under at least two independent input changes.
- Check the oracle source, update method, and protocol-specific liquidation rules.
- State what the metric omits before drawing a risk conclusion.
Vocabulary
Review the terms used in this case
FAQ
Questions this case should leave you asking
Is a health factor above one always safe?
No. Above one generally indicates that the position has not crossed that protocol's liquidation threshold under current inputs. It does not remove price, oracle, liquidity, contract, or operational risk.
Is the liquidation threshold the same as loan-to-value?
Not necessarily. Loan-to-value commonly describes borrowing capacity, while the liquidation threshold describes when collateral becomes insufficient under protocol rules. Exact definitions vary by protocol.
Why does the oracle matter if I can see an exchange price?
The protocol acts on its accepted on-chain input, which may use different venues, timing, aggregation, or safeguards from the exchange screen you are viewing.
Primary references
Verify the concepts at their source
These materials support the framework and terminology. They do not describe the fictional scenario above.