Building a DeFi lending platform, decision by decision

TL;DR — A DeFi lending platform is a risk engine, not a web app with a wallet button. The parts that decide whether it survives are the ones users never see: the oracle, the interest-rate curve, and the liquidation engine. Get the collateral maths and the price feed wrong and no audit saves you. Get them right and most of the remaining work is disciplined engineering. Budget the majority of your effort for the invariants that protect other people's money, not the features that attract it.

Most teams that set out to build a DeFi lending platform start in the wrong place. They start with the front end — the deposit box, the borrow button, the APY ticker — because that is the part they can picture. The front end is the least important thing you will build. A decentralized lending protocol is a system that holds custody of strangers' money, lets other strangers borrow it against volatile collateral, and has to remain solvent through market crashes, oracle failures, and people actively trying to steal from it. The interface is a thin skin over a risk engine. If the risk engine is wrong, a beautiful interface just helps people lose money faster.

This piece walks through the decisions that actually determine whether a lending platform works: how the protocol is structured, which smart contracts you truly need, where prices come from, how interest and liquidations are modelled, and the classes of exploit that have drained hundreds of millions from protocols that looked fine in a demo. It is written for the founder or CTO who has decided decentralized lending is the product and now has to make the calls that are expensive to reverse. The recurring theme: the demo is easy, and the demo is a lie. The distance between "it works on a testnet" and "it can hold nine figures of other people's money" is the entire job.

What a lending protocol actually is

Strip away the branding and every on-chain lending platform does the same three things. It takes deposits of an asset and issues the depositor a claim that accrues interest. It lets a borrower take that asset out, but only if they have posted collateral worth more than they borrow. And it continuously checks that every borrower's collateral still covers their debt — and forcibly sells that collateral the moment it stops.

That third function is the product. Deposits and withdrawals are bookkeeping. The reason a lending protocol can offer permissionless, undercollateralized-feeling credit to anonymous wallets is that it is, in fact, always overcollateralized, and it has an automated mechanism to enforce that fact faster than the market can move against it. Everything hard about the build lives in that enforcement loop.

Pooled liquidity versus peer-to-peer

The first architectural fork is whether lenders and borrowers are matched directly or through a shared pool. Peer-to-peer matching — one lender's capital funding one borrower's loan at an agreed rate — gives precise terms and cleaner accounting, but it fragments liquidity and leaves capital idle while it waits to be matched. Almost every protocol that reached meaningful scale chose the pooled model instead: all deposits of a given asset flow into one reserve, all borrows draw from it, and a single algorithmic interest rate clears supply and demand for the whole pool.

The pooled model is what makes deposits instantly liquid and borrowing instantly available, and it is the design you should default to. It also concentrates risk: one bad collateral listing or one oracle failure threatens the entire reserve, not a single loan. Pooling trades per-loan isolation for capital efficiency and liquidity, and then forces you to manage the pooled risk explicitly through collateral factors, caps, and — increasingly — isolated markets that ring-fence riskier assets so their failure cannot drain the blue-chip reserves. Building the pool is a week of work. Deciding which assets are allowed in and on what terms is the work that never ends.

Collateral, LTV, and the health factor

The number that governs the whole system is the ratio between what a borrower owes and what their collateral is worth. Each collateral asset gets a maximum loan-to-value — the fraction of its value you will lend against. Post $10,000 of ETH at a 75% LTV and you can borrow up to $7,500. The gap between that limit and the point at which you get liquidated is your safety margin, and it exists because collateral value moves while the loan sits there.

In practice this is expressed as a health factor: the ratio of the borrower's liquidation-weighted collateral to their debt. Above one, the position is safe. At or below one, it is liquidatable. The health factor is not a display metric — it is the single scalar the entire protocol is built to keep above one for every account, and every design choice about oracles, interest, and liquidation is ultimately about how quickly and reliably you can act when it dips. The maximum LTV, the liquidation threshold (usually a few points above the max LTV to create a buffer), and the liquidation penalty are the three risk parameters you will argue about more than anything else, because they are the dials that trade off capital efficiency against solvency. Set them loose to attract borrowers and you invite bad debt on the first sharp move. Set them tight and no one uses you. There is no universally correct setting — only a setting appropriate to each asset's liquidity and volatility, which is why per-asset risk configuration, not code, becomes your real product.

