Detailed Instructions

Begin by defining the core parameters that dictate how the interest rate responds to market conditions. The utilization rate (U) is the most critical variable, calculated as Total Borrows / Total Liquidity. You must also set the model's slope parameters: the slope of the variable rate (kink rate) and the optimal utilization point (kink). For example, a common Aave-style model might use an optimal utilization of 80% (0.8).

• Sub-step 1: Deploy the smart contract with initial parameters, often via a governance proposal.
• Sub-step 2: Configure the InterestRateStrategy contract address (e.g., 0x8C7e3e5a7b5c4a1F4B8C... on Ethereum Mainnet).
• Sub-step 3: Verify the base variable borrow rate is set, typically starting at 0% when utilization is zero.

Tip: Always audit the parameter values on-chain using a block explorer like Etherscan to confirm they match the intended economic design.

Detailed Instructions

The protocol's smart contract must fetch the latest reserves data to compute the utilization rate in real-time. This involves querying the total borrowed amount and the total available liquidity (including reserves) for the specific asset pool. The formula is U = borrows / (liquidity + borrows). This calculation occurs on every block, making the rate dynamic.

• Sub-step 1: Call the getUtilizationRate() view function on the lending pool contract.
• Sub-step 2: Monitor the output; a utilization of 0.65 (65%) indicates a moderately used pool.
• Sub-step 3: Log the historical utilization to analyze rate volatility over time.

codeCopy
// Solidity pseudo-code for utilization
function getUtilizationRate(uint256 totalBorrows, uint256 totalLiquidity) public pure returns (uint256) {
    if (totalLiquidity == 0) return 0;
    return (totalBorrows * 1e18) / (totalLiquidity + totalBorrows); // Scaled by 1e18 for precision
}

Tip: High utilization (>90%) often triggers a steep increase in rates to incentivize repayments or more deposits.

Detailed Instructions

Once the utilization (U) is known, apply the piecewise linear function. If U is below the optimal kink (e.g., 80%), the rate increases slowly. If U exceeds the kink, the rate increases sharply to penalize over-utilization and protect liquidity. The formula is: rate = baseRate + (U * slope1) for U <= kink, and rate = baseRate + (kink * slope1) + ((U - kink) * slope2) for U > kink, where slope2 is much larger than slope1.

• Sub-step 1: Retrieve the pre-configured slopes (e.g., slope1 = 0.04, slope2 = 0.75).
• Sub-step 2: Execute the calculation on-chain within the calculateInterestRates() function.
• Sub-step 3: For U=85%, with a kink at 80%, the rate jumps significantly due to the high slope2 multiplier.

codeCopy
// Example calculation for U > kink
uint256 kink = 0.8e18;
uint256 slope1 = 0.04e18;
uint256 slope2 = 0.75e18;
uint256 excessUtil = U - kink;
uint256 rate = (kink * slope1 / 1e18) + (excessUtil * slope2 / 1e18);
// Result might be ~4% for the first 80% utilization, plus a large add-on for the excess 5%

Tip: This model creates a soft liquidity cap, automatically adjusting rates to balance supply and demand.

Detailed Instructions

The calculated variable borrow rate is now applied to all outstanding variable-rate debts. The borrower's interest accrues continuously, increasing their debt balance. Simultaneously, the supply APY is derived from this borrow rate, taking a portion as a reserve factor for the protocol (e.g., 10%). The remaining interest is distributed to liquidity providers. This update is typically handled per block via an accrual mechanism.

• Sub-step 1: Invoke the accrueInterest() function on the token market contract (e.g., cToken or aToken).
• Sub-step 2: Check the new borrowIndex and supplyIndex state variables to see cumulative interest.
• Sub-step 3: For a borrow rate of 5% APR and a 10% reserve factor, the supply APY becomes 4.5% APR.

Tip: Users can monitor their evolving APY on front-ends like the Aave UI, which refreshes as on-chain data changes.

Detailed Instructions

Decentralized governance is key to maintaining a healthy lending market. Token holders should continuously analyze metrics like average utilization, rate volatility, and liquidity depth. If rates are too volatile or liquidity is chronically low, a governance proposal can be submitted to adjust the kink point, slopes, or reserve factor. This often involves a vote on a DAO platform like Snapshot, followed by a timelocked execution on-chain.

• Sub-step 1: Use analytics platforms (The Graph, Dune Analytics) to query historical rate data for the pool.
• Sub-step 2: Draft a proposal to change a parameter, e.g., setKink(0.85e18) to raise the optimal utilization.
• Sub-step 3: Execute the proposal via the protocol's governance contract (e.g., call execute() on 0xEC568... after a successful vote).

