What Is an Interest Rate Model?

Introduction

Interest rate model is the mechanism a DeFi lending protocol uses to decide what borrowers pay and what suppliers earn at any moment. That may sound like a narrow implementation detail, but it is actually the part of the system that keeps a lending pool usable: if borrowing stays too cheap when liquidity is scarce, the pool can be drained; if borrowing becomes too expensive too quickly, demand disappears and capital sits idle. The model’s job is to continuously push the market back toward a workable balance.

This is why DeFi lending protocols such as Compound and Aave put so much design effort into rate curves. In a traditional credit market, rates are often negotiated, administered, or set through a mix of institutional funding costs and policy benchmarks. In an on-chain lending pool, there is usually no loan officer and no central treasury desk repricing each loan by hand. The protocol needs an automatic rule that can look at current pool conditions and turn them into a price for liquidity.

The core idea is surprisingly simple: when a large share of a pool is already borrowed, borrowing should get more expensive. That higher rate does two things at once. It discourages additional borrowing, and it rewards suppliers more, which can attract fresh liquidity. When utilization falls, the opposite happens: rates soften, borrowing becomes more attractive, and idle capital becomes easier to put to work. Most DeFi interest rate models are variations on this feedback loop.

The details, however, matter a great deal. A protocol has to choose what variable represents market tightness, how sharply rates should rise, whether the curve should have a breakpoint, how interest actually accrues on-chain, and who is allowed to change the parameters later. Those choices affect capital efficiency, liquidation risk, protocol revenue, and resistance to manipulation.

What problem does an interest rate model solve in a DeFi lending pool?

A lending pool has a structural tension built into it. Suppliers want their assets available for withdrawal and want to earn yield. Borrowers want reliable access to liquidity at a reasonable cost. Those goals are compatible only if the protocol can keep enough unborrowed cash in the pool while still making supplied capital productive.

If rates were fixed forever, the pool would often be in the wrong state. Suppose borrowing demand suddenly surges because traders want leverage or because a stablecoin becomes useful elsewhere in DeFi. With a fixed low rate, borrowers keep taking funds until liquidity becomes thin. Existing suppliers may still see a modest yield, but the real problem is that the pool has lost flexibility: withdrawals become harder to satisfy, and liquidations can become more fragile because everyone is competing for the same scarce base asset.

Now flip the situation. Suppose demand collapses. If the borrow rate remains high, nobody wants to borrow, so suppliers earn very little in practice because most of the pool is idle. Capital is safe but economically unproductive. In both cases, the issue is not that the rate is “wrong” in some abstract sense. It is wrong for the current balance of supply and demand.

An interest rate model solves this by making the price of borrowing endogenous to pool state. Rather than asking, “What should USDC cost this month?” the protocol asks, “Given how much cash is left and how much has already been borrowed, what rate will best balance this market now?” That is the compression point: the model is less about forecasting the economy than about controlling pool utilization.

What is utilization in a lending pool and how is it calculated?

Most DeFi lending protocols compress the pool’s condition into a single number called utilization. The exact formula depends on the protocol version, but the idea is consistent: utilization measures what fraction of supplied liquidity is currently in use.

In Compound’s original formulation, utilization U is defined from borrowed assets relative to total available assets in the market. In the whitepaper’s notation, that is borrowed amount divided by cash plus borrows. In the on-chain JumpRateModel implementation, reserves are also accounted for in the denominator, so the function is effectively borrows / (cash + borrows - reserves), scaled for fixed-point arithmetic. Compound III developer docs express the same idea a bit differently as TotalBorrows / TotalSupply. These formulas differ at the margins because implementations differ, but they all try to answer the same question: how full is this lending market?

Why is utilization such a useful variable? Because it captures the thing the protocol actually cares about operationally: available slack. A pool at 20% utilization has lots of idle liquidity. A pool at 95% utilization is close to fully lent out. That does not merely describe supply and demand; it summarizes their interaction in a way the protocol can react to immediately.

There is an important intuition here. Utilization is not a market-clearing price discovered externally. It is a state variable internal to the pool. The protocol observes it directly on-chain, without needing a survey of lender sentiment or borrower preferences. That makes it attractive for smart-contract systems: it is objective, computable, and updated as users act.

The limitation is that utilization is only a proxy. Two markets can both show 90% utilization while having very different reasons for being there. In one, demand may be stable and healthy. In another, liquidity may be fleeing because users distrust the asset. The interest rate model usually cannot tell the difference. It responds to the same utilization number either way.

How do protocols convert utilization into a borrow rate?

Once a protocol has utilization, it needs a rule that maps that number into a borrow rate. The simplest possible rule is a line: as utilization rises, the borrow rate rises.

