For educational purposes only; not investment advice. Investing may result in loss.
Direct answer
A DeFi lending protocol is a set of smart contracts that accepts supplied assets, makes liquidity available to borrowers, accrues interest, and enforces collateral and liquidation rules. In a common pool-based design, suppliers do not choose individual borrowers; their assets enter a market that processes supply, borrowing, repayment, and withdrawal under shared rules.
Borrowing is usually overcollateralized. A borrower supplies approved collateral before taking another asset and must remain within protocol-defined borrowing limits. This design replaces a bank’s identity and credit review with transparent collateral, price-oracle, and smart-contract rules, but it does not eliminate credit loss or guarantee repayment.
Suppliers may receive an interest-bearing token or an account balance whose value grows through an index. The displayed rate is normally variable, not a fixed deposit rate. Borrowers pay according to the market’s rate model, while suppliers receive the portion assigned by that protocol; reserve factors and incentive tokens can make the two rates differ.
A lending protocol is not risk-free custody. Withdrawals depend on available liquidity, collateral values depend on price feeds, and an unhealthy position can be liquidated without the borrower’s approval. The deployed contracts and current market parameters, not a generic description or interface screenshot, determine the actual rules.
How it works
Although implementations differ, a pool-based lending transaction usually follows this sequence:
- A supplier transfers an accepted asset to the market and receives a claim recorded as a token balance or protocol account balance.
- A borrower enables eligible assets as collateral and borrows only if the account passes the market’s collateral checks.
- Interest indexes update supplied and borrowed balances; repayment reduces debt, while withdrawals succeed only when the account remains solvent and the pool has enough liquid assets.
Utilization measures how much supplied liquidity is in use. Compound III defines it as U = B / S, where B is total base-asset borrowing and S is total base-asset supply. Other protocols account for cash, reserves, unbacked liquidity, or market-specific debt differently. Many markets use a kinked curve: rates rise gradually below a target utilization and more sharply above it to price scarce liquidity. A high rate is an incentive, not a guarantee that withdrawals will be immediately available.
Borrowing capacity and liquidation eligibility are separate checks. A borrow LTV or collateral factor limits new debt. A liquidation threshold determines when an existing position can be liquidated. In an Aave-style account, a simplified health factor is HF = (C * LT) / D, where C is collateral value, LT is the weighted liquidation threshold, and D is debt value. Liquidation becomes possible when HF < 1; other protocols may expose different account-liquidity calculations instead of a health factor.
Prices, balances, indexes, and governance-set parameters all feed these checks. Aave’s oracle contract maps each asset to a price source and can use a fallback when its primary aggregator returns a non-positive value. That implementation detail does not make every oracle failure harmless: source selection, stale or anomalous prices, decimal handling, and governance changes can still alter solvency calculations.
Example
Assume a borrower supplies 10 ETH at $3,000 each, so the collateral is worth $30,000. The market’s maximum LTV is 75%, its liquidation threshold is 80%, and the borrower takes 10,000 USDC at a current 6% variable APR. These are teaching assumptions, not current parameters for any named deployment.
The initial health factor is HF = 30,000 * 80% / 10,000 = 2.4. The position is below its maximum borrowing capacity and has a substantial liquidation buffer, but both the debt and the collateral price can change.
If ETH falls to $1,500, collateral is worth $15,000 and HF = 1.2. At $1,250, collateral is worth $12,500 and HF = 1. A further price decline or accumulated interest can make the position eligible for liquidation. In practice, oracle updates, protocol rounding, asset correlations, and parameter changes affect the exact trigger.
Suppose the protocol permits a liquidator to repay 5,000 USDC and the liquidation bonus is 5%. Ignoring fees and rounding, the liquidator receives about $5,250 of ETH. The borrower’s debt falls, but collateral is sold at a discount and does not return automatically if ETH later recovers. Borrow interest, liquidation penalties, network fees, and the opportunity cost of locked collateral all affect the outcome.
Risks
- Collateral risk: Volatile, concentrated, bridged, or depegging collateral can lose value faster than a position can be repaired or liquidated.
- Oracle risk: A stale, misconfigured, manipulated, or incorrectly scaled price can allow excess borrowing or wrongful liquidation.
- Liquidity and liquidation risk: High utilization can delay withdrawals, while congested networks and thin markets can prevent collateral from being sold fast enough to cover debt.
- Interest-rate risk: Variable borrowing costs can rise sharply, and debt continues to accrue until it is repaid or liquidated.
- Smart-contract and governance risk: Bugs, faulty upgrades, privileged roles, parameter changes, or governance attacks can change balances or market rules.
- Composability risk: Recursive borrowing, receipt-token collateral, bridges, and cross-protocol positions can transmit one failure through several systems.
Before using a market, verify the network, deployed contract addresses, supported asset, price source, borrow limit, liquidation threshold, liquidation bonus or penalty, interest-rate model, caps, reserve policy, pause and upgrade powers, and bad-debt process. Model the position after collateral declines of 20%, 40%, and 60%, and include debt growth and transaction costs. A user interface’s current APY or health factor is only a snapshot.
Supplying or borrowing on-chain carries a risk of partial or total loss. Overcollateralization reduces some default risk but cannot guarantee principal, yield, stablecoin parity, oracle correctness, contract security, or immediate liquidity.
Common misconceptions
Myth 1: Supplying is equivalent to a fixed-rate bank deposit
Lending-market rates usually change with utilization and governance parameters. Incentive-token yields can also change independently. An annualized number describes current conditions under an interface’s convention; it is not a promise for the next year.
Myth 2: Overcollateralization removes credit risk
Collateral can gap below debt value, an oracle can report an unusable price, or liquidation can fail to execute economically. The protocol can still incur bad debt even when every new loan began overcollateralized.
Myth 3: A health factor above 1 is safe
It means the account has not yet crossed that protocol’s current liquidation boundary. Price moves, accrued interest, parameter updates, and transaction latency can compress a small buffer before the borrower can act.
Myth 4: Borrowing without selling has no economic cost
The borrower pays interest, locks collateral, and accepts liquidation and smart-contract risk. If liquidation occurs, the collateral discount and fees can cost more than an earlier voluntary sale.
Related topics
Sources
- Supply Tokens - Aave (accessed: 2026-08-21)
- Borrow Tokens - Aave (accessed: 2026-08-21)
- Health Factor & Liquidations - Aave (accessed: 2026-08-21)
- Compound III Docs: Interest Rates - Compound Finance (accessed: 2026-08-21)
- Compound III Docs: Collateral & Borrowing - Compound Finance (accessed: 2026-08-21)
- AaveOracle.sol - Aave DAO (accessed: 2026-08-21)