Introducing a Revolutionary Automated Rate Controller System

As a long-time contributor to Compound, I am excited to present my latest innovation: a novel automated rate controller system. This cutting-edge solution is designed to improve and streamline the management of Compound’s rates while offering advanced features and capabilities.

User stories

Paul’s experience with setting rates

Paul is responsible for adjusting Compound’s collateral factors to mitigate bad debt and maximize capital efficiency. He faces a challenge in changing the collateral factor for UNI from 75% to 65%. Paul is aware that significant changes can lead to negative user experiences, as such a change could put borrowers underwater. He understands that not every borrower pays attention to governance proposals and may only monitor their current loan health. Ideally, he would like to split this significant change into smaller increments over time. However, this would necessitate multiple governance proposals, potentially overwhelming the governance system.

Paul decides to utilize Adrastia’s novel rate controller to decrease the rate by 2% over five days. By doing so, he enhances the user experience while only requiring a single governance proposal. This innovative solution allows for a smoother transition and minimizes potential negative impacts on borrowers.

Tyler’s experience as a user

During a bull market, Tyler, a user who borrows stablecoins from Compound against his Ether, faces volatile interest rates. He wants to borrow a large number of stablecoins but is concerned about the rapid fluctuations in interest rates. To improve the user experience for Tyler and other borrowers, Compound DAO employs Adrastia’s novel rate controller to stabilize rates. Instead of having rates fluctuate block-by-block, they built a rate computer module to adjust rates based on daily average utilization rates, limiting changes to 0.5% daily. The end result is a more stable and predictable interest rate environment for borrowers like Tyler.

Key features

  • Rate Limiting Support: Safeguard against excessive rate fluctuations, enhancing platform stability and user experience.
  • Delayed Rate Activation: Give users visibility on upcoming rate changes, fostering transparency and allowing them to plan accordingly.
  • Granular Access Control: With five unique roles, enable precise control over rate management to ensure a secure and well-organized system.
  • Circuit Breakers: Protect the platform from extreme market conditions and minimize risks through automated emergency response mechanisms.
  • Dynamic Rates: Automatically adjust rates in response to market changes, ensuring the platform stays competitive and aligned with prevailing conditions.

Use cases

Our automated rate controller system offers versatile applications, such as, but not limited to:

  • Managing collateral factors to optimize risk management
  • Implementing supply and borrow caps as velocity limits, enhancing system stability
  • Streamlining interest rate adjustments to better reflect market conditions

Scalability and future development

While the system is relatively simple in its current form, it offers excellent potential for future enhancements. Through responsibility delegation to dynamic rate computer modules, you can easily build upon and expand the system to incorporate more sophisticated features and functionality as needed.

Data feeds integration

Adrastia has a growing set of data feeds that can be seamlessly integrated into the dynamic rate computer modules. These data feeds include essential information such as price, liquidity, and historical volatility, providing valuable input for the system to make well-informed rate adjustments. By leveraging these data feeds, the automated rate controller system can further enhance its capabilities and provide an even more robust and reliable solution for managing rates.

For example, a dynamic collateral factor could look something like the following.

With a fixed portion of 30% and a dynamic portion of up to 15%, the collateral factor can dynamically adjust between 30% and 45%. Note that our novel rate controller system supports rate limiting, so there’s no need to worry about large fluctuations over short time spans, even though the dynamic range is 15%. Also, note that the fixed portion is changeable by the rate admin (governance).


I deployed a demo to Polygon about five days ago with the initial RateController setup that I’m proposing for Compound. The update period is 24 hours, and the buffer’s capacity is two, allowing up to one day of delayed rate activation. Let’s dive into the transactions.

  1. Mar-25-2023 - Initial rate setup for WETH
    • Max increase: 2% daily
    • Max decrease: 1% daily
    • Base rate: 50%
    • Gas cost: ~103k gas
  2. Mar-25-2023 - Initial rate update for WETH
    • Target rate: 50%
    • Current rate: 50%
    • Gas cost: ~71k gas
  3. Mar-26-2023 - Rate update for WETH: To fill the buffer (updates stop here unless the target rate changes, to save gas)
    • Target rate: 50%
    • Current rate: 50%
    • Gas cost: ~74k gas
  4. Mar-27-2023 - New rate config for WETH
    • Max increase: 2% daily
    • Max decrease: 1% daily
    • Base rate: 60%
    • Gas cost: 41k gas
  5. Mar-27-2023 - Rate update for WETH
    • Target rate: 60%
    • Current rate: 52%
    • Gas cost: ~61k gas
  6. Mar-28-2023 - Rate update for WETH
    • Target rate: 60%
    • Current rate: 54%
    • Gas cost: ~61k gas
  7. Mar-29-2023 - Rate update for WETH
    • Target rate: 60%
    • Current rate: 56%
    • Gas cost: ~61k gas

