T22 · Lending Protocol

A Real-World Problem

Your lending pool has been live for a month and appears to work well.

You are proudest of its interest-rate curve: two linear segments, a carefully placed kink, sharp borrowing costs at high utilization, and pleasing symmetry between deposit and borrow returns on the chart. You wrote extensive unit tests and checked each slope to six decimal places.

Then, one afternoon, the collateral asset falls 25% in twenty minutes.

During reconciliation the next day, you find bad debt: after a position was liquidated, the collateral sale could not cover its debt. The protocol absorbs the shortfall.

You review the components one by one:

• Was health calculated incorrectly? No; hand calculation matches the code.
• Was there a bug in liquidation? No; tests exercised it hundreds of times.
• Did the price feed fail? No; all four T21 checks passed, and prices accurately tracked the decline.
• Was the collateral factor too high? It was 75%, a common setting.

Every component worked. Bad debt still appeared.

The chain history reveals the cause: the position became liquidatable at 14:32, but the first successful liquidation executed at 14:36.

Four minutes. During those minutes, the price fell another 12%.

You spent a month polishing the interest-rate curve, but those four minutes decided whether the protocol was safe.

Thought Experiment

Think of a lending protocol as a pawnshop. Set interest rates aside.

The rule is simple: pledge an item worth 100 and borrow 75.

The item's price can change. At 80, the pawnshop may still be safe; at 70, it loses money.

The owner cannot watch every pledged item around the clock. Instead, they outsource the task to the market and post a notice:

Anyone who finds collateral worth less than 80 may buy it at a 5% discount to its current value, using the proceeds to repay its loan.

Notice who these people are: they are not employees, receive no salary, and owe no duty to act. They appear only when it is profitable.

Break the mechanism into four questions:

First, why would they come? The 5% discount is the entire incentive. If the item is worth only 200, that is 10 in gross profit; after fees and transaction costs, the trip may not pay.

Second, how quickly can they arrive? They must notice the position, prepare funds (hold or borrow the 190), send a transaction, and wait for inclusion.

Third, can another buyer win first? Everyone sees the same opportunity; only one captures it. Losers pay for unsuccessful attempts and may bid more next time. Those costs eventually reach users.

Fourth, and most important, what is the 25% buffer really?

It is not merely a safety cushion. It is a time budget.

Precisely, the collateral may fall by at most 25% between the start of the decline and completion of liquidation. If price falls faster or liquidators arrive later, the pawnshop bears the gap.

The real question is not “what collateral factor should we set?” It is whether price falls faster than liquidation can run.

Your Decision

The market is falling fast and many positions approach their liquidation lines. As protocol designer, which of four levers do you use first?

What Happens

All four levers buy the same thing: time.

Summarize it as the chapter's central inequality:

Bad debt appears when:

    Collateral price decline during the "liquidation delay"
                >
    Buffer provided by the liquidation threshold + portion consumed by liquidation bonus

Where:
  Buffer = 1 - debt / (collateral value * liquidation threshold) ← what you can design
  Liquidation delay = detection + decision + funding + inclusion   ← what you cannot control

The left side is market speed and the right side is your design. Safety depends on which is larger.

Most people focus on the right: tuning parameters, optimizing formulas, and proving the rate curve continuous. Incidents tend to come from the left, driven by how violently price moves and how slowly liquidation completes.

Hence this chapter's rule: a lending protocol's safety boundary is liquidation speed, not an elegant interest-rate model.

The rate model determines income. Liquidation speed determines survival.

Build a Model

Split liquidation delay into stages so you can improve the right one:

The final row is easily missed and can explode during congestion. Ten liquidators race for one opportunity; nine fail, recompute, and submit again as prices keep falling.

Now the code: three central functions.

First, the health factor. It is the protocol's pulse:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

// Express ratios in basis points (bps) to avoid floating point
uint256 constant BPS = 10_000;

struct Account {
    uint256 collateral;   // Collateral amount
    uint256 debt;         // Debt principal, with interest already accrued through the index
}

/// Health factor >= 1 means safe; below 1 means liquidatable
/// Return value is scaled by BPS as well: 10_000 represents 1.0
function healthFactor(
    uint256 collateral,
    uint256 price,              // Unit price of collateral
    uint256 liquidationLtv,     // Liquidation threshold in bps; often 7000–8500, per-asset configurable
    uint256 debt
) pure returns (uint256) {
    if (debt == 0) return type(uint256).max;
    uint256 adjusted = collateral * price * liquidationLtv / BPS;
    return adjusted * BPS / debt;
}

