Aave Interest Index System: Mechanics & Accounting Model

In the previous articles, we covered how Aave sets borrow rates from utilization and how those rates become depositor yield. Now we focus on the accounting layer: how Aave accrues interest over time without updating every user’s balance on every block.

We break down Aave’s interest index system – the Liquidity Index and Variable Borrow Index – how they accrue, when they update, and the edge cases forks often get wrong.

Part 1 – Aave Borrow Rate Tuning (Practical Guide)

Part 2 – Aave Liquidity Rate Mechanics (Economic & Security Implications)

TL;DR

• Aave stores user positions in scaled units and applies interest via indexes.
• Suppliers: actual balance = scaled aToken balance × liquidityIndex
• Variable borrowers: actual debt = scaled variable debt × variableBorrowIndex
• Indexes update using rate + time delta. In Aave-style codebases, supplier-side normalized income is often computed using linear interest × liquidityIndex (while variable debt typically compounds).
• Bugs around timestamps, caching, rounding, and update order change who gets paid – and who eats the deficit.

What Are the Indexes?

Liquidity Index (aTokens / suppliers)

The Liquidity Index applies to depositors and reflects how much interest their aToken balance has earned over time. It is shared globally across all depositors for a given reserve and increases linearly based on the liquidityRate. Whenever any operation affects the reserve – such as deposit, withdrawal, borrow, or repay – the index is updated using the elapsed time since the last update and the current rate. 

We build upon the Aave Liquidity Rate graph introduced in the previous article, Aave Liquidity Rate Mechanics: Economic & Security Implications, by adding trigger events and visualizing how the Liquidity Index evolves over time in response to those events.

Liquidity Rate vs Utilization and Liquidity Index Over Time with Triggers

Variable Borrow Index (variable debt / borrowers)

The Variable Borrow Index is the corresponding index for borrowers using variable interest rates. It is also global per reserve but grows using compounded interest based on the variableBorrowRate. Each borrower also stores a user-specific snapshot of the index.

Like the liquidity index, it is updated on any reserve-changing action. The actual debt of a borrower is derived by multiplying their scaled debt by the current variable borrow index.

We will build on the borrow rate graph introduced in Aave Borrow Rate Tuning: A Practical Guide, using it as a foundation to illustrate how the Variable Borrow Index evolves over time in response to changes in the borrow rate and trigger-based updates.

Growth Of Variable Borrow Index With Labeled Trigger-Based Updates

In contrast, borrowers with stable rates do not use a global index. Instead, each stable-rate borrower has an individual stored rate and timestamp and is updated only during specific user actions such as borrowing more, repaying, or rebalancing.

Mathematical Basis: Linear vs Compound Accrual

Below, we start with the two interest functions (linear vs compounded), then map each one to the exact update path used for indexes.

In Aave’s default model, the Liquidity Index grows linearly (gas-efficient, supplier side), while the Variable Borrow Index grows using compounded interest (borrower side). The asymmetry is intentional.

Linear:

$LiquidityInde{x}_t=LiquidityInde{x}_{t-1}\times \left(1+r_{liquidity}\times \frac{\Delta t}{SECONDS\_PER\_YEAR}\right)$

Compound:

$VariableBorrowInde{x}_t=VariableBorrowInde{x}_{t-1}\times \left(1+r_{borrow}\times \frac{\Delta t}{SECONDS\_PER\_YEAR}+\frac{1}{2}{\left(r_{borrow}\times \frac{\Delta t}{SECONDS\_PER\_YEAR}\right)}^2+\frac{1}{6}{\left(r_{borrow}\times \frac{\Delta t}{SECONDS\_PER\_YEAR}\right)}^3\right)$

Both indices are updated simultaneously in the core update function:

Source: ReserveLogic.sol 

The linear interest calculation implements the mathematical formula exactly:

Source: MathUtils.sol 

This directly implements:

Where:

$rate=r_{liquidity}$ (current liquidity rate)

$\Delta t=block.timestamp-lastUpdateTimestamp$

$SECONDS\_PER\_YEAR=31,536,000$ (365 days)

$WadRayMath.RAY=10^{27}$ (representing 1.0 in ray precision)

The compound interest calculation uses a binomial approximation to avoid expensive exponentiation:

Source: MathUtils.sol 

This implements the binomial approximation of $(1+x{)}^n$:

Where:

$x=\frac{rate\times \Delta t}{SECONDS\_PER\_YEAR}$ (the rate per time period)

$n=\Delta t$ (time delta in seconds)

First term: $1=WadRayMath.RAY$ (1.0)

Second term: $\frac{rate\times exp}{SECONDS\_PER\_YEAR}$ (linear component)

Third term: $secondTerm$ (quadratic component with $\frac{1}{2}$ coefficient)

Fourth term: $thirdTerm$ (cubic component with $\frac{1}{6}$ coefficient)

Implications for Security and Precision

Understanding Aave's default implementation is only the first step. Many forks modify the interest calculation models to optimize for different priorities – lower gas costs, simplified math, or different economic models. However, even small changes can have profound security implications.

