DeFi lending protocol development: design choices that decide risk

DeFi lending protocol development is mostly risk design written as code. The contracts that take deposits and issue loans are well understood. What decides whether your protocol survives is a handful of choices: whether markets share risk or isolate it, which oracle you trust for prices, how liquidations work under stress, how the interest rate curve behaves near full utilization, and who can change those parameters. Get those right and the code is a careful implementation job. Get them wrong and no audit will save you.

This guide covers each choice in the order we would make it, with references to how Aave, Compound and Morpho handled the same decisions.

Pick the market structure first

This is the decision everything else depends on.

Compound moved to this model in Compound III: a single borrowable, interest-earning asset, with all other supported assets functioning as collateral, plus market-wide limits on each collateral asset. Collateral no longer earns interest, and in exchange it can never be withdrawn by other users. Morpho Blue went further. Each market has one collateral asset, one borrowable asset, an oracle, a liquidation LTV and an interest rate model, all fixed at creation, and risk is contained within each market.

Aave kept the shared pool but added controls to contain risk inside it: supply and borrow caps per asset, an isolation mode that lets a new asset serve as collateral only for approved stablecoin borrowing up to a debt ceiling, and an efficiency mode with higher LTVs for correlated assets. Cyfrin's Aave v3 overview walks through how these work together.

Our opinion: if you are launching a new protocol without an established risk team, isolated markets are the safer default. Shared pools are more capital efficient, but they make every listing decision a decision about every lender's money. That is a heavy governance burden for a young protocol. If your product targets one specific use case, such as borrowing stablecoins against a single yield-bearing token, an isolated market is often the entire product.

Oracles: the most common way lending protocols die

A lending protocol values collateral using a price feed. If an attacker can move that price, they can borrow against collateral that is not worth what the protocol thinks.

Mango Markets is the textbook case. In October 2022, an attacker pushed the price of the MNGO token up sharply in an illiquid market, which inflated the value of their collateral, and then borrowed against it. CertiK's analysis puts the loss at about $116 million. The price feed worked as designed. It reported a price from a market that was too thin to trust.

Rules we follow when designing oracle integration:

• Use aggregated, manipulation-resistant feeds for anything accepted as collateral. Chainlink feeds update when the price deviates past a threshold or when the heartbeat interval passes, whichever comes first.
• Check staleness per feed. Chainlink's docs tell integrators to use the updatedAt value from latestRoundData() to confirm the answer is recent enough. Set the maximum age to match each feed's heartbeat, since heartbeats differ by feed and by chain.
• Never price collateral from a single DEX spot price. Spot prices can be moved within one transaction using a flash loan. Time-weighted prices are harder to move, but on thin pools they can still be pushed over a few blocks.
• Match collateral to oracle quality. If a token has no reliable feed and thin liquidity, it should not be collateral, or it should sit in an isolated market with a low LTV and a tight supply cap.
• Plan for oracle failure. Decide in advance what happens if a feed stops updating: pause borrowing against that asset, fall back to a secondary source, or both.

Liquidations: design them for the worst day

Each position has a health factor: risk-adjusted collateral value divided by debt. When it drops below 1, anyone can repay part of the debt and receive collateral at a discount. The discount, often called the liquidation bonus, pays liquidators to do this quickly.

The parameters to decide:

1. Liquidation threshold and max LTV. Max LTV is how much a user can borrow. The threshold, set slightly higher, is where liquidation starts. The gap between them is the user's buffer.
2. Liquidation bonus. Too low and nobody liquidates during a crash, when gas is expensive and DEX liquidity is thin. Too high and users lose more than they should, and the bonus itself can push positions further underwater.
3. Close factor. How much of a position can be liquidated in one call. Aave v3 caps it at 50% while the health factor is above 0.95 and allows full liquidation below that, per the CLOSE_FACTOR_HF_THRESHOLD constant in its LiquidationLogic contract. Partial liquidation is gentler on users. Full liquidation clears risky positions faster.
4. Who liquidates. Assume nobody will at launch. Run your own liquidation bot until third-party liquidators show up, and keep it funded.
5. Bad debt handling. When collateral is worth less than debt and liquidation can no longer cover it, someone absorbs the loss. Decide who: a reserve fund built from interest, a safety module, or lenders in that market pro rata. Write it down before launch.

Liquidation logic is also where subtle bugs live. Euler Finance lost roughly $197 million in March 2023 after a donateToReserves function, added in a later upgrade, let a user reduce their own collateral without a health check. The attacker used it to make their own leveraged position insolvent and then liquidated it at a profit. The lesson we take from it: every function that changes a balance must end with the same solvency check, and every upgrade gets reviewed against that invariant, not only the new code in isolation.

Interest rate model