The contracts you actually need

A common mistake is imagining you need dozens of contracts. You need a small, deliberate set, and the discipline is in keeping them small.

At the center is the pool or lending-pool contract: the entry point that holds accounting for reserves, handles deposit, withdraw, borrow, and repay, and enforces the health-factor check on every state-changing action. Around it you need a configuration or registry contract that stores each asset's risk parameters and can be updated by governance without touching the core logic. You need interest-bearing receipt tokens — the tokenized claim a depositor receives, whose balance grows as interest accrues, plus a corresponding debt token that tracks what a borrower owes. You need an oracle adapter that normalizes price feeds into a single interface the pool can query. And you need a liquidation contract — sometimes folded into the pool, better kept separate — that executes the seizure and sale of collateral from unhealthy positions.

That is the whole spine. Resist adding more. Every additional contract is additional surface area for bugs and additional trust the user has to extend. The protocols that have held up over years are, at their core, remarkably compact.

Interest-bearing tokens and the accounting trap

The receipt-token design has a subtlety that trips up first-time teams. You want a depositor's balance to grow continuously with accrued interest, but you cannot loop over every account updating balances — that would cost unbounded gas. The standard solution is to store balances internally as shares of a growing index rather than as raw token amounts. The pool tracks a single liquidity index that increases as interest accrues; each account's displayed balance is its share multiplied by the current index. Interest for a million accounts is applied by updating one number. The same rebasing-index pattern handles borrower debt.

This is elegant and it is also where rounding bugs and share-inflation attacks live. When shares convert to and from underlying amounts, the direction you round matters: always round in the protocol's favor, never the user's, or an attacker will extract the dust systematically. And the very first deposit into an empty share-based vault is a known attack vector — a malicious first depositor can donate assets to skew the share price and steal from the next depositor. You handle it by seeding the pool, burning initial shares, or using virtual reserves. These are not edge cases you discover in production; they are known, catalogued failure modes you design out from the first commit.

Upgradeability, and what it costs

You will want the ability to fix bugs and add markets after launch, which means a proxy pattern that separates storage from logic so you can point the proxy at new implementation code. This is standard and usually correct. It is also a loaded gun. An upgradeable contract means someone — a multisig, a governance process, a timelock — can change the rules under which users deposited their funds. That admin key is now the most valuable target in your system; more protocols have been drained through compromised upgrade keys and malicious governance than through clever maths.

The decision is not "upgradeable or immutable" in the abstract; it is how much you constrain the upgrade path. A timelock that delays every upgrade by 24 or 48 hours gives users a window to exit if governance proposes something hostile or compromised. A well-distributed multisig raises the bar on key compromise. Immutable core logic with upgradeable peripheral modules gives you the best of both where it counts. Whatever you choose, the upgrade mechanism is a first-class part of the threat model, not an ops detail — and pretending otherwise is how teams with clean audits still lose everything. This is exactly the kind of decision where disciplined product engineering — thinking through the operational and adversarial consequences of an architectural choice, not just the happy path — separates a protocol that survives from one that merely launches.

Where prices come from: the oracle problem

If you take one thing from this piece, take this: the oracle is the single most dangerous component in a DeFi lending platform, and it is the one teams most consistently underestimate. Your protocol's entire notion of whether a position is healthy depends on knowing what the collateral is worth. That number comes from outside the chain. An attacker who can move that number, even for a single block, can make the protocol believe worthless collateral is valuable, borrow against it, and walk away — leaving the pool with bad debt. A large share of the biggest DeFi exploits by dollar value trace back to price manipulation, not to bugs in the lending logic itself.

For background on the mechanics of decentralized lending before you go deeper on the risk surface, our companion piece on what is DeFi lending and how does it work covers the fundamentals. This section is about the part that keeps engineers awake.

Why an on-chain spot price is a trap

The naive approach is to read the price from an on-chain source you already have — the reserves of a decentralized exchange pool. It is right there, it is trustless, and it is catastrophic. A DEX spot price is only the marginal price of the last trade, and within a single transaction an attacker can borrow a huge sum via a flash loan, dump it into the pool to crash or spike the reported price, exploit your protocol at that fake valuation, and reverse the trade — all atomically, all before any other transaction sees the manipulation. Reading a raw DEX spot price for a lending oracle is the single most common way inexperienced teams get drained, and it has happened over and over.

