Rate Update Mechanism

This defines the source of data used to trigger a rate update.

• On-Chain Oracles: Rates are updated based on data already available on the blockchain, such as a pool's utilization ratio or the price from an on-chain DEX. This is deterministic and trust-minimized.
• Off-Chain Oracles: Rates are updated based on data supplied by external oracle networks (e.g., Chainlink). This allows for incorporating real-world data like traditional interest rates but introduces a trust assumption in the oracle.

Mechanisms define when and why a rate recalculation occurs.

• Time-Based (Periodic): Updates occur at fixed intervals (e.g., every block, hourly). Example: Compound's borrow rate updates every block.
• Event-Based: Updates are triggered by specific on-chain actions, such as a deposit, withdrawal, or when a utilization threshold is crossed.
• Hybrid: A combination, such as a minimum time between updates with event-based triggers.

The core formula that translates input parameters (like utilization) into a new rate. Common models include:

• Linear Models: Simple, predictable increases.
• Kinked / Piecewise Models: Rates change more aggressively after a specific threshold (e.g., optimal utilization rate) to manage liquidity crises. Used by Aave and Compound.
• Exponential / Polynomial Models: Rates increase sharply to strongly disincentivize high utilization. The choice of model is a critical economic policy decision for a protocol.

Determines who can adjust the mechanism's settings.

• Immutable / Hard-Coded: The model and its parameters are fixed at deployment. Maximizes predictability but lacks adaptability.
• Governance-Controlled: Key parameters (like slope coefficients, optimal utilization, oracle addresses) are controlled by a DAO via governance votes. This is the most common design, balancing flexibility with decentralization.
• Admin / Multisig Control: A privileged address can update parameters. Faster to react but introduces centralization risk.

Features designed to prevent volatility and protect the system.

• Rate Smoothing (Averaging): The new rate is a weighted average of the old rate and the calculated rate, preventing abrupt jumps.
• Absolute Rate Caps: A hard-coded maximum limit a rate can reach, acting as a safety mechanism.
• Change Rate Limits (Speed Limits): Restricts how much a rate can increase or decrease in a single update period.

Rate updates rarely operate in isolation; they interact with other protocol systems.

• Liquidation Engines: High borrow rates increase the likelihood of positions becoming undercollateralized, triggering liquidations.
• Reward Emissions: In liquidity mining programs, reward rates (APR) are often updated based on pool weights and emission schedules set by governance.
• Fee Accrual: In AMMs, swap fee rates might be updated dynamically based on volume or volatility to optimize for LP profitability.

Updates occur at predetermined, regular intervals, creating a predictable schedule. This is common for protocols that need to refresh rates based on recent historical data.

• Example: A lending protocol may recalculate its utilization rate and corresponding interest rates every block or at the end of each epoch.
• Purpose: Ensures rates reflect the most recent market activity without requiring manual intervention.

An update is automatically executed when a specific on-chain metric crosses a predefined limit. This is a reactive mechanism for risk management.

• Example: A lending protocol's interest rate model may increase borrowing rates sharply if the pool's utilization rate exceeds 90%.
• Purpose: Acts as a circuit breaker to protect protocol solvency by disincentivizing further borrowing when liquidity is low.

Changes are proposed and voted on by the protocol's governance token holders or a delegated committee. This is used for strategic parameter adjustments.

• Example: A DAO votes to change the reward emission rate for a liquidity mining program or to adjust fee parameters in a DEX.
• Purpose: Allows for community-driven, strategic evolution of the protocol's economic policy.

Key parameters are updated based on fresh data supplied by a decentralized oracle network. This links on-chain rates to real-world or cross-chain data.

• Example: A synthetic asset protocol updates its collateralization ratio requirements based on a new price feed from Chainlink.
• Purpose: Ensures protocol parameters remain accurate and secure by relying on verified external data sources.

Compound uses a hybrid model combining time-based and threshold-based triggers.

• Time-Based: The borrow rate for each asset is recalculated and compounded every Ethereum block (~12 seconds).
• Threshold-Based: The specific rate applied is determined by a piecewise formula that reacts to the asset's current utilization rate.
• This creates a dynamic, automated system where rates are continuously and predictably updated in response to market conditions.

MakerDAO's Stability Fee (a form of interest rate on DAI debt) is updated via a purely governance-driven process.

