Lending Market Improvements: IRM Automation

Background

The dominant DeFi lending markets use a peer to pool model, where lenders supply assets into a pool which can then be utilized by borrowers. Supply and demand for liquidity are balanced dynamically via utilization based interest rate models (IRMs), where the cost of borrowing (and return on lending) increase as more liquidity is withdrawn from the pools. This helps ensure that lenders have adequate liquidity to be able to withdraw their funds on demand, by incentivizing borrower repayments and new deposit inflows in cases where liquidity falls to low levels.

Most IRM mechanisms use a “jump rate model”, where borrowing rates rise slowly up to an optimal utilization level, and then increase rapidly as utilization increases above the optimal point towards 100%. In normal conditions changes in utilization have a limited impact on borrow rate volatility, while the steep “slope” of borrow rates over the optimal point offer strong assurance against illiquidity risk.

Historically, these rate models have remained mostly static despite significant changes in market conditions. For example, in the height of the bull market, borrow rates frequently found equilibrium at high levels above the optimal utilization point, while in the bear market they have settled far below the optimal utilization point.

Lenders earn a return proportionally to both the interest rate paid by borrowers and utilization rate of the pool as a whole, meaning that the overall efficiency of peer to pool lending markets is maximized when utilization is at relatively high levels, typically around the optimal utilization point. The lack of adaptive updates to rate models therefore represents a missed opportunity to improve money market efficiency and welfare of borrowers, lenders, and the protocol as a whole.

Design Goals

As discussed above, static utilization based IRMs have significant drawbacks in terms of market inefficiency and user welfare. A mechanism design solution to these drawbacks should fulfill the following criteria:

  • Maintain market safety by mitigating illiquidity risk
  • Improve market efficiency, as measured by the spread between supply and borrow rates
  • Limit governance workload and requirements for active management
  • Minimize interest rate volatility

Below we describe one solution to optimize IRMs which addresses the key weaknesses of existing static models, while minimizing ongoing management and governance complexity.

Mechanism

The proposed mechanism adds a simple controller to the traditional utilization based IRMs. This allows for borrow rates to be adjusted to target the market utilization around the optimal level, automatically adapting to changes in equilibrium borrow rates without requiring active governance. Over time this should result in better market efficiency and narrower spreads between supply and borrow rates.

The core utilization based IRM remains broadly unchanged from existing lending protocols. Borrower interest rates are determined by a two part linear function, with interest rates at 0% utilization starting at a low base value, scaling up slowly towards an optimal interest rate at a selected optimal level of utilization, and then increasing rapidly to a high maximum interest rate as utilization increases beyond optimal levels towards 100%.

A controller adjusts the interest rate at optimal utilization, and potentially also the base interest rate, depending on realized utilization levels over the prior period. Utilization levels can be determined implicitly based on past period realized borrow rates, which in turn are measured by comparing current supplier token (hereafter called cToken) exchange rate to its underlying asset versus the exchange rate at the beginning of the period.

In cases where utilization is higher than target, interest rates are increased to encourage additional deposits or loan repayments. If utilization is below target, borrow rates are reduced to encourage additional borrowing or withdrawals of excess liquidity. Over time this should lead to utilization more closely adhering towards the optimal point, leading to improvements in market efficiency without compromising on liquidity risk.

Efficiency score noted above is a composite value determined based on the relative and absolute spreads between supply and borrow rate at a given utilization, and recognizes that users benefit from each of these values being minimized as much as possible. The score is calculated as supply rate as a share of borrow rate (1 minus the relative spread), divided by the absolute spread. We can see that this measure of efficiency is maximized at or slightly below the optimal utilization rate of a market.

Controller Parameters

The controller has several parameters that must be selected by protocol governance. This includes the time period where past rates are evaluated and IRM adjustments are made, and the degree of rate adjustments when utilization is above or below target.

Because the maximum borrow rate at 100% utilization is intended to be high enough to ensure that markets don’t remain illiquid for prolonged periods, it generally should not be necessary to adjust this rate via the controller. However, in cases where it is technically simpler to have the maximum rate shift on a one for one basis with optimal borrow rate (eg. due to the max rate being calculated based on a premium vs the optimal borrow rate), this should not cause any negative impacts.