TWAP and its limits

The first mitigation is a time-weighted average price: instead of the instantaneous price, use the average over a window — say 30 minutes — which makes manipulation require sustaining a distorted price across many blocks at real cost. TWAPs from deep, established pools raise the manipulation bar substantially and are genuinely useful. But they are not free of tradeoffs. A longer window is harder to manipulate but slower to reflect real crashes — which is dangerous, because during a real crash you need current prices to liquidate promptly. And a TWAP is only as manipulation-resistant as the liquidity of the pool it reads; a thinly traded asset's TWAP can still be moved by a determined attacker.

Chainlink, redundancy, and circuit breakers

For most production lending platforms, the answer is a decentralized oracle network — Chainlink being the dominant choice — that aggregates prices from many off-chain sources and many independent node operators, delivering a signed price on-chain that no single actor controls. This is the sensible default for major assets. It is not a license to stop thinking. Oracle feeds can go stale if updates stall; they can have their own failure modes; and not every asset you want to list has a robust feed. Serious protocols treat the oracle as a component that will eventually misbehave and design accordingly: check the timestamp and reject stale prices, sanity-check against a secondary source, and implement circuit breakers that pause borrowing or liquidation if a price moves implausibly far in one update. The mature posture is not "we use Chainlink so oracles are handled." It is "we assume the price feed will lie to us someday, and the protocol degrades safely when it does."

The interest-rate model

Interest rates in a pooled lending protocol are not set by a human; they are a function of how much of the pool is being borrowed. The variable that drives everything is utilization — the fraction of available liquidity currently lent out. When utilization is low, capital is idle, so borrowing is cheap to attract demand. As utilization rises, rates climb to attract more deposits and discourage further borrowing. The relationship between utilization and rate is your interest-rate curve, and its shape is a real design decision with real consequences.

The standard is a piecewise-linear curve with a kink. Below a target utilization — commonly around 80 to 90% — rates rise gently as a function of utilization. Above the kink, they rise steeply, sometimes to triple-digit APRs at full utilization. The steep upper segment exists for one reason: to guarantee that the pool never fully empties. If borrowing could push utilization to 100%, depositors could not withdraw, because their capital would all be lent out — a liquidity crisis. The punishing rates above the kink make it economically irrational to borrow the pool dry, so utilization self-corrects and there is always a buffer for withdrawals. The kink is not a tuning nicety; it is the mechanism that keeps deposits redeemable.

Choosing the kink location and the two slopes is a matter of the asset and the risk appetite: stablecoins can run a higher target utilization because their price is stable and demand is predictable; volatile assets warrant a more conservative curve. As with LTV, there is no universal answer — which is why the interest-rate model, like the risk parameters, is configured per asset and revisited as markets change.

The liquidation engine

Liquidation is the mechanism that makes the whole thing work, and it is the part most likely to fail when you need it. When a borrower's health factor drops below one, the protocol must sell enough of their collateral to bring the position back to safety, before the collateral's value falls below the debt and the pool eats a loss. The protocol cannot do this itself — a smart contract cannot wake up and act; something has to call it. So liquidation in DeFi is outsourced to a competitive market of external actors, usually called liquidators or keepers.

Incentives and the liquidation bonus

You motivate liquidators with a discount: a liquidator who repays part of an unhealthy borrower's debt gets to seize their collateral at a bonus — say 5 to 10% below market. That bonus is the liquidator's profit and the borrower's penalty, and it has to be calibrated carefully. Too small, and no one bothers to liquidate small or gas-expensive positions, so bad debt accumulates. Too large, and borrowers are punished excessively on minor dips and liquidations become predatory. The bonus also has to exceed the gas cost and price risk a liquidator takes on, or rational actors will sit out exactly when you need them most — during network congestion, when gas spikes and everyone is trying to act at once.

Cascades, and designing for the worst day

