A borrowing limit is not a spending target. It is a boundary defined by a protocol's rules and assumptions. When the value of collateral or debt changes, the distance to that boundary can change too. A position that looks comfortable at entry may require attention long before the borrower planned to repay it.
This guide explains collateral, borrowing costs, and liquidation through hypothetical examples. It does not identify a safe loan size or recommend leverage. The important skill is understanding how a position behaves under different conditions and what actions remain possible when those conditions become unfavorable.
Separate supplying from borrowing
Supplying assets to a lending market and borrowing against collateral are related activities but create different exposures. A supplier needs to understand how the market uses assets and under what conditions withdrawals are available. A borrower also takes on debt and must understand how that debt interacts with pledged collateral.
Do not assume that supplying automatically means borrowing, or that every supplied asset is automatically enabled as collateral. Review the exact settings and market rules. Keep a simple record of assets supplied, assets designated as collateral, assets borrowed, and any receipt tokens held. A single dashboard total can conceal these important distinctions.
Loan-to-value and liquidation threshold differ
Loan-to-value compares borrowed value with collateral value. A market may have one parameter governing how much a new position can borrow and another governing when an existing position becomes eligible for liquidation. These should not be treated as interchangeable simply because both are expressed as percentages.
Read the definitions used by the exact protocol and version. Also check how multiple collateral assets are combined and whether special market modes alter the calculation. A generic explainer cannot replace the rules for a specific deployment. Record the parameters and the date you checked them, because an old screenshot is not evidence that a rule still applies.
Work through a health-factor example
Aave describes health factor as liquidation-adjusted collateral value divided by total borrowed value. In a simple single-collateral example, suppose collateral is worth $12,000, the assumed liquidation threshold is 75%, and debt is $4,500. The resulting health factor is $12,000 × 0.75 ÷ $4,500, which equals 2. These are illustrative inputs, not current settings for any listed asset.
If the collateral value falls 30% to $8,400 while debt and the assumed threshold remain unchanged, the health factor becomes 1.4. If collateral falls to $6,000, it becomes 1. On Aave, a health factor below 1 makes a position eligible for liquidation. A value above that line measures a buffer under the current inputs, not immunity from future losses.
Stress the debt side too
The collateral price is not the only moving part. Borrowed value can increase through accrued interest or changes in the borrowed asset's reference price. If the hypothetical debt increases from $4,500 to $5,000, the same $8,400 of collateral at a 75% threshold gives a health factor of 1.26 rather than 1.4.
This is why a one-direction scenario is incomplete. Create separate cases for collateral depreciation, debt appreciation, higher interest, and combinations of those changes. Keep the assumptions visible. A calculation is most useful when you can explain which variables were held constant and which events would invalidate that simplification.
A liquidation is not a friendly reminder
Liquidation mechanisms are designed around the protocol's solvency rules, not the borrower's preferred schedule. A liquidator may repay eligible debt and receive collateral under the applicable terms. The precise amounts, incentives, and close-factor rules vary across systems and versions, so avoid importing a percentage from another market.
Plan as though an eligible position could be acted on before you respond. A notification service may be helpful, but it is not a contractual grace period. Your internet connection, wallet access, network congestion, and available repayment assets are separate operational dependencies. A plan that assumes every one of them works perfectly at the worst moment deserves closer examination.
Compare borrowing cost with the actual purpose
Write down why the loan exists. Is it funding an external expense, maintaining an asset exposure, or financing another position? Each purpose creates a different repayment question. A borrowed token must eventually be repaid according to the market's rules, regardless of whether the activity financed with it was successful.
For a simple cost illustration, assume $2,000 of debt with an unchanged 9% annual simple rate for 30 days. Interest would be about $14.79 using a 365-day year, before compounding and any other charges. Actual protocols may calculate interest differently, and variable rates can change. The example shows how duration belongs in the analysis; an annual figure alone does not describe the cost of a particular borrowing period.
Supplier withdrawals need a liquidity question
A lending position should not be described as a bank deposit merely because the interface resembles a savings balance. Ask how much liquidity is available for withdrawal, how much is currently borrowed, and what other restrictions may apply. Owning a claim and being able to turn that claim into the desired asset immediately are different matters.
Imagine needing funds on a fixed date. Your plan should identify whether that date is compatible with the withdrawal mechanics and a stressed liquidity scenario. If the plan requires exact availability, an uncertain exit is a material mismatch. This is a timing issue even before you consider market prices or the security of the contracts.
Model an exit before entering a loan
An exit sequence might require obtaining the borrowed asset, repaying debt, and then withdrawing collateral. Fees and balances must support each step. If the borrowed asset is not the one you naturally hold, a conversion may be needed. That introduces another market and potentially another failure point.
Prepare a written sequence using the exact asset units rather than only dollar estimates. Include a small residual debt possibility caused by ongoing interest or rounding, and establish how the interface indicates that repayment is complete. A zero-looking dashboard rounded to two decimals is not necessarily a complete technical description of the account's state.
Avoid confusing correlated assets with no risk
Borrowing one asset against a related asset can look less volatile in ordinary conditions. But the relationship between them may depend on redemption, liquidity, a wrapper, or a staking system. If that relationship breaks down, the apparent buffer can change in ways that a normal-period chart did not capture.
Write the connection explicitly. For example, explain why you expect two asset values to move together and what might stop that relationship from holding. This does not require predicting a depeg or outage. It requires acknowledging the assumption so that it can be monitored. The stablecoin hub and staking hub cover two common sources of these dependencies.
Frequently asked questions
What health factor is safe?
There is no universally safe number. Asset volatility, correlations, debt behavior, protocol parameters, and your ability to respond all matter. A buffer can be modeled under chosen scenarios, but it should not be advertised as a guarantee. Explain the scenarios and the limits of the model instead of turning one threshold into personalized advice.
Can automation remove liquidation risk?
Automation can only operate within its design, funding, permissions, and execution environment. A repayment tool may add convenience while introducing its own dependencies. Evaluate what triggers it, what assets it can access, and what happens if a transaction fails. A backup plan should not be identical to the system whose failure it is meant to address.
Conclusion: think in buffers and obligations
A complete lending analysis identifies collateral, debt, changing rates, withdrawal constraints, and the repayment path. It also shows what happens under stress. The highest permitted borrowing amount is not a substitute for that analysis.
For the health-factor definition and liquidation framework used in the example, see Aave's health factor and liquidations documentation. Continue through the lending hub and the DeFi risk checklist. Verify the actual deployment's parameters before relying on any calculation involving real assets.
Something unclear or inaccurate?
Send an editorial correction ↗