As we can see, the system works as expected. When it comes to consumption, the comptroller can call getRateAt(token = 0x7ceB23fD6bC0adD59E62ac25578270cFf1b9f619, delay = 1) to get the rate for the token with a one day delay in rate activation. This function returns a tuple containing the target rate, current rate, and timestamp from when the rate was pushed. Having both the target and current rates allows the comptroller to choose the lower of the two when extending credit.

More information



Next steps

  1. Gauge sentiment - is this something the Compound DAO is interested in?
  2. Developer feedback - is the RateController contract missing anything?
  3. Schedule an audit for the RateController contract
  4. Integration - how should this system be used? How should the Compound codebase be modified?
  5. Schedule an audit for the integration
  6. Deployment configuration, division of responsibilities, and compensation
  7. Launch

In conclusion

I believe that integrating this novel automated rate controller system into Compound will lead to significant improvements in efficiency, security, and user experience. I am eager to discuss this proposal further and demonstrate how the system can be tailored to Compound’s requirements.

Please present any comments, critiques, or questions regarding Adrastia’s novel rate controller system. I am confident that this innovative solution will bring substantial value to Compound and its users.

Thank you for considering my proposal, and I look forward to our continued collaboration.

Best regards,
Tyler Loewen


Step 1. Gauge sentiment

Is it worthwhile for Compound to explore integration opportunities of Adrastia’s novel rate controller system? The path to integration is open-ended for now, as this abstract system can be used for many purposes, whether the system is used for collateral factors, interest rates, supply/borrow caps, etc.

Should Compound explore the integration of Adrastia’s novel rate controller system?
  • Yes
  • No

0 voters


Step 2. Developer feedback

It’s been a week, and sentiment looks favorable, so let’s proceed to the second step.

In the original post, I outlined several ways this rate controller system can be used. Please note that I’m not necessarily proposing all of these. They serve to get our creative juices flowing and envision how the system can be used in the future. We save time down the road by thinking about and planning for all that is possible.

It is challenging to think in abstract terms and plan years in advance, so let me provide some concrete implementation paths. Adrastia’s novel rate controller system is currently ready to be used in two ways: collateral factors and supply/borrow/collateral caps.

Implementation paths

Collateral factor implementation

The system is currently ready to be used for basic collateral factors. I’ve spoken about dynamic collateral factors, but this is only an option for the future. By dynamic, I mean autonomous adjustments based on market data feeds. So please ignore the FUD surrounding dynamic collateral factors, as this isn’t what I’m proposing now.

What I’m proposing today is that the system is used to provide smooth collateral factor adjustments with only one governance proposal. For example, say that Gauntlet recommends changing a CF from 70% to 50%. As this is a significant change, Gauntlet would break it up into multiple governance proposals. Instead, with this rate controller system, Gauntlet could make one governance proposal that reads something like “decrease the CF by 5% every seven days until it reaches 50%.”

There are several benefits of using this new system. Gauntlet saves time by not having to submit so many proposals. Voters save time by not having to review so many proposals. Voters and governance executors save gas by not having to vote on and execute many proposals. Less governance fatigue decreases the chances that mistakes occur.

These benefits are in addition to the benefits of the rate controller’s key features: delayed rate activation, granular access control, and circuit breakers.

Supply/borrow/collateral cap implementation

Adrastia’s novel rate controller system is also ready to implement autonomously adjusting supply/borow/collateral caps.

Today, these caps are statically set by governance. Once again, we come across the inefficiencies of governance. The more activity Compound has and the larger it grows, the more painful it becomes to maintain these caps.

I propose that Adrastia’s rate controller system is used to manage them. This system will continually adjust itself based on the current state of Compound. Since what I’m describing is dynamic, I’ve developed additional controls to limit changes: minimums and maximums.