For many peer to pool money markets, the base rate at 0% utilization is set as 0% borrowing cost, and in these cases it should not be necessary to adjust base rate via the controller as utilization should trend towards optimal rates regardless. For markets with non-zero base rate, it may be necessary to make controller adjustments to this rate to ensure there is sufficient slope between the base and optimal borrow rates to allow for price discovery.

The controller has the following parameters:

  • Update frequency: determines length of time where interest rate and utilization levels are evaluated, as well as the frequency of adjustments to the interest rate model (minimum time period that must elapse between updates)
  • Max target utilization: the maximum targeted level of market utilization, above which interest rates are progressively increased to encourage deposits or repayments
  • Min target utilization: the minimum targeted level of market utilization, below which interest rates are progressively reduced to encourage additional borrowing
  • Overutilization adjustment: degree of increase to interest rates when utilization exceeds maximum target
  • Underutilization adjustment: degree of reduction to interest rates when utilization falls below minimum target
  • Rate floor: absolute minimum rate(s) able to be set by the controller

While exact settings for the controller are open to refinement, the below reference parameters should fulfill the overall design goals for the mechanism.

  • Update frequency: 1 day
  • Max target utilization: equal to optimal utilization ratio of the market
  • Min target utilization: optimal utilization ratio minus 20% (eg, 60% min target utilization if market has optimal utilization ratio of 80%, or 25% min target utilization for markets with optimal utilization ratio of 45%)
  • Overutilization adjustment: increase interest rates by 0.2%
  • Underutilization adjustment: reduce interest rates by 0.1%
  • Rate floor: 50% of initial optimal borrow rate determined by governance (eg 2% for Aave stablecoins)

In effect, if the increase in value of cTokens over the preceding period indicates a weighted average utilization outside the min or max target utilization rates, then the interest rate model is updated according to the underutilization or overutilization adjustment parameter.

Whenever a rate adjustment is made, the controller must recalculate the supply rate that corresponds to optimal utilization levels to ensure that future period adjustments accurately reflect market conditions.

Derivation and Examples

We denote the exchange rate of supplier tokens to underlying assets at time t as V(t). The supplier interest rate Rs over a given time period p can be calculated based on the length of time in the period, and relative exchange rate of lending tokens to underlying at times t-p and t.

Rs(t) = (V(t) / V(t-p)) ^ (1 year / p)

If p is 1 day, and the exchange rate of supplier token to underlying has increased from 1 to 1.0001 over the period, then the equation would be filled in as follows:

Rs(t) = (1.0001 / 1) ^ (365 / 1) ≈ 1.037 = 3.7%

Given a realized geometric mean supply rate over the period, we must determine whether it corresponds to a utilization ratio above the max target utilization, below the min target utilization, or within the target utilization range. We can do this by referencing the supply rate against market parameters set at the beginning of the sample period.

Let the borrow rate at time t equal Rb(t), utilization rate of the pool equal U, and reserve factor equal F. This yields the following equation relating supply rate to utilization.

Rs(t) = Rb(t) * (1 - F) * U

Now, we simply calculate the supply rate at the min and max target utilization ratios based on market parameters at the beginning of the period. For example, if a market has a reserve factor of 10%, optimal utilization ratio of 80%, base borrow rate of 0%, and optimal borrow rate of 4%, then using the example controller parameters from the previous section we would need to calculate supply rate at 60% utilization (min target) and 80% utilization (max target).

Max target utilization: Rs = [(0.04 - 0) * (0.8 / 0.8)] * (1 - 0.1) * 0.8 = 0.0288 = 2.88%

Min target utilization: Rs = [(0.04 - 0) * (0.6/0.8)] * (1 - 0.1) * 0.6 = 0.0162 = 1.62%

So, if the realized geometric mean supply rate is below 1.62% over the period, the interest rate model would be adjusted according to the underutilization adjustment parameter, and if mean supply rate is above 2.88% the rate model would be adjusted according to the overutilization adjustment parameter.

Continuing the above example, let’s assume that realized geometric mean supply rate was 3%, indicating utilization above target. The rate model would be adjusted to increase optimal borrow rate by 0.2% to 4.2%. New supply rates corresponding to min and max target utilization ratios would now be calculated based on the updated rate model.

Max target utilization: Rs = [(0.042 - 0) * (0.8 / 0.8)] * (1 - 0.1) * 0.8 = 0.03024 = 3.024%

Min target utilization: Rs = [(0.042 - 0) * (0.6/0.8)] * (1 - 0.1) * 0.6 = 0.01701 = 1.701%