The scenario that breaks lending protocols is not a single liquidation; it is a cascade. A sharp price drop pushes many positions underwater at once. Liquidators sell the seized collateral into a falling market, which pushes the price down further, which pushes more positions underwater, which triggers more selling. On the worst days this reflexive loop, combined with network congestion that delays liquidation transactions and blocked oracle updates, is how protocols accumulate bad debt in minutes. You cannot eliminate this risk, but you design against it: conservative LTVs that leave room to liquidate before collateral falls below debt; caps on how much can be liquidated in one transaction to avoid dumping; support for partial liquidations so a position is trimmed to health rather than wholesale dumped; and — as a backstop — a reserve or insurance fund that absorbs bad debt when liquidation is not fast enough. The question to ask of every liquidation-path decision is not "does this work in normal conditions" but "does this work on the single worst day of the year, when everything correlated crashes together." That day is when your protocol is actually tested, and it is the only test that counts.

Security: assume you will be attacked

Everything above is the design. Security is the discipline of making sure the design's invariants actually hold in code, against people whose full-time job is finding the one place they don't. DeFi is uniquely unforgiving here: the code is public, the money is in the code, and a single exploitable flaw can drain everything in one transaction with no recourse. There is no chargeback, no support line, no rollback.

The exploit classes you must design out

A handful of vulnerability classes account for most of the value ever stolen from DeFi protocols. Reentrancy — where an external call lets an attacker re-enter your contract mid-execution before state is finalized — is the classic, and you defend against it with the checks-effects-interactions ordering and reentrancy guards, applied rigorously, not selectively. Oracle and price manipulation, covered above, is the largest category by dollars lost. Flash-loan attacks are not a vulnerability themselves but an amplifier: they let an attacker wield millions in capital for a single transaction at near-zero cost, turning a subtle pricing or accounting flaw that would be uneconomical to exploit with real money into a catastrophic one — which means you must assume every attacker is arbitrarily well-capitalized within a transaction. Then there are the quieter ones: integer rounding and share-inflation bugs, unchecked external calls, access-control mistakes that leave an admin function callable by anyone, and logic errors in the health-factor or interest maths. None of these are exotic. They are catalogued, understood, and still ship to mainnet constantly because teams treated security as a phase rather than a property.

Audits, formal verification, and their limits

You will get the code audited — by more than one reputable firm, because auditors miss things and a second independent pass catches what the first didn't. An audit is necessary and it is not sufficient; audited protocols get exploited regularly, because an audit is a time-boxed review by humans, not a proof. For the core invariants — the ones that must never be violated, like "total debt never exceeds total collateral value" or "no function lets a user withdraw more than they own" — formal verification, which mathematically proves properties hold for all possible inputs, is worth the substantial effort. Beyond audits, the practices that actually move the needle are a comprehensive test suite that includes adversarial and fuzz testing, invariant tests that assert your core properties under randomized sequences of actions, a staged mainnet rollout with conservative supply caps that limit what a first-day exploit could take, a monitoring system that watches for anomalous activity in real time, and a well-funded bug bounty that makes responsible disclosure more attractive than exploitation. Security is not a gate you pass before launch; it is an operating posture you hold forever, because the code stays public and the incentives to break it only grow with your TVL.

Compliance is a design input, not an afterthought

The pure-DeFi ideal is permissionless: anyone with a wallet can lend or borrow, no identity required. The regulatory reality is that this ideal is under pressure everywhere, and the posture you take is a product decision with architectural consequences you cannot bolt on later. A fully permissionless protocol maximizes decentralization and minimizes your control — which is the point, but also means you cannot stop sanctioned addresses or comply with jurisdiction-specific rules, and that has real legal exposure depending on where you and your users are.

Many teams building for institutional capital or specific jurisdictions choose a permissioned or hybrid model: KYC/AML checks gate access, allowlisted addresses can interact, and the protocol can enforce compliance rules at the contract level. This is a legitimate design, and it is a fundamentally different system from the permissionless version — different contracts, different trust assumptions, different user experience. The mistake is treating compliance as a front-end feature you add before launch. Whether and how you verify identity, restrict access, and handle sanctioned addresses shapes the contract architecture itself, and retrofitting it into a live permissionless protocol is often impossible. Decide your regulatory posture before you write the core contracts, not after.

Deployment, gas, and scaling

