Reading a DeFi Lending Market Before You Borrow

Borrowing rates move block to block and tell you almost nothing. What decides whether you keep your collateral is a set of parameters that barely change: the loan-to-value ceiling, the liquidation threshold, the close factor, the liquidation penalty, and who is allowed to alter any of them and how quickly. All five are published. None of them appears on the screen where you click borrow.

This is the reasoning behind our lending ranking, written so you can read any market yourself.

The five parameters that decide your worst day

Loan-to-value is the most you may borrow against a given collateral asset. The liquidation threshold sits above it and is the ratio at which your position becomes eligible for liquidation. The gap between the two is your entire margin for error: borrow to the maximum and any adverse move puts you in range immediately.

The close factor limits how much of your debt a liquidator may repay in a single event, and therefore how much collateral they may seize. A 10% close factor means a liquidation nibbles; 50% means half the position goes at once. Some protocols escalate — a normal close factor of 50% that rises to 100% once health deteriorates past a stated point, meaning a position sufficiently underwater is closed entirely rather than trimmed.

The liquidation penalty is what you pay for being liquidated, and it is expressed in two different conventions that are easy to confuse. Some protocols publish a bonus above 100% — 105% means the liquidator receives 5% more collateral than the debt they repaid, so the 5% is your loss. Others publish a penalty percentage directly. Either way the question is the same: what fraction of the seized collateral disappears, and who receives it.

That last part varies more than people expect. The incentive may go entirely to the liquidator, or be split with the protocol's treasury or a growth fund. A penalty split between a liquidator and a fund is still your money leaving; a protocol taking no share of the incentive is passing the whole amount to the party doing the work, which tends to produce faster liquidations and less bad debt.

As published in each protocol's own documentation and repositories, read 24 July 2026. Parameters are per-market and change by governance; the protocol's own documentation is the authority, and each figure is cited on the review it came from.

Who can change the rules, and how fast?

Every parameter above is a variable someone controls. The question that separates a governed protocol from one that can be altered underneath you is whether a delay stands between a decision and its execution.

A timelock is that delay. Its length is the window in which a borrower who disagrees with a change can act — repay, add collateral, or leave — before the new parameters bind. Twenty-four hours is enough to react if you are watching. Seventy-two hours is enough to react if you are not. No stated delay means a governance decision can take effect at the speed of a transaction.

Two details worth checking beyond the headline duration. First, whether an emergency path exists that bypasses the normal delay: several protocols publish tiered processes where a critical proposal executes in an hour or less, which is the correct design for stopping an exploit and also the mechanism most worth understanding before you rely on the standard delay. Second, whether the timelock addresses are published — a named contract you can inspect is a verifiable claim; the word "timelocked" on a marketing page is not.

Where a protocol publishes neither a delay nor an admin structure, treat the parameters as revisable at will. That is not automatically disqualifying; plenty of immutable-by-deployment designs deliberately have no governance at all, and a market whose liquidation fee is fixed at deployment cannot be changed by anyone, which is a stronger guarantee than any timelock. What matters is knowing which of the three you are in: governed with delay, governed without delay, or not governed at all.

What does the rate actually consist of?

The borrow rate you pay is not the rate a lender receives. Between them sits the protocol's cut, published variously as a reserve factor, an interest fee or a protocol spread — and the range is wide, from around a tenth of the interest paid up to, in one published case, a guaranteed range running as high as 100% with the protocol's own share capped at half.

Ask three questions of any lending market's fee page. What share of interest does the protocol keep? Are there origination, deposit or withdrawal fees on top — a protocol stating plainly that it charges none has disclosed something, while a page that omits the subject has not? And is there a published cap on how high the protocol's share can be set later, since an uncapped parameter is a future rate rise waiting for a governance vote.

Why utilisation explains a rate that jumped

Interest rates in these markets are set by a curve, not by a committee. The input is utilisation — what fraction of supplied assets is currently borrowed — and the curve is deliberately gentle up to a target point and steep after it. That kink exists to protect withdrawals: as the pool empties, borrowing becomes punitively expensive, which pushes borrowers to repay and lenders to supply, refilling the pool.