At the end of the next period, these updated supply rate values would be used to determine whether utilization was above or below target.

Implementation

Ownership of or permissions over the relevant interest rate model(s) would be granted to a controller, which itself would be owned by the protocol governance. The controller would store values for supply rates corresponding to min and max target utilization ratios, as well as the exchange rate between cToken and underlying token, and time the last update was triggered.

After at least as much time as the selected period has elapsed since the last controller update, anyone would be permitted to call the controller contract to trigger an update. The controller would record the current time and new cToken to underlying exchange rate, and then compare against the previous stored time and exchange rate to calculate the geometric mean supply rate over the period. It would then compare this realized supply rate against the stored supply rates corresponding to min and max utilization ratios to see whether it is within or outside of the target range.

If the realized supply rate indicates utilization is within the target range, no further action is needed. The controller would store the new timestamp while retaining the previously stored min and max supply rates. This would reset the countdown before a new update becomes possible, after the given period time frame has elapsed.

If realized supply rate indicates utilization is outside of the target range, then the controller would trigger an update to the interest rate model according to the relevant underutilization or overutilization adjustments. Based on the resulting rate model parameters, the controller would recalculate the supply rates corresponding to min and max target utilization ratios, and store these values along with the new timestamp.

Governance would have the ability to update controller parameters to optimize the rate model automation scheme based on growing familiarity with the mechanism or changing market conditions. Alternatively, governance could deauthorize the controller and return to a manual rate model parameter setting framework.

General Notes

To maintain gas efficiency and avoid burdening users with additional state updates, controller updates would be handled separately from standard market interactions. In some cases this could result in the controller not being updated for an extended time frame far longer than the given minimum update period. If the utilization ratio has been within the target range for a long period of time, then deviations from the range may not be immediately recognized until the controller has undergone a new update cycle. Because market liquidity is primarily ensured via the steep slope between optimal and maximum borrow rates, this should cause minimal disruption or reduction in the mechanism’s efficacy. Protocols could consider engaging with an in house or decentralized keeper network to encourage more regular controller updates.

Use of geometric mean of realized supply rates to assess utilization, alongside a “jump rate” style interest rate model with high maximum borrow rate, results in asymmetric adjustments to deviation from target utilization range. This can be demonstrated via an example: consider a market with 0% base rate, 4% optimal borrow rate at 80% utilization, and 50% maximum borrow rate. If the market reached 100% utilization for at least 6.5% of the given period, this would ensure an overutilization adjustment in the controller regardless of how low utilization (and supply rate) were for the remainder of the period. In a slightly less extreme example, utilization reaching 85% for as little as 25% of a given period would ensure an overutilization adjustment even if utilization was 0% for the remainder of the period. This is arguably a feature and not a bug, as conservative management of optimal rates to ensure market liquidity also has the beneficial side effect of strongly curtailing interest rate volatility. Over time this can be expected to improve borrower user experience.

This paper discusses rate model controllers in the context of standard interest rate models with explicit borrow rate curves and implied supply rates, used in Aave v2 and v3 as well as Compound v2. In principle it could also be easily adapted to markets with explicit supply rate curves such as Compound v3. In this case supply rate could be directly related to utilization, rather than via calculations as is the case with classical borrow rate models.

Conclusion

The above mechanism is able to achieve the stated design goals with minimal technical complexity or governance workload. This will allow liquidity protocols to improve market efficiency while freeing up governance and service provider workflows to address more complex, higher value goals. It offers a path towards greater automation of liquidity protocols, which in the long run can bring the benefits of greater decentralization and resilience.

We at Block Analitica look forward to sharing more on this and other mechanism design improvements for liquidity markets in the coming months. If your protocol is interested in implementing deeper automation, feel free to get in touch and we’ll be happy to discuss how we can help.

7 Likes

This sounds remarkably similar to the rate controller I started developing early this year (read more) called Adrastia Prudentia. @bgdlabs (Ernesto) is somewhat familiar with it. Has Block Analitica considered creating a rate computer to plug into Prudentia?

In addition to the rate controller, we’re also running geometric-mean time-weighted average supply rate oracles that can be used to power the enhanced IRM with even more precision as you’ve described. Here’s one that’s been tracking the USDC supply rate on Polygon for the past 2 months: Aave v3 USDC Interest Rate Oracle by Adrastia.