Compound’s whitepaper gives an illustrative example in that spirit: a borrowing interest rate that looks like 10% + U * 30%. The exact numbers there are not universal defaults; they are an example of a demand curve. But the logic is general. There is a base rate even when utilization is low, and then there is a slope telling you how much more expensive borrowing becomes as the pool gets busier.

This linear design already creates the desired feedback. If the pool is underused, rates remain relatively low, which encourages borrowing. As more funds are borrowed, the rate climbs, making the next unit of borrowing less attractive. The pool resists becoming fully drained because the marginal cost of borrowing keeps increasing.

But a purely linear model has a weakness. In practice, many protocols are comfortable with fairly high utilization up to a point. Idle liquidity is expensive too: it means suppliers are not earning much and capital efficiency is poor. What protocols often want is not “keep utilization low,” but rather “keep utilization near a target zone, then punish scarcity hard if the pool goes beyond it.”

That is why modern DeFi lending markets often use a kinked or jump model instead of a single straight line.

Why do many lending protocols use a kinked (jump) interest-rate curve?

A kinked model has two regimes.

Below some utilization threshold rates rise with one slope.

• the kink or
• in Aave’s language
• the optimal utilization rate

Above that threshold, rates rise faster with a steeper slope.

This shape expresses a specific economic view. Up to the target utilization, the protocol is willing to trade some liquidity slack for better capital efficiency. Suppliers want their funds earning yield, and borrowers want low enough rates to make loans useful. So below the kink, the rate curve is relatively gentle. But once utilization moves past the target, the pool is entering a danger zone: withdrawals become harder to serve, liquidations may need scarce liquidity, and the protocol wants to restore slack quickly. So above the kink, borrowing gets expensive much faster.

Compound’s JumpRateModel makes this explicit. It stores a kink, a multiplierPerBlock for the normal region, and a jumpMultiplierPerBlock for the high-utilization region. If utilization is at or below the kink, the borrow rate follows the base rate plus the regular slope. If utilization is above the kink, the model first computes the rate at the kink, then adds a steeper increment for the excess utilization beyond that point.

Aave v2 implements the same broad idea as a two-slope model. Its reserve interest strategy is based on one slope before OPTIMAL_UTILIZATION_RATE and another slope from there to 100% utilization. Below the optimal point, the variable borrow rate increases proportionally with utilization. Above it, the rate adds the first slope and then accelerates with the second slope using the excess utilization ratio.

These protocols differ in naming and code structure, but the economic mechanism is the same. The kink is a policy choice: it says, “This is roughly where we want the market to sit.” Below it, borrowing is encouraged. Above it, scarcity is penalized.

A worked example makes this concrete. Imagine a stablecoin pool with a kink at 80% utilization. At 50% utilization, plenty of cash remains in the pool, so the borrow rate might be modest. Traders can use leverage, arbitrageurs can borrow for short periods, and suppliers still earn something because half the capital is in use. Now suppose a market shock pushes utilization to 92%. At that point, the protocol is no longer mainly optimizing for efficiency. It is defending liquidity. The steeper post-kink slope makes new borrowing much more expensive, some existing borrowers unwind because the carry cost is too high, and the higher lender yield can attract fresh deposits. The pool is being pulled back from the edge by price.

How is supplier yield (APY) derived from borrower rates and reserves?

Borrowers pay the gross interest entering the system, but suppliers do not simply receive the same rate. A supplier only earns on the portion of the pool that is actually borrowed, and the protocol may also keep a cut.

Compound’s whitepaper states this clearly: the supply interest rate is a function of the borrowing rate, utilization, and a spread S retained by the protocol. In simplified form, that relationship is supply rate = borrow rate U (1 - S). Compound’s newer implementations express the same mechanism through a reserve factor. In JumpRateModel, the supply rate per block is computed from utilization multiplied by the borrow rate after adjusting for 1 - reserveFactor.

The intuition is straightforward. If borrowers are paying 10% but only half the pool is borrowed, the pool as a whole is not earning 10% on all supplied capital. It is earning something closer to 5% before reserves, because only 50% of funds are deployed to borrowers. Then the reserve factor takes another slice for protocol reserves.

This leads to an important invariant: supplier yield must come from borrower payments, net of the protocol’s cut. It cannot sustainably exceed that source of cash flow unless the protocol adds outside subsidies such as token incentives. That is why lending yield is often called one of DeFi’s more organic yield sources. The return is funded by borrowers paying for liquidity.

It also explains why the spread matters. The reserve factor or spread is not just protocol profit in a cosmetic sense. It is part of the market’s safety design. Reserves can absorb losses or support protocol operations. But if governance sets the reserve factor too aggressively, suppliers become less willing to provide liquidity. If it sets it too low, the protocol may earn too little to build reserves. The model therefore prices not only loans, but also the division of economic surplus between suppliers and the protocol.

How do DeFi protocols accrue interest on-chain without updating every user account?