Tip: Parameter changes are high-risk; always simulate the impact using forked mainnet environments like Tenderly before proposing.

Detailed Instructions

First, identify the immutable parameters that define the stable interest rate model. Unlike variable models that fluctuate with market conditions, a stable model uses a fixed base rate and a utilization rate multiplier that are set at deployment. For example, a common configuration might set the optimal utilization rate (U_opt) at 80%, the base stable rate (R_base) at 5% annually, and a rate slope (R_slope) of 7% for utilization above the optimum.

• Sub-step 1: Locate the contract's constants. Query the smart contract's public variables. For a contract at 0x...StableRateModel, you might call getBaseRate() and getOptimalUtilization().
• Sub-step 2: Understand the rate calculation formula. The stable rate is typically calculated as: if utilization < U_opt: rate = R_base; else: rate = R_base + R_slope * ((utilization - U_opt) / (1 - U_opt)).
• Sub-step 3: Verify parameter immutability. Check that these parameters are set in the constructor and have no public functions to alter them, ensuring true stability.

Tip: Use a blockchain explorer like Etherscan to read the verified contract code and confirm these constants are not governed by a timelock or admin key, which would introduce variability.

Detailed Instructions

With the model parameters defined, calculate the current borrowing rate by feeding in the pool's utilization ratio. This ratio is total borrows / (total liquidity + total borrows). The key distinction from a variable model is that the rate only changes significantly if utilization crosses the optimal threshold; otherwise, it remains predictably near the base rate.

• Sub-step 1: Fetch pool state data. Call the lending protocol's main contract (e.g., 0x...LendingPool) for getReserveData(asset_address) to retrieve totalVariableDebt, totalStableDebt, and availableLiquidity.
• Sub-step 2: Compute utilization. Use the formula: utilization = totalStableDebt / (availableLiquidity + totalStableDebt). Note we isolate stable debt for this calculation.
• Sub-step 3: Apply the model formula. Plug the utilization into the formula from Step 1. For example, if utilization is 85%, R_base=5%, U_opt=80%, R_slope=7%:

codeCopy
rate = 0.05 + 0.07 * ((0.85 - 0.80) / (1 - 0.80))
rate = 0.05 + 0.07 * (0.05 / 0.20)
rate = 0.05 + 0.0175 = 0.0675 (6.75% APY)

Tip: This predictable calculation allows for precise long-term financial planning, as the rate is insulated from short-term market volatility affecting variable rates.

Detailed Instructions

To borrow at a stable rate, you must explicitly select the stable rate option during the borrow transaction. This action will lock the interest rate calculated at that moment for the duration of your loan, unless you actively choose to rebalance. This contrasts with a variable rate borrow, where the rate automatically updates with each block.

• Sub-step 1: Prepare the transaction. Construct a call to the lending pool's borrow function. The critical parameter is the interestRateMode. For stable rates, this is typically 2 (where 1 is often variable, and 3 is for specific aTokens).
• Sub-step 2: Specify the amount and recipient. For example, to borrow 1000 DAI on Aave V3, your transaction to 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4e2 would include: asset=0x6B175474E89094C44Da98b954EedeAC495271d0F, amount=1000000000000000000000, interestRateMode=2, referralCode=0.
• Sub-step 3: Submit and confirm. Send the transaction and verify the logs. Look for a Borrow event that confirms the interestRateMode and the stableBorrowRate field, which should match your calculation from Step 2.

Tip: Ensure you understand the protocol's rules for stable rate rebalancing and liquidation thresholds, as borrowing at a stable rate might have different health factor implications than a variable rate loan.

Detailed Instructions

After borrowing, active management is required. Monitor your position's health factor and be aware of conditions that could trigger a stable rate rebalancing or make your rate eligible for change. Protocols often have mechanisms to incentivize moving from stable to variable rates if the stable rate becomes economically unfavorable.

• Sub-step 1: Track key metrics. Regularly query your user account data via a function like getUserAccountData(user_address). Pay close attention to the healthFactor and the currentStableBorrowRate for your specific assets.
• Sub-step 2: Understand rebalancing triggers. If the pool's overall stable rate rises significantly above the variable rate, the protocol may flag stable borrows for rebalancing. You might receive an incentive to switch or be required to do so to maintain loan health.
• Sub-step 3: Execute a rebalance or repayment. To manually switch from stable to variable, call the swapBorrowRateMode(asset, interestRateMode) function. To repay, use repay(asset, amount, interestRateMode, onBehalfOf). Always use interestRateMode=2 to target the stable debt.

Tip: Set up alerts for your health factor falling below 1.5 and for significant changes in the protocol's average stable rate. Tools like DeFi Saver or Aave's own UI can automate some of this monitoring.