Let me know what you think because I’d love to work together on this!

4 Likes

Hi Tyler,

The mechanism we proposed is focused on minimizing gas intensive operations to maintain user experience and reduce operating costs for the host protocol (Aave in this case). With the above rate automation mechanism, it should only be necessary for keepers to update the interest rate model once per day or less, which should help limit gas costs; this is particularly important on mainnet but might be less of a concern on other chains/L2s such as Polygon PoS, Gnosis, Avalanche, Optimism or Arbitrum.

Imo the core goals for IRM automation should be maintaining market safety, improving efficiency (lower spread between borrow and supply rates, resulting from higher average market utilization rates), and less voting/governance/service provider overhead, while limiting cost of operation. If Adrastia oracles can achieve this with better precision / at comparable cost, this would make sense to use borrow/supply rate oracles rather than the proposed geometric mean rate evaluation mechanism. But I suspect at least on Ethereum mainnet using daily geometric mean will probably offer a better tradeoff between precision and operating expenses.

Happy to discuss further!

4 Likes

Hey monet,

Thanks again for the response! We talked on Discord, but I’ll also respond here for transparency and to allow more people to participate in the discussion.

The core goals of maintaining market safety, improving efficiency, reducing overhead, and limiting the cost of operation are well aligned with Adrastia.

Our rate oracles can be - and are - tailored to each chain that they’re deployed on. On L2s and alt-L1s, precision is cheap. With Polygon, for instance, a sensitivity threshold of 2% (2% → 2.04% => update) for the USDC supply rate costs about $4/month to maintain. Ethereum is much costlier, so a higher sensitivity threshold can be used such that updates occur on average once per day or less.

I will provide a cost estimate for Ethereum and other chains in the coming days.

Thanks!

2 Likes

Over the past week I’ve done a gas cost estimate for Ethereum while also deploying and running 7-day average USDC supply rate oracles on Arbitrum and Optimism, which are now reporting data.

On Ethereum mainnet, with a 25% change threshold, an average of about 2.138 updates would be triggered per day. With an ETH price of $2000 and gas price of 56 gwei, the cost would be about $800/month.

It’s a lot less expensive to run feeds on Arbitrum and Optimism, so I decided to go ahead and start running these oracles. The following costs are extrapolated from the past 7 days with the oracles using a 2% change threshold.

Note that the recent interest rate volatility has inflated these costs. Also, note that the 2% change threshold can be raised to decrease costs.

Arbitrum: 0.1882 ETH/month or $376/month.
Optimism: 0.0601 ETH/month or $120/month.

Let me know if these gas costs sound reasonable.

2 Likes

What is the status of this proposal? @monet-supply @BlockAnalitica Having an IRM automation is a huge improvement for current AAVE’s mechanism.

1 Like

On the whole, Gauntlet agrees that technologies such as this automated IR can be valuable additions to the Aave protocol. A dynamic interest rate that can adjust in response to a number of factors could optimize capital efficiency in a manner that is equivalent to credit scoring, and also reduce risk caused by a dearth of available reserve liquidity.

However, automated IR mechanisms do have their tradeoffs. We show in our research on dynamic rate curves that the deterministic nature of this automated IR mechanism - as evidenced by the constant nature of marginal increase/decrease in IR outside of the target utilization bounds - could introduce potential attack vectors analagous to JIT liquidity attacks for Uniswap. These attack vectors essentially allow for a strategic user to profit and seize higher yield at the expense of less sophisticated lenders. This over time may reduce overall liquidity on protocols, impairing the capital efficiency of the protocol. For instance,

  1. A strategic user adds a large amount of demand and raises utilization rates by opening borrow positions, causing the interest rate to spike dramatically.
  2. The choice of how much of a spike was caused allows the strategic user to sequentially reduce demand (repaying a portion of the opened borrow) and increase supply in such a way that the interest rate and utilization are stationary.
  3. After a number of blocks, the strategic user returns the utilization to the level prior to opening loans.

image

At a high level, we find that the reducing the reserve factor below certain thresholds can negate attacker profitability. We have also identified that considering supply and demand elasticities may help with this IR param optimization, especially with the reserve factor and optimally balancing protocol revenue. As a result, models for these elasticities and/or their results can be fed into future automated IR mechanisms to make them more robust against potential attacks and manipulations and disincentivize adversarial actors.

2 Likes