Moving Average vs Spot Utilization Rate Models

Predictability & Stability: Smooths out short-term volatility in utilization, preventing rate spikes from flash loan attacks or temporary arbitrage. This matters for long-term depositors and borrowers seeking predictable costs.

Slower Market Response: Lags behind real-time supply/demand shifts. During sustained high utilization, rates may remain artificially low, risking insolvency if reserves are drained before rates adjust. This matters for risk managers.

Real-Time Market Signals: Rates adjust instantly to current pool utilization, providing accurate price discovery. This matters for arbitrageurs and active liquidity providers who need immediate feedback.

High Volatility & Manipulation Risk: Rates can spike dramatically from a single large transaction, creating liquidation cascades or making borrowing prohibitively expensive. This matters for protocol stability and user experience.

Smooths volatility: Uses a time-weighted average (e.g., 24-hour window) to dampen the impact of short-term liquidity spikes. This provides predictable borrowing costs for users and stable revenue projections for lenders. This matters for structured products and risk management where rate stability is more critical than perfect market alignment.

Harder to game: A sudden, large deposit or withdrawal has a diluted effect on the calculated rate, making it expensive and inefficient for actors to manipulate rates for short-term gain (e.g., to trigger liquidations). This matters for protocols with lower TVL or in early stages where market depth is a concern.

Delayed repricing: The model inherently lags behind real-time market conditions. During rapid market moves (e.g., a bank run scenario or a sudden surge in demand), rates may not adjust quickly enough, leading to temporary interest rate arbitrage or inefficient capital allocation.

Introduces complexity: Requires careful selection of the averaging window (e.g., 1hr vs 24hr) and update frequency. A poorly chosen window can make the model either too sluggish or too reactive. This matters for protocol architects who must now manage and potentially govern an additional layer of economic parameters.

Real-time market efficiency: Rates are calculated based on the exact, instantaneous utilization of the pool. This ensures the cost of capital always reflects the current supply/demand equilibrium, optimizing for capital efficiency and immediate lender yield in highly liquid markets.

High volatility and gaming surface: Rates can swing wildly with single large transactions, creating a poor user experience for borrowers and making yield unpredictable for lenders. This is a significant vulnerability for protocols susceptible to flash loan attacks or whale manipulation.

Smooths volatility: Uses a time-weighted average (e.g., 24h TWAP) of utilization, preventing rate spikes from single-block arbitrage or flash loan events. This creates predictable costs for borrowers (e.g., Aave's stable borrow rates) and steady yields for lenders, which is critical for long-term treasury management and structured products.

Introduces response lag: The model is slow to react to genuine, sustained shifts in market demand. During rapid market moves, rates may remain artificially low (under-charging risk) or high (over-charging), leading to suboptimal capital allocation and creating arbitrage opportunities against the protocol. This is a trade-off for stability.

Maximizes capital efficiency: Rates update per block based on real-time utilization (e.g., Compound v2, many DEX pools). This ensures the cost of capital instantly reflects current supply/demand, enabling precise price discovery and eliminating the lag that can lead to stale pricing. Ideal for highly volatile or nascent markets where speed is paramount.

Exposed to oracle and flash loan attacks: A malicious actor can borrow a large amount in a single block (via flash loan) to spike utilization, triggering extreme rate changes for other users or triggering liquidations, before repaying in the same transaction. This requires robust circuit breakers (e.g., utilization caps) and increases protocol risk engineering overhead.