DeFi lending: how a lending and borrowing platform works and how to build one

DeFi lending lets users deposit crypto assets to earn interest and borrow other assets against collateral, with smart contracts in place of a bank. This guide explains the mechanics that keep a lending market solvent and the steps to build one.

It covers interest rate models, collateral rules, liquidations, oracles, market designs, chain choice, security and cost. If you want to study Aave's design in detail, read the companion guide on DeFi lending protocols like Aave.

How DeFi lending and borrowing works

1. A lender deposits USDC into a market and receives a token that represents the deposit, and that token's balance or exchange rate grows as interest accrues.
2. A borrower deposits ETH as collateral and can then borrow USDC up to a limit set by the loan-to-value ratio of ETH.
3. Interest accrues every block, at a rate that depends on how much of the pool is borrowed.
4. If the price of ETH falls far enough, the collateral no longer covers the debt with a safe margin, and anyone can then liquidate the position by repaying part of the debt and taking collateral at a discount.

Platforms add extra features, such as flash loans, but the four steps above are the same on every major platform.

Major DeFi lending platforms compared

The table lists the largest DeFi lending platforms by total value locked (TVL). The figures come from DefiLlama on 19 October 2026 and change daily. DefiLlama counted about $52 billion across all lending protocols on that date.

Interest rate models

A lending pool sets its rates from utilization, the share of deposits that borrowers have taken out: U = borrows / (cash + borrows).

Most DeFi lending platforms use a kinked curve, in which the borrow rate rises slowly up to an optimal utilization point and then rises fast. The fast rise makes borrowing expensive when the pool runs short of cash, so borrowers repay, new lenders deposit and lenders can withdraw again.

if U <= U_opt:
    borrowRate = base + slope1 * U / U_opt
else:
    borrowRate = base + slope1 + slope2 * (U - U_opt) / (1 - U_opt)

supplyRate = borrowRate * U * (1 - reserveFactor)

In the formula, the base rate is the borrow rate at zero utilization. Slope1 is the rise up to the optimal point, and slope2 is the extra rise from there to 100%. Here is an example with a base rate of 0%, slope1 of 4%, slope2 of 75% and an optimal utilization of 90%. At 50% utilization, borrowers pay about 2.2% a year and lenders earn about 1.0%, because the protocol keeps 10% of the interest as its reserve factor. At 95% utilization, the borrow rate jumps to about 41.5%.

The steep second slope protects lenders. If the rate stayed low when almost all cash is borrowed, borrowers would have no reason to repay, and lenders could not withdraw their cash.

In some newer designs, the interest rate contract raises the curve by itself when utilization stays above the target for a long time, while in older designs a governance vote changes the parameters.

Collateral, health factor and liquidation

Each collateral asset has two main parameters:

• Loan-to-value (LTV) is the maximum a user can borrow against the asset when opening a position, for example 80%.
• Liquidation threshold is the level at which the position can be liquidated, for example 83%. The difference between the two numbers, 3 percentage points here, is room for the price to move before liquidation.

The health factor sums up a position in one number. It equals the collateral value, weighted by each asset's liquidation threshold, divided by the debt value:

healthFactor = Σ (collateral_i × price_i × liquidationThreshold_i) / totalDebtValue

A position with a health factor above 1 is safe, and one below 1 can be liquidated. The liquidator repays part of the debt and receives the same value in collateral plus a bonus, for example 5%.

A close factor limits how much debt one liquidation can repay. In Aave V3 the default close factor is 50%. When the health factor is at or below 0.95, Aave lets one liquidation repay all of the debt. Since version 3.3, Aave also allows a full liquidation when the remaining position is very small, so that no unprofitable dust debt is left behind.

When liquidations fail

A liquidation happens only when a liquidator earns a profit from it. Liquidations fail in three common cases:

• The collateral has too little market depth, so selling it causes slippage larger than the liquidation bonus.
• The chain is congested, and high gas fees make small liquidations unprofitable.
• The price falls faster than liquidators can act, so some positions owe more than their collateral is worth.

In each case, the position can end with bad debt, which is debt that no collateral covers. Lenders carry this loss unless a reserve or a safety module pays for it. A risk framework should set supply and borrow caps for each asset, each below the amount that liquidators could sell during a crash.

Oracles

Every borrow limit and every liquidation depends on a price feed, and oracle failures have caused some of the largest losses in DeFi. In several attacks, a person pushed up the price of a thinly traded token and then borrowed against the inflated value.