Two details:

• Liquidation threshold and collateral factor are different numbers. The factor caps borrowing; the threshold triggers liquidation and must be higher. Their gap is the user's buffer and only opportunity to repair the position.
• Accrue interest before calculating health. A long-idle position can cross the line from interest alone, without any price change.

Second, the interest-rate model. Two slopes are common:

/// Utilization = total borrowed / total supplied
function utilization(uint256 borrowed, uint256 supplied) pure returns (uint256) {
    if (supplied == 0) return 0;
    return borrowed * BPS / supplied;
}

/// Gentle before the kink; steep afterward
function borrowRate(
    uint256 u,           // Utilization, in bps
    uint256 base,        // Base rate
    uint256 slope1,      // Slope before kink
    uint256 slope2,      // Slope after kink, often an order of magnitude higher
    uint256 kink         // Kink, often 8000–9000 bps; configurable
) pure returns (uint256) {
    if (u <= kink) {
        return base + u * slope1 / kink;
    }
    uint256 excess = u - kink;
    return base + slope1 + excess * slope2 / (BPS - kink);
}

The steep segment after the kink is not mainly for revenue. It protects liquidity. Near 100% utilization, depositors cannot withdraw. A sharp borrowing rate pushes borrowers to repay and restore availability.

This is rate limiting through a price. It works only if the slope is steep enough and borrowers can actually repay promptly.

Third, liquidation. This is the chapter's most delicate function:

error NotLiquidatable(uint256 health);
error TooMuchDebt();

function liquidate(
    address user,
    uint256 repayAmount        // Debt the liquidator repays for the user
) external {
    Account storage a = accounts[user];
    _accrueInterest(user);

    uint256 price = priceGuard.readPrice();          // Includes the four T21 checks
    uint256 health = healthFactor(a.collateral, price, liquidationLtv, a.debt);
    if (health >= BPS) revert NotLiquidatable(health);

    // Maximum debt repaid in one call; closeFactor often around 5000 bps, configurable
    uint256 maxRepay = a.debt * closeFactor / BPS;
    if (repayAmount > maxRepay) revert TooMuchDebt();

    // Collateral seized = equivalent value plus bonus
    uint256 seized = repayAmount * BPS / price;
    seized = seized * (BPS + liquidationBonus) / BPS;

    // Insufficient collateral: this is where bad debt arises
    if (seized > a.collateral) {
        seized = a.collateral;
        // Record remaining debt explicitly; do not silently erase it
        _recordBadDebt(user, a.debt - repayAmount);
    }

    a.debt -= repayAmount;
    a.collateral -= seized;

    _pullDebtToken(msg.sender, repayAmount);
    _pushCollateral(msg.sender, seized);
}

The final if is where bad debt appears. Write it explicitly and account for it.

If you omit it and simply revert when collateral is insufficient, the position can never be liquidated. It remains in the protocol, debt keeps accruing, and collateral is always short. A known loss turns into a growing black hole.

General rule: bad debt cannot always be avoided, but it must be visible. Recorded losses can be covered by reserves, shared with depositors, or disclosed. Hidden losses erupt when someone cannot withdraw.

What It Is Called

Hands-on

Block 0    Price 100; health factor 1.33
Block 1    Price 92
Block 2    Price 85    ← position crosses the liquidation line
Block 3    Price 79
Block 4    Price 74
Block 5    Price 70

Liquidator profit = liquidated amount * liquidation bonus
                    - gas cost - slippage when selling collateral

A rational liquidator will not act when this is zero or negative

             1-block delay   3-block delay   10-block delay
5% fall      Safe            Safe            Safe
15% fall     Safe            Safe            Bad debt
30% fall     Safe            Bad debt        Bad debt
50% fall     Bad debt        Bad debt        Bad debt

AI Lab

Step one:
Design a two-slope interest-rate curve for a lending pool. Give parameters,
formula, and Solidity code. Explain where to put the kink, why, and how steep
the post-kink segment must be to matter.

Step two:
Suppose utilization rises from 50% to 99% in two hours. Simulate it step by step:
borrow and deposit rates, borrowers' incentive to repay, and depositors'
incentive to supply at each point. When should market forces turn it around?

Step three:
What happens if utilization reaches 100% and stays there? Describe the
conditions for depositors, borrowers, and the protocol, plus each intervention
available to the protocol and its cost.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check