• Process: The Maker Governance community votes on Executive Votes to approve changes to the fee, which are then executed after a formal delay.
• Frequency: Updates are irregular, occurring only when MKR holders deem an economic adjustment necessary based on market conditions and DAI's peg stability.
• This demonstrates a manual, deliberative approach to rate setting for a core system parameter.

A decentralized governance model where token holders vote on proposed rate changes. This ensures changes reflect community consensus but can be slow and subject to voter apathy or manipulation.

• Examples: Compound's COMP token holders vote on borrowRateModel updates.
• Security: Relies on the security of the governance token and voting mechanism.

Rates are updated automatically by on-chain code based on predefined formulas and real-time protocol metrics (e.g., utilization rate, collateral ratios). This removes human latency and bias.

• Core Mechanism: Uses a rate model function, often a kinked or linear model, where the rate is a function of utilization = totalBorrows / totalSupply.
• Example: Aave's interest rate model algorithmically adjusts rates between a baseRate and a maxRate based on pool utilization.

Rate changes are triggered by data supplied by oracles. This is common for protocols pegging rates to external benchmarks like the Secured Overnight Financing Rate (SOFR) or other real-world financial indices.

• Security Critical: The mechanism's security is directly tied to the oracle's reliability and decentralization. A compromised oracle can manipulate rates to destabilize the system.
• Process: An off-chain keeper or the oracle itself calls a permissioned function to sync the on-chain rate with the latest external data.

A critical security feature where approved rate changes are queued and only executed after a mandatory delay. This gives users time to react to upcoming changes and provides a last line of defense against malicious governance attacks or admin key compromises.

• Function: queueTransaction() → executeTransaction() after delay.
• Economic Impact: Prevents surprise changes that could trigger immediate liquidations or arbitrage cascades.

Poorly designed mechanisms create vulnerabilities:

• Governance Attacks: An attacker acquires enough tokens to pass a malicious rate change, potentially draining funds.
• Oracle Manipulation: Feeding false data to trigger incorrect rate updates for profit (e.g., causing unjust liquidations).
• Parameter Shock: A sudden, large rate change can cause mass liquidations or a "bank run" on deposits, destabilizing the protocol.

A core design trade-off. High-frequency updates (e.g., per block) keep rates perfectly aligned with market conditions but can be volatile. Infrequent updates (e.g., weekly) provide stability and predictability but can lead to arbitrage opportunities and rates being "stale" versus the true market.

• Smoothing Functions: Some protocols use moving averages or rate change caps per period to mitigate volatility while maintaining responsiveness.

A pre-programmed, formula-based mechanism that automatically adjusts rates based on real-time on-chain data, minimizing governance overhead.

• Utilization Rate: A core input; as borrowing demand (utilization) for an asset increases, its borrow rate typically rises.
• Kink Model: A piecewise function (used by Aave, Compound) where rates increase more sharply after a target utilization (kink) is passed to discourage over-borrowing.
• Example: Aave's interest rate model for USDC uses a Uoptimal parameter (optimal utilization) to define where the slope of the rate curve changes.

A security and coordination mechanism that enforces a mandatory delay between a governance vote's approval and the execution of the rate change.

• Security: Provides a final review period for users to react to upcoming changes (e.g., withdrawing funds).
• Coordination: Ensures all network participants (nodes, frontends, users) have time to update their systems.
• Example: A governance proposal to update interest rate parameters on a DeFi protocol may have a 2-day timelock before the new rates take effect.

An automated adjustment of token balances to reflect changes in a target price or index, effectively distributing a rate change directly to holders' wallets.

• Positive Rebasing: When the protocol's token is below its target (e.g., $1 for a stablecoin), holders receive more tokens, acting as a yield.
• Negative Rebasing: When above target, token balances decrease to maintain peg stability.
• Example: Ampleforth (AMPL) adjusts all wallet balances daily based on market price deviations from its target, changing the effective supply growth rate for all holders.

A governance-controlled parameter that activates or adjusts the percentage of protocol fees (e.g., swap fees, lending spreads) that are captured by the treasury or distributed to token holders.

• Revenue Distribution: Turning on a "fee switch" converts protocol income into a yield for governance token stakers.
• Rate Impact: Can indirectly affect user-facing rates; if more fees are captured by the protocol, the net rate for users may change.
• Example: Uniswap governance can vote to enable a protocol fee, taking a percentage of the pool fees otherwise earned entirely by liquidity providers.