This section examines the most critical modifications seen in production forks and analyzes their security and economic trade-offs. Each modification represents a decision point where protocol designers must balance competing priorities: gas efficiency, mathematical accuracy, economic safety, and user experience.

Linear vs Compound Interest Changes

Default Aave – linear for lenders, compound for borrowers. This asymmetry is intentional and serves multiple purposes:

• Creates a built-in safety buffer (borrowers pay slightly more than lenders earn).
• Reduces gas costs for the most common operations (deposits/withdrawals).
• Balances precision with practicality.

However, forks often modify this model. Let's examine the implications:

Compound for Both:

• Mathematical symmetry: Accruals on both sides are internally consistent over time.
• Gas inefficiency: Compound interest (with multiple terms) is computationally heavier than linear.
  • Aave's current compound index with 3-term binomial expansion costs ~8,000 gas more per update than calculateLinearInterest.
  • Since indexes update on every reserve-changing transaction (deposit, withdraw, borrow, repay), this leads to significant cumulative gas costs.

Linear for Both:

• Loss of exponential growth: Compound(5%, 5y) = 1.276, Linear(5%, 5y) = 1.25 – Underestimation grows with time and rate.
• Weakened safety assumptions:
  • Borrowers accrue debt more slowly than expected.
  • In high-volatility events, debt may be under-represented, reducing liquidation incentives and increasing protocol insolvency risk.
• Gas savings: Linear interest requires only one multiplication and division.

Reversed Model (Compound for Lenders, Linear for Borrowers):

Liquidity index uses compound, borrow index uses linear.

Why it fails: every time protocol owes more to depositors than it collects from borrowers.

Result: protocol shortfall unless subsidized by external capital

Binomial Approximation Modifications

Aave's 3-term approximation balances accuracy and gas costs.

But forks often experiment with different precision levels:

2-Term Approximation (Linear + Quadratic Only)

• Accurate for short periods and moderate rates.
• Saves gas vs full exponentiation.
• Error increases with large t or r.

Security implications:

• Acceptable for most normal scenarios (rates < 30%, frequent updates).
• Risk during extreme events: if updates are delayed during network congestion and rates spike, errors compound.
• Could lead to slight underpayment to depositors or slight overpayment by borrowers (direction depends on rounding).

Full Exponential Model: 

 

• Most accurate.
• Very expensive to compute on-chain.
• Accrual is precise, but diverges from lender linearity unless a symmetrical model is adopted.
• Requires high-precision math library and gas optimizations (e.g., precomputed lookup tables or approximation algorithms like rpow).

Precision Model Changes

Aave Standard: Ray precision (1e27), uint128 storage. This design choice is carefully calibrated for the protocol's requirements:

• Minimize rounding errors in compounding.
• Keep index values within bounds to avoid overflow.

Why 1e27 (Ray precision)?

• Provides 27 decimal places of precision
• Sufficient for accurate compounding over decades
• Allows rates from 0.0000001% to 1,000,000% APR

Minimizes rounding errors when multiplying indexes by balances.

Why uint128 storage?

• Reduces storage costs (2 indexes fit in one storage slot)
• Provides maximum value of ~3.4 × $10^{3}8$
• At 10% compound APR, takes ~300 years to overflow from initial value of 1e27
• Safe under all realistic scenarios

Now let's examine what happens when forks modify this precision model:

Full uint256 storage:

• Removes upper bounds – safer against overflow.
• Increases SSTORE gas cost.
• All internal math must handle larger intermediate values.
• Rounding logic must be revised.

1e18 precision (1e18):

• Same as ERC20 token decimals.
• Reduces gas and simplifies interactions with token balances.
• Insufficient for accurate long-term compounding.

Custom precision (e.g., 1e24, 1e30):

• A compromise between Ray and Wad.
• Must carefully design: multiplication/division rounding, safe scaling across operations.

Key Insights

• The asymmetry is intentional: Linear interest for lenders and compound interest for borrowers creates a built-in safety buffer that protects the protocol from insolvency while keeping operations gas-efficient.
• Precision matters over time: Small differences in interest calculation models become large differences over months and years. A protocol that seems to work fine in testing may develop critical imbalances after a year in production.
• Gas efficiency vs. Accuracy trade-off: Every modification to the interest model involves trade-offs. More accuracy costs gas; less accuracy risks economic exploits. Aave's choices represent a well-tested middle ground.
• Mathematical symmetry is critical: The relationship between liquidity index and borrow index must maintain balance. Any configuration where depositors earn more than borrowers pay will eventually bankrupt the protocol.

Conclusion

Aave’s index model ensures consistent accounting between lenders and borrowers by maintaining a careful balance between mathematical precision and gas efficiency.

Forks modifying index logic must validate that both accrual and repayment remain balanced across time and usage. Without aligned formulas and precision, small changes can lead to protocol imbalance, fund leakage, or unsafe liquidation behavior. All modifications must be tested holistically under long-term scenarios.