Where you deploy is now a serious decision because it changes your economics and your risk. Deploying to Ethereum mainnet buys you the deepest liquidity, the most mature oracle infrastructure, and the strongest security assumptions — and it costs users a great deal in gas, which makes small deposits and, critically, small liquidations uneconomical. That last point matters: if gas is high, liquidating a modest underwater position may cost more than the liquidation bonus is worth, so those positions don't get liquidated and become bad debt.

Layer-2 rollups and alternative chains cut gas by orders of magnitude, which makes the protocol usable for smaller positions and keeps liquidation economical during stress. The tradeoff is thinner liquidity, younger and sometimes less battle-tested oracle feeds, and different security and finality assumptions you have to understand rather than inherit. There is no free lunch: cheaper execution generally means shallower markets and newer infrastructure. The right answer depends on your target users and assets, and many protocols deploy to several chains — but multi-chain multiplies your surface area, your oracle dependencies, and your operational burden, so it is a decision to make deliberately, not by default. Deployment and scaling is where a lot of dApp projects underestimate the ongoing operational weight of running a protocol that holds real value across multiple environments.

What separates a demo from a protocol

You can build something that looks like a DeFi lending platform in a few weeks. Deposit, borrow, a rate that moves, a front end with an APY. It will demo perfectly on a testnet with a mocked price feed and cooperative users. It will also be, in the precise sense that matters, unsafe to put a single real dollar into — because the demo skips exactly the parts that are hard: the oracle that resists manipulation, the interest curve that guarantees liquidity, the liquidation engine that holds up on the worst day, and the security discipline that assumes a well-funded adversary is reading your code line by line.

The distance between that demo and a protocol that can safely custody nine figures is not a matter of adding features. It is a matter of getting a small number of invariants exactly right and proving they hold under adversarial conditions, then operating the thing with the assumption that it will be attacked forever. Teams that understand this from the start spend their effort where the risk is. Teams that don't spend it on the interface and discover the risk in production, on-chain, in public, with other people's money. Building decentralized lending software is one of the most demanding things you can do in software precisely because the usual forgiveness of software — patch it later, roll it back, apologize to users — does not exist. The maths has to be right the first time.

FAQ

How long does it take to build a DeFi lending platform? A credible production build is typically a matter of months, not weeks, and the timeline is dominated by security work — multiple independent audits, formal verification of core invariants, adversarial testing, and a staged rollout — not by writing the core contracts, which is a comparatively small share of the effort. Anyone promising a safe, launch-ready lending protocol in a few weeks is quoting the demo, not the product.

What is the biggest security risk in a decentralized lending protocol? Price oracle manipulation. Because the protocol's entire notion of collateral value depends on an external price, an attacker who can move that price — often using a flash loan to do it atomically within one transaction — can borrow against overvalued collateral and drain the pool. A large share of the biggest DeFi exploits by dollar value come from oracle manipulation rather than bugs in the lending logic itself.

Should I use Chainlink or a TWAP oracle? For major assets, a decentralized oracle network like Chainlink is the sensible default because it aggregates many independent sources and no single actor controls the price. TWAPs are useful for assets without a robust feed or as a secondary check, but they lag real price moves and are only as safe as the liquidity of the pool they read. Serious protocols use redundancy, staleness checks, and circuit breakers regardless of the primary source.

What is a health factor? The health factor is the ratio of a borrower's liquidation-weighted collateral value to their outstanding debt. Above one, the position is safe; at or below one, it becomes eligible for liquidation. It is the single scalar the entire protocol is engineered to keep above one for every account, and every oracle, interest, and liquidation decision ultimately serves that goal.

Do I need KYC to run a DeFi lending platform? It depends on your regulatory posture and target users, and it is a decision you must make before writing the core contracts, not after. A fully permissionless protocol requires no identity but carries legal exposure and cannot restrict sanctioned addresses; a permissioned or hybrid model gates access with KYC/AML and is a fundamentally different system architecturally. Retrofitting compliance into a live permissionless protocol is often impossible.

Which is better: a pooled model or peer-to-peer lending? The pooled model, where all deposits of an asset share one reserve and one algorithmic rate, is the default for most platforms because it makes deposits instantly liquid and borrowing instantly available. Peer-to-peer matching gives more precise terms but fragments liquidity and leaves capital idle. Pooling's tradeoff is concentrated risk, which you manage through per-asset collateral factors, supply caps, and isolated markets for riskier assets.