A subtle but crucial piece of an interest rate model is not just the curve, but the accounting method used to apply interest over time. A lending protocol may have thousands of suppliers and borrowers. It cannot rewrite every user balance every block or every second just to add a tiny increment of accrued interest. That would be far too expensive on-chain.

Compound’s solution, described in its whitepaper, is the Interest Rate Index. Instead of updating every account continuously, the protocol maintains market-level indexes that summarize how much supply-side and borrow-side balances should have grown since inception. When the market state changes, the index is updated by compounding the interest since the previous checkpoint. The paper gives the per-period update idea as Index_n = Index_(n-1) (1 + r t), where r is the per-block rate and t is elapsed time in blocks for that period.

A user’s balance then does not need to be stored as a fully current number after every moment of accrual. Instead, the system stores the user’s principal-like balance and the index value at the last time that account was touched. To compute the current balance, the protocol scales by the ratio of current index to checkpoint index. That is the mechanism behind statements like: a user’s balance, including accrued interest, is the ratio of the current index divided by the user’s stored index, applied to their stored balance.

The practical benefit is enormous. The protocol gets time-based compounding behavior while keeping storage writes localized. Market-level state changes frequently; account-level state changes only when the account interacts.

Compound III shifts the time basis from per-block to per-second accrual using the block timestamp. Its documentation specifies that supply and borrow interest accrue every second, and that returned rates are per-second values scaled by 10^18. The design choice is different, but the underlying problem is the same: interest must be accrued efficiently and deterministically from on-chain time.

This is one of the places where theory meets implementation. The interest-rate curve may look clean on paper, but the protocol still has to decide how to discretize time, what scale to use for fixed-point math, and how much approximation error is acceptable. In Compound’s JumpRateModel, annual-style constructor parameters are converted into per-block values by dividing by a fixed blocksPerYear constant. That is simple and predictable, but it is still an approximation.

Who sets interest-rate parameters and how does governance affect the model?

It is tempting to think of an interest rate model as pure code: a formula sitting on-chain, objectively running forever. In practice, parameter choice is governance.

Compound’s materials are explicit that the demand curve is codified through governance and can be updated. The whitepaper describes this initially in admin or Chief Economist terms; the later protocol design routes such changes through governance. Compound v2 governance docs state that a proposal can set a cToken’s interest rate model. Those changes go through proposal review, voting, and Timelock execution, so rate model updates are neither instant nor entirely autonomous.

Compound III docs similarly note that interest-rate parameters such as bases, slopes, and kinks are set by governance. Aave’s documentation and contract structure also point to governance-controlled strategy and parameter choices, even though the exact process depends on version and deployment. Morpho Blue takes yet another stance: market creation chooses an interest rate model from a governance-approved set, and its AdaptiveCurveIRM is designed to be immutable after selection.

The reason this matters is conceptual. The formula alone does not tell you the market’s future behavior. The same functional form can produce a conservative market or an aggressive one depending on the kink and slopes. A kink at 80% with a steep jump is a different policy from a kink at 95% with a mild jump. So when people ask whether a protocol’s rates are “algorithmic,” the precise answer is: the day-to-day rates are algorithmically computed, but the curve itself is usually a governed policy object.

That governance layer introduces both adaptability and risk. If conditions change, governance can tune the market. But poor parameter choices can make a pool brittle, uncompetitive, or attackable. Compound’s own whitepaper notes the sustainability requirement that total interest earned by suppliers must remain less than total interest paid by borrowers. This sounds obvious, but it underscores a broader point: parameterization is an economic security decision, not just a UI preference.

Static curves vs adaptive controllers: how do different interest-rate models compare?

Underneath the implementation details, there are two broad philosophies.

The first is the now-standard static utilization curve: pick a formula, choose the kink and slopes, and let rates respond mechanically to utilization. Compound and Aave are the clearest examples from the supplied material. This approach is simple, transparent, and easy to analyze. Users can inspect the curve and predict how rates will move if utilization changes.

The second is a more adaptive controller approach. Morpho Blue’s AdaptiveCurveIRM is a good example. Rather than keeping the entire curve fixed, it combines a short-term curve mechanism with an adaptive mechanism that shifts the whole curve over time by adjusting r90%, the rate at 90% target utilization. If utilization stays above target, the curve shifts upward; if utilization stays below target, it shifts downward; the speed of adjustment depends on how far utilization is from target.

This difference reflects a deeper design question: should the protocol assume that one manually chosen curve is usually enough, or should it try to learn and retune itself as conditions evolve? Static curves are easier to reason about and often more robust to manipulation because the controller is simple. Adaptive systems may improve capital efficiency and react better to changing markets, but they introduce a new control problem: how fast should adaptation happen, and how easy is it to push the controller around?

