Aave Borrow Rate Tuning: A Practical Guide

Aave’s borrow rate model is one of the most mathematically elegant mechanisms in decentralized lending. It dynamically adjusts interest based on utilization, discouraging over-borrowing while promoting capital efficiency. Yet elegance can be unforgiving: the model is highly sensitive to parameter choices — especially in forks — where a “small” tweak can reshape the entire curve.

If you’re shipping or forking an Aave-style market, here’s what you’ll learn in the next 30 minutes:

• Understand how Aave’s variable borrow-rate model works — both mathematically and in code.
• See simulations that reveal misconfigurations capable of freezing markets.
• Identify systemic risks when forking Aave or changing parameters without full context.
• Apply practical, holistic checklists and recommendations to evaluate borrow-rate configurations.

TL;DR

Our analysis highlights a critical insight: parameter tuning in interest-rate models is not a trivial task. Even a mathematically sound model like Aave’s can behave harmfully if its configuration is misunderstood, copy-pasted, or tweaked without grasping the implications.

Recommendations for Auditors

• Check for parameter sanity: Validate that $U_{opt}\in (0,1)$ and that all slopes are within reasonable economic bounds. Be cautious of extreme values like $slope$ > 1000% or $r_{base}$ > 100%.
• Simulate before signing off: Edge cases are not always visible through code alone. Simple simulations can reveal cliffs, inversions, or plateaus in the rate curve.
• Look for economic consistency: Ensure that the model aligns with supply-demand logic. If higher utilization results in lower rates, that’s a red flag.

Recommendations for Developers (Especially on Forks)

• Don’t blindly copy parameters: A change from $U_{opt}=0.8$ to $U_{opt}=0.99$ may seem minor, but can multiply the post-optimal slope effect by 20×.
• Test unusual utilization regimes: Validate behavior at very low and very high utilization, not just around the target range.
• Document the intention: If you choose non-standard parameters, explicitly state the rationale. This aids future audits and protects against misconfiguration.

In many Aave forks, teams tweak a single parameter to “optimize” behavior without seeing the second-order effects. That’s deceptively dangerous.

A small change in one parameter, like optimalUtilization, impacts the entire shape of the interest rate curve. Changing $U_{opt}$ from 80% to 99% means that the denominator in the $slop{e}_2$ term shrinks from 20% to 1%, multiplying the slope effect by 20×. What was once a gradual increase becomes a vertical wall.

Seemingly safe settings — like flat pre-optimal regions or low $slop{e}_1$ — can hide risk until the protocol hits a hard cliff.

Borrow Rate Model: Stable vs Variable Rates

Aave offers borrowers two interest rate options: Variable and Stable. When borrowing, users actively choose between these two models. Both rate types operate simultaneously within the same pools, with users able to switch between them based on market conditions and personal risk tolerance.

In our analysis, we focus exclusively on the Variable Rate mechanism.

Variable Borrow Rate

In Aave V3, the variable borrow rate (the rate paid by users who borrow assets) is dynamically adjusted based on the current utilization of the reserve.

This rate is computed inside the DefaultReserveInterestRateStrategy contract, specifically in the calculateInterestRates() function.

The logic is piecewise, depending on whether the utilization is below or above a configured threshold called the optimal usage ratio.

Source: DefaultReserveInterestRateStrategy.sol 

At a glance, this looks like two formulas joined together. But what does it really do?

Aave calculates how much of the lending pool is currently in use. This is called the borrow usage ratio, or simply the utilization.

Then the protocol decides how much interest to charge borrowers based on this value:

• If utilization is low or moderate (e.g., 40% or 70% out of 100%), the borrow rate increases gradually - like a gentle slope. This makes borrowing affordable and helps the market operate normally.
• But if utilization becomes high (goes above the optimal threshold), the rate increases much faster.

Example:

Let’s say:

• The optimal utilization is 80%
• The borrow rate at 80% is 4%
• The slope after that is steep

If someone takes a large loan that pushes utilization from 80% to 90%, the borrow rate could suddenly jump from 4% to 30% or more, depending on the slope. This makes borrowing extremely expensive, which discourages further borrowing and signals that the pool is under pressure.

Mathematical model:

Let:

• $U$= utilization =  $\frac{B}{B+L}$
  where B is the borrowed amount and L is the available liquidity.
• $r_b(U)$ = variable borrow rate
• $r_{base}$ = base rate (a constant)
• $slop{e}_1,slop{e}_2$ = slopes before and after the optimal point

$U_{opt}$ = optimal usage ratio

Then:

If $U\le U_{opt}$:

$r_b(U)=r_{base}+slop{e}_1\ast (\frac{U}{U_{o}pt})$

If $U>U_{opt}$:

r_b(U) = $r_{base}+slop{e}_1+slop{e}_2\ast ((U-\frac{U}{U_{opt}})/(1-U_{opt}))$

Let’s now visualize this formula using a common configuration:

• $U_{opt}$ = 0.8 (i.e., 80% optimal utilization)
• $r_{base}$ = 2%
• $slop{e}_1$= 4% (slow increase before 80%)
• $slop{e}_2$ = 100% (aggressive increase after 80%)

The graph below shows how the borrow rate responds as utilization increases from 0% to 100%.

Borrow rate curve with a kink at 80% utilization.

We have now seen how the variable borrow rate is defined mathematically as a piecewise linear function. Let’s return to the relevant Solidity code mentioned above.

This if statement splits the logic exactly like our formula:

Case 1: borrowUsageRatio ≤ OPTIMAL_USAGE_RATIO

Case 2: borrowUsageRatio > OPTIMAL_USAGE_RATIO