For a borrower, this means the rate you signed up to is a function of other people's behaviour. A market sitting comfortably below its kink is stable; one hovering just under it can double in cost within hours if a large borrower arrives. The practical habit is to look at current utilisation against the published kink before borrowing, and to treat a market already past it as one you are entering at the expensive end of the curve.

Everything here runs on a price feed

Liquidation is triggered by a number the protocol believes, and that number comes from an oracle. It follows that the oracle is not a technical detail sitting beneath the risk parameters — it is a risk parameter, and frequently the one that decides whether a liquidation was correct.

Three properties are worth reading before you trust a market with collateral:

• Where the price comes from. An aggregate of many venues is harder to move than a single market. A feed that ultimately depends on one thin on-chain pool inherits that pool's manipulability, and the cost of moving a price is the cost of attacking every position priced by it.
• How often it updates, and what forces an update. Feeds typically refresh on a heartbeat or when price moves past a deviation threshold. Between updates the protocol is working from a stale number — which can mean liquidations that fire late, or fire on a price the market has already left.
• What happens when the feed fails. Protocols differ on whether a stale or missing price pauses the market, falls back to another source, or is simply used anyway. This is usually documented, and it is the single most useful paragraph in any risk documentation.

The related design question is isolation. In a shared pool, every collateral asset is a risk to every borrower, because bad debt from one market is absorbed by the whole. In isolated markets, a failure — a manipulated price, a collateral asset collapsing — is contained to that pair, and the trade-off is thinner liquidity in each one. Protocols that let anyone create a market are necessarily isolated by design; the permissioned ones tend to pool. Neither is safer in the abstract, but the answer determines whether an asset you have never touched can cost you money.

Who absorbs bad debt?

Liquidation is meant to close a position while it is still over-collateralised. When a price gaps faster than liquidators can act, the position ends up owing more than its collateral is worth, and the shortfall has to land somewhere.

The published answers vary: a reserve or safety module funded from protocol fees, a socialisation mechanism that spreads the loss across suppliers of that asset, or a deficit carried on the protocol's books until governance decides what to do. Some protocols document this clearly; others do not address it at all, which does not mean it cannot happen to them.

For a lender rather than a borrower, this is the question that matters most, and it rarely appears in an APY comparison. Supplying to a market pays a rate; what it costs, in the tail, is a share of somebody else's liquidation gone wrong. A protocol that names the mechanism and publishes the size of the fund standing behind it has told you what that tail looks like.

The licence is part of the risk assessment

Most major lending protocols publish their code, and most publish it under a licence that is not open source. Delayed-open licences are the norm — source visible now, converting to a permissive licence on a stated future date, sometimes years out. Some carry explicit restrictions: a grant limited to education with production use prohibited, or a licence file that states in its own text that it is not open source. And a repository with no licence file at all reserves every right by default, whatever the code's visibility suggests.

This is not an ideological point. A licence determines who may fork, audit at depth, or deploy a fix — and therefore how quickly problems get found by parties other than the team. Read the LICENSE file rather than the marketing page; the gap between them in this category is consistently wide.

A checklist before you borrow

1. Find the LTV and liquidation threshold for your specific collateral, not the protocol's headline maximum.
2. Find the close factor and penalty, and note whether the penalty is expressed as a bonus above 100% or as a percentage.
3. Check who receives the liquidation incentive.
4. Find the timelock — its duration, its emergency path, and its published address.
5. Check current utilisation against the curve's kink.
6. Read the LICENSE file in the repository, not the documentation's claim about it.

What we cannot verify

Parameters are per-market and change by governance, so any table including this one is a snapshot with a date attached rather than a permanent fact. We read published documentation and repositories; we do not open positions or trigger liquidations, so the mechanics described here are documented behaviour rather than observed behaviour. And where a protocol publishes field names without values — the parameters exist in code, but the numbers are not stated anywhere public — we record that as undisclosed rather than reading values out of a contract and presenting them as the protocol's published position.

Sources

• Liquidation parameters, governance delays, fee ranges and licences as published in each protocol's own documentation and repositories, cited individually on the reviews linked above, read 24 July 2026
• Our scoring rubric for this category — Ratings Methodology

The mechanics of over-collateralised borrowing itself are covered in our guide to how DeFi lending works. This article is about reading a specific market before you use it.