Recent research makes that trade-off explicit. Work such as AgileRate argues that static curves struggle to adapt to rapid market changes and proposes real-time adaptive controllers, while also acknowledging a trade-off between adaptivity and adversarial robustness. Reinforcement-learning-based proposals make a similar claim: rule-based models can be inefficient under changing conditions, but more adaptive systems raise operational and safety questions. These are not yet the industry default, but they show where design is heading.

What failure modes should you watch for in an interest rate model?

An interest rate model can fail in more ways than “the slope was badly chosen.” Some failures are economic, some are governance-related, and some come from accounting implementation.

The first economic failure is parameter misalignment. If the post-kink slope is too weak, utilization can stay pinned near 100%, leaving the pool illiquid for long periods. If it is too steep, ordinary temporary demand spikes can produce unusably high borrowing costs and make the market unstable. If the kink is set too low, the protocol sacrifices capital efficiency. If it is set too high, it may not defend liquidity soon enough.

The second failure is manipulability of the state variable. Utilization is observable and simple, but simplicity does not make it ungameable. Because rates depend on current pool composition, large actors can move utilization abruptly by borrowing or supplying size, especially in thinner markets. Static curves tolerate this to some degree because the rule is transparent, but any adaptive mechanism that learns from recent utilization may become more sensitive to strategic behavior.

The third failure is implementation and accounting error. The rate curve may be fine while the debt-accounting system around it is broken. The Alpha Homora V2 post-mortem is a good reminder here. The exploit described there centered on debt-share accounting and reserve-handling logic rather than the utilization curve itself, but the lesson is broader: lending-market safety depends on the full accounting stack. Interest accrual, debt shares, reserves, and permissions must preserve the intended invariants. If aggregate debt can drift out of sync with aggregate debt shares, pricing correctness alone will not save the system.

There is also a governance failure mode. Because many protocols can change their interest-rate parameters through proposals, users face policy risk. A market that is attractive today can become harsher after governance updates the reserve factor or changes the slope structure. Timelocks and public proposals help, but they do not eliminate the fact that the curve is a governed choice.

Finally, there is a modeling limit. Utilization-based models are local controllers for pool balance. They are not comprehensive models of credit risk, macro conditions, or market structure. They do not know whether borrowing demand is healthy hedging activity or panic leverage. They do not know whether suppliers are sticky long-term depositors or mercenary capital chasing a transient spread. They react to the visible symptom (utilization) because that is what is available on-chain.

Why are utilization-based interest rate models common across DeFi?

Despite those limitations, utilization-based interest rate models became the standard because they fit the constraints of blockchain systems unusually well. They are computationally cheap, transparent, and legible to users. They do not require private credit underwriting or off-chain committees to quote rates every hour. And they create a direct, automated connection between pool scarcity and price.

That is why the pattern appears across protocols and chains. Compound and Aave made it prominent in EVM lending. Solana’s SPL Token Lending explicitly describes itself as inspired by Aave and Compound, which signals the spread of the same design logic beyond one chain or one codebase. The exact formulas and parameter names vary, but the mechanism survives because the underlying problem is the same everywhere: a pool must price liquidity using on-chain state.

The model also matters beyond lending itself. Yield in lending markets depends directly on it, because supplier APY is derived from borrower rates, utilization, and reserve cuts. Liquidation dynamics are affected by it, because stressed markets often coincide with high utilization and expensive base-asset liquidity. Governance value is affected by it, because changing the curve changes protocol competitiveness and revenue. In that sense, the interest rate model is not a peripheral formula. It is the market’s operating system for liquidity.

Conclusion

An interest rate model in DeFi is the rule that turns pool state into prices for borrowing and supplying capital. Its central insight is simple: utilization is a good enough signal of liquidity scarcity to drive an automatic feedback system. When utilization rises, borrow rates rise; when utilization falls, rates soften. Kinks, reserve factors, and accrual indexes are refinements of that core mechanism.

What makes the topic worth understanding is that small design choices inside this rule have large consequences. They shape capital efficiency, withdrawal safety, lender yield, borrower cost, and protocol resilience. Tomorrow’s models may become more adaptive, but the basic challenge will remain the same: a lending pool needs a way to price liquidity from first principles, using the information it can actually observe on-chain.

How do you evaluate a DeFi lending or collateral market before using it or buying related tokens?

Interest Rate Model belongs in your lending-risk checklist before you take related exposure on Cube Exchange. Translate it into collateral risk, liquidation risk, and position sizing before you trade a protocol or governance token tied to that market.

1. Identify the lending protocol, token, or market you actually want exposure to.
2. Map Interest Rate Model to one concrete risk variable, such as liquidation distance, collateral efficiency, rate sensitivity, or rehypothecation risk.
3. Size the position assuming the credit model can behave badly during stress, not just in normal conditions.
4. Use a limit order when possible, review liquidity and spread, and only submit after the risk trade-off is acceptable.