The Solidity implementation maps directly to the piecewise formula we discussed earlier. The use of Ray math (i.e., rayMul and rayDiv) is simply for precision; internally, all values are scaled by 1e27.

This clear correspondence between the math and the code is what makes this model both predictable and auditable, but as we’ll see in the next section, small changes in parameters can lead to extreme behaviors under certain edge conditions.

Borrow Rate Edge Cases: Sensitivity to Parameter Configuration

In this section, we simulate how a poorly chosen interest rate configuration, particularly an excessively steep $slop{e}_2$, can lead to unintended consequences. Specifically, it can create a situation where the lending pool becomes effectively frozen, with no incentive for liquidity providers to deposit and no viable way for borrowers to repay.

Even well-designed interest rate models can be dangerous when misunderstood or misconfigured.

In this section, we simulate multiple edge cases that demonstrate how a single parameter change in Aave’s borrow rate model can lead to catastrophic outcomes. These examples are based on the exact mathematical model described earlier and show what happens when forks or custom deployments tamper with the parameters.

Edge Case 1: Extremely Low Optimal Utilization ($U_{opt}=10$)

Config: $U_{opt}$ = 10%, $slop{e}_1$ = 4%, $slop{e}_2$ = 50%, $r_{base}$ = 2%

• Math:
  • $U$ = 10%: $r$ = 6%
  • $U$ = 50%: $r$ ≈ 28.2%
  • $U$ = 90%: $r$≈ 50.45%

Edge Case 2: Extremely High Optimal Utilization ($U_{opt}=99$)

Config: $U_{opt}$ = 99%, $slop{e}_1$ = 4%, $slop{e}_2$ = 200%, $r_{base}$ = 2%

• Math:
  • $U$ = 99%: $r$ = 6%
  • $U$ = 99.5%: $r$ ≈ 106%

Implication: The system behaves normally until it suddenly freezes. This is dangerous for high-demand assets.

Edge Case 3: Inverted Slopes ($slop{e}_1>slop{e}_2$)

• Config: $slop{e}_1$ = 50%, $slop{e}_2$ = 10%, $U_{opt}$ = 80%, $r_{base}$ = 2%

• Math:
  • $U$ = 50%: $r$ = 33.25%
  • $U$ = 79%: $r$ ≈ 51.375%
  • $U$ = 90%: $r$ ≈ 57%

• Implication: Lower borrowing cost beyond the optimal point. Incentivizes over-borrowing.

Edge Case 4: Flat Pre-Optimal Rate ($slop{e}_1=0$)

• Config: $slop{e}_1=0,slop{e}_2=100$
• Math:
  • $U$ < 80%: $r$ = 2%
  • $U$ = 90%: $r$ ≈ 52%

• Implication: Sudden cliffs at $U_{opt}$. Users receive no warning.

Edge Case 5: Extreme Slopes

• Config: $slop{e}_1=200$

• Math:
  • $U$ = 10%: $r$ = 27%
  • $U$ = 50%: $r$ = 127%
  • $U$ = 90%: $r$ = 452%

• Implication: Protocol is unsustainable even with minimal usage.

Edge Case 6: Near-Zero Optimal Utilization ($U_{opt}=1$)

• Config: $U_{opt}=1$

• Math:
  • $U$ = 2%: $r$ ≈ 7.01%
  • $U$ = 50%: $r$ ≈ 55.49%

• Implication: Pool spikes with minimal borrowing. Appears safe but punishes instantly.

Mathematically Invalid or Dangerous Configurations

Edge Case 7: Slopes > 1000%

• Config: $U_{opt}=80$

• Math:
  • $U$ = 10%: $r$ = 127%
  • $U$ = 90%: $r$ = 3502%

Implication: The protocol becomes unusable almost immediately due to excessively steep rate escalation, rendering the system economically nonviable.

Edge Case 8: Base Rate = 200%

• Config: $U_{opt}=80$

• Math:
  • $U$ = 0%: $r$ = 200%
  • $U$ = 90%: $r$ = 229%

Implication: Interest accrues even when idle. The protocol is unusable.

Edge Case 9: All Parameters Extreme

• Config: $r_{base}=100$

• Math:
  • $U$ = 10%: $r$ = 2626%
  • $U$ = 50%: $r$ = 6837%

Implication: Destructive behavior. Even minimal borrowing drives the rate into thousands of percent, instantly disincentivizing usage.

Real-World Cases of Interest Rate Parameters Configurations Issues in Aave

USDT Utilization Spike (November 2022): Aave V2’s USDT market reached over 95% utilization, creating a high risk of liquidity lock for suppliers. Governance responded with an emergency adjustment, lowering the Optimal Utilization from 90% to 80% and increasing $slop{e}_2$ from 60% to 75% to encourage liquidity return and reduce the likelihood of “stuck” markets.

Stablecoin Borrow Rate Adjustment (November 2024): Governance proposed raising $slop{e}_1$ to 9.5% for all stablecoins across Aave V3 to align borrowing rates with market conditions better. The goal was to increase protocol revenue and improve liquidity incentives, addressing imbalances caused by overly conservative initial parameters.

Conclusion

A well-audited protocol like Aave can become fragile the moment a fork changes a single value without simulating its long-tail behavior. Even minimal parameter tweaks must be reviewed as a complete system — not treated as trivial variants or narrow-scope changes. Each adjustment can propagate through interest-rate dynamics, liquidation mechanics, and user incentives, introducing systemic fragility that isn’t obvious at first glance.

Need a second set of eyes? Our security researchers can run rate-curve simulations, parameter sanity checks, and economic stress tests before you ship. Explore Hacken services →