Most lending protocols use a kinked curve based on utilization, the share of supplied assets currently borrowed. Below an optimal utilization point, the borrow rate rises slowly along one slope. Above it, the rate rises steeply along a second slope. Aave's docs describe this directly as Slope1 below the optimal usage ratio and Slope2 from there up to 100%.

The steep second slope exists for one reason: lenders must be able to withdraw. At 100% utilization there is nothing left in the pool to withdraw, so the rate must get high enough that borrowers repay and new lenders deposit.

How those numbers get tuned in practice: in August 2026 Aave's risk stewards raised optimal utilization from 90% to 92% and cut Slope2 from 40% to 20% on three stablecoin reserves on Aave v3 Monad, lowering the borrow rate at full utilization from 44% to 24%. Even a mature protocol adjusts these curves often, per asset and per chain. Build the model so parameters can change without redeploying markets, and put that change behind a timelock or a narrow risk role.

Practical guidance for a new protocol:

• Stablecoins tolerate higher optimal utilization because their price risk is low.
• Volatile assets need lower optimal utilization and a steeper Slope2, so lenders can exit during a sell-off.
• Set a reserve factor, the share of interest kept by the protocol, from day one. It funds the bad debt buffer.

Risk parameters and who controls them

Your full parameter set per asset typically includes: max LTV, liquidation threshold, liquidation bonus, supply cap, borrow cap, reserve factor, interest rate curve, oracle address and whether the asset can be collateral at all.

Then decide how those change:

Caps matter most at launch. Start with low supply caps on every new collateral and raise them as liquidity and liquidation history build up. A cap is the cheapest risk control you have. If you plan to make contracts upgradeable, read our guide on upgradeable smart contracts and proxy patterns before choosing a pattern, because an upgrade path is also an attack path.

Build steps

The order we would build a lending MVP:

1. Write the risk spec. Market structure, assets, oracles, parameters, liquidation and bad debt policy. This document is what auditors read first.
2. Core contracts. Supply, withdraw, borrow, repay, liquidate, interest accrual. Keep accounting in shares (like aTokens or cTokens) rather than raw balances, so interest accrues without touching every account.
3. Invariant tests and fuzzing. Total borrowed never exceeds total supplied. No action leaves an account below its health threshold unless it is a liquidation. Interest accrual is monotonic. Run these under Foundry fuzzing and fork tests against real oracle feeds.
4. Liquidation bot and monitoring. Bots that watch health factors, a dashboard of utilization and positions near liquidation, alerts on oracle staleness. You will need an indexer for positions; our blockchain indexer comparison covers the options.
5. Audit. At least one full audit, ideally two firms for a protocol holding real deposits. Our smart contract audit checklist covers preparation, and the security ROI post covers budget.
6. Guarded launch. Low caps, a short list of collateral, a bug bounty live from the first day, and a pause function with a clearly limited scope.
7. Raise limits based on data, not on demand.

Fork, license or build

You rarely need to write a lending protocol from zero. Aave v3 and Compound III code is public, and many lending protocols started as forks. Licences differ though, and some code is under business source licences with restrictions on commercial use, so check before forking. Deploying on top of Morpho-style isolated markets as a curator is another route if your product is the strategy, not the protocol. We compare those routes in white-label DeFi: build vs buy.

Our planning estimates: a fork of an audited protocol with your own asset list, parameters and frontend takes roughly 6 to 10 weeks plus an audit of the diff. A custom lending protocol with new mechanics typically runs 4 to 8 months including two audits, and the audit queue often adds weeks you do not control.

FAQ

How do DeFi lending protocols work?

Lenders deposit assets into a pool and earn interest. Borrowers post collateral worth more than their loan and pay interest set by utilization. If collateral value falls too far, liquidators repay the debt and take collateral at a discount.

What is the difference between Aave and Morpho?

Aave runs shared pools where many assets back each other, with caps and isolation modes to contain risk. Morpho Blue runs isolated markets, each with one collateral, one loan asset and parameters fixed at creation.

How much does it cost to build a lending protocol?

By our planning estimates, forking and customizing an audited protocol is the cheapest route, mostly frontend, configuration and an audit of the changes. A custom protocol with new mechanics costs several times more, with two audits as a large share of the budget.

Which oracle should a lending protocol use?

Use an aggregated feed such as Chainlink for any collateral asset, check staleness against each feed's heartbeat, and avoid single-DEX spot prices. Assets without a reliable feed should not be collateral, or only in isolated markets with tight caps.

How do liquidations work in DeFi lending?

When a position's health factor drops below 1, anyone can repay part of the debt and receive collateral plus a bonus. Aave v3 lets liquidators repay up to 50% of a position at a time unless the health factor is below 0.95.

Work with us

If you are designing a lending market, or deciding whether to fork, license or build, we can help you write the risk spec and the contracts behind it. See our DeFi product development work or contact 23studio to talk through your markets.