Rollups such as Arbitrum and Base order transactions through a sequencer, a single server run by the rollup operator. Lending contracts on rollups should read a sequencer uptime feed, because prices stop updating while the sequencer is down. A grace period after the sequencer restarts gives users time to repay before liquidations resume.

Pegged assets such as stablecoins and liquid staking tokens need a pricing decision: a protocol can price them at the peg or at the market price. If the protocol uses the peg price and the asset loses its peg, positions can turn into bad debt. If the protocol uses the market price, a short dip can trigger liquidations.

DeFi lending platform designs: pooled or isolated

A market for ETH, wrapped BTC and large stablecoins can work as a pool, but a market for small or new tokens needs isolated markets or tight caps.

Choosing a chain for a lending market

Liquidations on a chain depend on that chain's liquidity and price feeds. Check five points before you deploy:

• Collateral liquidity on that chain. Liquidators sell seized collateral on the same chain. A bridged token with deep liquidity on Ethereum may have a thin pool on a rollup, so it needs lower LTV and lower caps there.
• Oracle coverage. Each asset needs a reputable feed on that chain, with a known heartbeat and deviation setting.
• Sequencer and finality. Arbitrum and Base each run a single sequencer that can go offline, so liquidation logic needs a grace period for that case.
• Native or bridged assets. A bridged token depends on its bridge, and if the bridge is exploited, the token can lose its value at once. Native issuance avoids this risk.
• Gas costs. Low gas makes small loans and small liquidations profitable, but it also lets attackers open many tiny positions that are too small to liquidate at a profit.

Ethereum, Arbitrum, Base, Polygon PoS and BNB Smart Chain all run the Ethereum Virtual Machine (EVM), so the same Solidity contracts deploy on each. Solana needs a separate program written in Rust, with a different account model and different oracle integrations. Each chain deployment needs its own risk parameters, because settings copied from Ethereum are not safe on a chain with less liquidity.

Security risks in DeFi lending

• Empty-market exchange-rate attacks. Attackers have drained several Compound V2 forks when a new market launched with no deposits: the attacker donated tokens and used rounding errors to inflate the exchange rate. Seed every new market with a deposit, and round calculations in the protocol's favor.
• Reentrancy through token hooks. Some tokens, such as ERC-777 tokens, call the receiver during a transfer. Attackers have used these calls to re-enter lending contracts in the middle of a borrow. Update balances before any external call, and add a reentrancy guard to every entry point.
• Donation and accounting logic. Euler Finance lost about $197 million in March 2023, when an attacker used a donation function to create an undercollateralized position and liquidate it for a profit. The attacker returned the funds a few weeks later. Every function that changes balances must run the solvency check.
• Flash loans. A flash loan feature lets anyone borrow without collateral inside one transaction, and it adds attack surface. During a flash loan, some balances can be temporarily wrong, and no function should rely on them at that moment.

The smart contract audit guide explains how to scope a security review for a lending protocol.

How to build a DeFi lending platform

1. Choose the market structure (pooled, single borrowable asset or isolated) and the first assets. Two or three liquid assets are enough for a launch.
2. Write a risk framework that sets each asset's LTV, liquidation threshold, bonus and caps from its price volatility and on-chain liquidity.
3. Fork or write the core contracts. A fork of an audited protocol carries less risk than new code, but check the license first. Aave lists its V3 contracts under the Business Source License 1.1, which limits commercial use until a set change date, when the code moves to an open license.
4. Build a liquidation bot and publish liquidation documentation, so that outside liquidators compete for liquidations.
5. Run stress simulations. Test historical crashes, oracle delays, gas spikes and stablecoin de-pegs.
6. Launch in stages. Complete the audits, open a bug bounty, launch with low caps and raise them as the market proves stable.

Cost and timeline

The figures below are estimates, not quotes. A fork of an established lending protocol with new parameters, a front end and a liquidation bot takes a team of three to five engineers about two to four months, with audits and risk work on top of that time.

A new lending design takes longer, because it needs an economic review as well as a code audit. Running costs include oracle fees on some networks, keeper and bot servers, risk monitoring and governance work. For loans backed by NFTs, see the NFT lending guide, and for the wider field, see the DeFi development overview.

Regulation

Rules for crypto lending differ by country. In the EU, the Markets in Crypto-Assets Regulation (MiCA) does not cover the lending and borrowing of crypto assets, as recital 94 states, but national law in each member state still applies. A company that runs a lending front end, holds user funds or offers a fixed yield may need a license in its own jurisdiction.

Frequently asked questions