A lending protocol is easy to describe and hard to survive. Deposits earn, borrowers post collateral, the protocol takes a spread.
Everything that has ever gone wrong with one has gone wrong in the liquidation path, usually on a day when everything moved at once.
The interest rate model
Rates are set algorithmically against utilisation — what proportion of the pool is currently lent out.
The standard shape is a kinked curve. Below a target utilisation, rates rise gently. Above it, they rise steeply. The steep section exists to do two things simultaneously when liquidity gets scarce: pull new deposits in, and push borrowers to repay.
Getting the kink position right matters more than the exact slopes. Set it too high and the pool runs dry before rates react. Too low and you leave yield on the table and lose borrowers to protocols that do not.
Collateral factors are a risk decision
How much can be borrowed against a given asset is where most of the protocol’s actual risk management lives.
A stable, deeply liquid asset can support a high factor. A volatile, thinly traded one cannot, and the temptation to list it generously to attract deposits is exactly how protocols acquire the positions that hurt them.
The question to ask for every listed asset: if this fell sharply and liquidity vanished simultaneously, could the liquidation engine actually close positions at the prices it assumes? If the honest answer is no, the factor is too high regardless of what competitors offer.
The liquidation engine
Monitor every position. Compute a health factor from collateral value against debt. When it crosses the threshold, allow liquidators to repay debt in exchange for collateral at a discount.
The discount is the incentive. Too small and nobody liquidates, leaving the protocol holding bad debt. Too large and borrowers are punished disproportionately for brief volatility.
What matters more than the parameters is behaviour under stress, which is where design gets tested:
- Many positions crossing simultaneously, competing for the same liquidator attention and the same block space.
- Gas costs spiking exactly when liquidation is most urgent, making small positions uneconomic to close.
- Collateral prices falling further because liquidations are themselves selling pressure.
These are correlated, not independent. Designing for each separately produces a protocol that fails when they arrive together, which is the only way they ever arrive.
Partial liquidation and auto-deleveraging
Closing an entire position at once is brutal for the borrower and creates a large market impact.
Partial liquidation — closing only enough to restore health — is gentler and harder to implement correctly, particularly around rounding and the minimum economically viable liquidation size.
For protocols with leverage, an auto-deleveraging mechanism of last resort matters: a defined, transparent way for the system to reduce exposure when liquidation is failing. Socialised loss designs are unpopular and far better than insolvency, provided the rules were published in advance rather than invented during the incident.
Oracles are the attack surface
Every liquidation decision depends on a price, which makes the oracle the most attacked component in the system.
Use established providers with multiple independent sources. Apply sanity bounds so an impossible print cannot trigger mass liquidation. Handle staleness explicitly — decide in advance what the protocol does when the feed stops updating, because at some point it will.
Single-source oracles and spot prices read from a shallow on-chain pool have caused more lost value in DeFi than almost any other design error.
Testing that means something
Unit tests confirm the happy path. What you need is invariant testing — assert that the protocol can never become insolvent, that total debt always matches accounted borrows — and then try extremely hard to break those assertions.
Then run the liquidation engine against historical volatility. Take the worst days the market has actually produced, replay them against your parameters, and see what happens.
Two independent third-party audits before mainnet, plus formal verification on the accounting invariants. We coordinate those firms; we do not audit our own code.
Common questions
How does a DeFi lending protocol work?
Users deposit assets into a pool and earn interest; borrowers take loans against collateral worth more than they borrow. An interest rate model adjusts rates based on how much of the pool is lent out, and a liquidation engine closes positions when collateral value falls too close to the debt. The lending part is straightforward. The liquidation engine is what decides whether the protocol survives a volatile day.
What is a liquidation engine?
The system that closes undercollateralised positions before the debt exceeds the collateral backing it. It monitors every position against oracle prices, triggers when a health factor crosses a threshold, and incentivises liquidators to repay debt in exchange for discounted collateral. Its design under extreme conditions - when many positions cross at once and gas costs spike - is the single highest-risk component in the protocol.
What are the main risks in a lending protocol?
Oracle manipulation, cascading liquidations, and collateral assets that become illiquid faster than positions can be closed. All three are correlated: a manipulated or stale price triggers liquidations, liquidations push prices further, and thin liquidity means collateral cannot be sold at the assumed price. Designing for the correlated case rather than each risk separately is what separates protocols that survive a crash.
How should interest rates be set in DeFi lending?
Algorithmically, against utilisation, with a kink. Rates stay low while the pool has spare capacity and rise sharply past a target utilisation, which pulls in deposits and discourages borrowing exactly when liquidity is scarce. The kink position and the slope above it are the parameters that determine whether the pool can always honour withdrawals.
Does Corum8 build DeFi lending protocols?
Yes. We build the pool and accounting contracts, interest rate models, liquidation engines with stress testing against historical volatility, oracle integration with sanity bounds, and the front end and subgraph. We coordinate independent third-party audits before mainnet.