Let’s use an example to explain how the system works for caps.

  1. Governance sets a collateral cap for ETH in the USDC mainnet market with the following configuration:
// Set the rate controller config
rateController.setConfig(WETH, config = {
  maxIncrease: 20000, // Max of 20000 WETH increase per period
  maxDecrease: 20000, // Max of 20000 WETH decrease per period
  base: 0, // Ignored
  componentWeights: [100], // The USDC market rate computer has a weight of 100%
  components: [usdcMarketCollateralCapRateComputer] // The USDC market rate computer for collateral caps

// Set the USDC market collateral cap rate computer config
// Note: The current collateral supply is 85,674 WETH
usdcMarketCollateralCapRateComputer.setConfig(WETH, config = {
  max: 90000, // Max collateral cap of 90,000 WETH
  min: 80000, // Min collateral cap of 80,000 WETH
  offset: 1000, // Add 1,000 WETH to the current collateral supply
  scalar: 105% // Add 5% on top of the current collateral supply
  1. Once per period, caps are updated. With a current collateral supply of 85,674 WETH, the update sets the collateral supply cap to max(85,674 * 105% + 1,000 = 90,957.7, config.max) = 90,000.

The rate computer takes the current collateral supply and mutates it according to its configuration, subject to its limits. The rate controller takes this value and applies further limitations to the value before pushing it to the buffer.

Note that it’s possible to use time-weighted averages instead of current values - Adrastia was built to provide this for any data point. We support the use of all three Pythagorean means (arithmetic, geometric, harmonic). We also support median filtering. Any techniques that are used off-chain to improve data quality can also be used on-chain.

Also, note that all figures are just examples. It’s up to risk managers to decide how the system is configured.

Like the collateral factor implementation, the caps implementation also saves time, gas, and energy with governance. It reduces the chance that mistakes are made because of governance fatigue. It allows tighter caps to be employed because governance inefficiencies do not limit it. This is in addition to the benefits of granular access control, circuit breakers, and delayed rate activation.


Request for feedback

I hope that it’s clear how Adrastia’s novel rate controller system can be used today, and I hope that I’ve sparked everyone’s imagination as to other ways this system can be used.

I’m looking for feedback on today’s proposed uses and any design concerns we may encounter in the future.

More specifically, I have the following questions for the developers and system designers of Compound:

  1. Is the RateController contract’s design and architecture clear and easy to understand? Are there any aspects that you think could be simplified or improved?
  2. Are there any features or functions you think should be added to the RateController or other contracts to better suit Compound’s requirements?
  3. Do you see any potential security risks or vulnerabilities within the contract’s implementation? If so, how do you suggest addressing them?
  4. Are there any potential challenges or obstacles you foresee when integrating the RateController contract with the existing Compound codebase? How can we mitigate these issues?
  5. Are there any specific events or edge cases that the RateController contract should handle, which it currently does not?
  6. How can we improve the monitoring and alerting mechanisms within the RateController contract to ensure the system operates as expected?
  7. How is the role hierarchy? Should there be additional roles to make the system more fine-tuned?
  8. Are the existing control mechanisms for limiting changes sufficient?

The more feedback I receive, the better the system will be. Thanks for reading and providing feedback!


I have engaged with members from various protocols and gathered valuable feedback that has led to the following enhancements in the RateController:

  1. Added minimum and maximum rates to the config: This addition allows for better control over the range of rates, ensuring they stay within acceptable boundaries set by governance.
  2. Introduced minimum and maximum percent change to the config, alongside the existing minimum and maximum absolute change: By incorporating both absolute and percentage-based limits, the system can now cater to various scenarios, offering more flexibility and precision in controlling rate changes.
  3. Extracted the management code into a new contract, enabling easy extension and implementation of a role management system tailored specifically for Compound: This change not only makes the codebase more modular but also allows Compound to customize the role management system as needed.

Furthermore, I have developed a ManualRateComputer that permits a designated user (such as governance or one or more whitelisted risk managers) to set rates manually. This can be used with collateral factors, representing the “Fixed” portion in the figure shown in my initial post. It can also be used for supply and borrow caps in replace of a completely automated system.

I hope these improvements address the concerns and needs of the Compound community. I am eager to hear any feedback or suggestions for further refinement.

1 Like