• Proposal

  • OIP-123 RBS Launch & Initial Parameters

Summary

Formalize a set of necessary permissions to launch the Range Bound Stability system.

  • Approve an initial set of parameters for the system implementation.

  • Approve a set of emergency conditions under which the autonomous operations of the system could be stopped by the Policy multisig to prevent exploits, bugs, and/or unexpected behaviors that can be harmful to the protocol.

  • Approve an estimated 12 month budget to fund triggering key functions by keepers

  • Approve the launch of RBS

Motivation

The implementation of the RBS system aims to increase automation and bring stability to the Olympus ecosystem in an algorithmic manner. Proper configuration of the system is of great import to minimize risk.

The RBS system will always have room for improvement and further automation using a dynamic controlling system. The Policy team wants to progressively increase its robustness and autonomy, as the understanding of the system increases and its behavior is proven over time.

To speed up this learning curve, and to provide an optimal set of initial parameters, the Policy R&D team has created extensive simulations of the system. The team tested the system under different market conditions to fine-tune an initial set of parameters, which serve as a starting point and a benchmark for both future parameter iterations and a more advanced controlling system.

Since the system will have the ability to autonomously perform market operations using Treasury funds, it is extremely important to progressively add funds to the system and have a backstop method to be able to stop all market operations if malicious actors are able to exploit the system. To that end, this proposal requests the authority for the DAO to turn off the system by closing all active markets and setting capacity limits to 0.

Parameter Simulation Report

The Policy R&D team has created a report of the modeling and simulation effort done to fine-tune the initial parameters.

This report recaps all the development steps, as well as the analysis framework that the broader Policy team used to come up with the final parameter proposal.

The report can be found here.

Proposal

Initialize the RBS system with the following parameters

  • length of the target price MA: 30 days

  • max liquidity ratio: 0.14375

  • ask/bid factor: 0.095

  • cushion factor: 0.3075

  • wall offset: 0.295

  • cushion offset: 0.1675

  • mint and sync: 0

  • reinstate window: Yes, 18/21 epochs

Initialize the RBS system with the following price target:

  • initial price target: 30d MA at time of launch

Approve the treasury team to fund the new treasury contract in multiple stages from the current treasury contract.

Definitions:

  • reserves: all DAI in the Olympus treasury contracts

  • liquidity: all DAI in Olympus treasury owned LP positions (including Balancer, Aura, Curve and Fraxswap)

  • liquidity ratio: liquidity / reserves

Set up the Policy multisig as the admin of the Operator contract, effectively giving it permission to perform an emergency stop of the RBS system if any of the following conditions are met:

  • Flash loan / Exploit / Treasury attack (>2x capacity lost in 24h)

  • Manipulation of the price oracles (Chainlink oracle price delta >10% from Balancer main pool price)

  • Market capacity >10% delta vs calculated theoretical

  • Fast price depreciation (>20% price breakout outside lower wall in less than 6h)

An emergency stop is comprised only of the following actions:

  • Deactivate RBS operations

  • Close all active markets, halting all current bond emissions (both reserve and inverse)

  • Fall back to OIP-94B temporarily until RBS goes back online

The Policy multisig would not have the authority to touch the system other than described above.

  • Approve 5,475 OHM for keepers

As part of RBS, there is a beat() function in the Heart.sol policy. This function is critical to running RBS and needs keepers (bots) to trigger it. Due to that, we’re requesting a budget for these keeper rewards. Our best estimate is that we’d need 5,475 OHM a year for these keepers, but it may be more or less depending on OHM and ETH price, as well as gas prices in general.

After at least 1 month of the RBS system being active, the community should re-evaluate the need for this emergency shutdown authority. The hope is that with enough time, the system can be proven enough to warrant a fully autonomous and automated operation.

Poll: approve RBS launch initial parameters, emergency powers, and keeper funding? Poll will be live until Monday 14 November, and if passed then immediately go to Snapshot.

Approve RBS launch initial parameters, emergency powers, and keeper funding?

This poll has ended.

    Watched the session on this and re-read the notion and as much as I can grok, I am for it. Others are better to speak to the mechanics and tuning, but I have 2 practical questions around the "Emergency stop":

    • What alerts have been put in place for when these conditions have been met? (how/who etc)
    • What communications plans are in place to ensure enough mutisig signers can get together in a timely fashion when a condition is met?

    In the past I have seen it mentioned that getting multisig quorum is hard, and it seems like this being done in a timely fashion is now essential.

    Thx team!

      thomasscovell Thanks for your reply!

      • Oracles, capacity, and prices can be tracked on Dune. Attacks can't be monitored in real time on Dune so we'll have to monitor the chain directly.
      • We're proposing to use the Policy multisig, which is different (and much faster to execute) than the Treasury multisig.

        Regarding the topics for further research,

        I recently wrote a (math) paper, can be found here, that gives some answers/insight into a few of the future research topics:

        Are there scenarios in which dynamic RBS parameters prove more effective than static ones?

        Yes - making RBS parameters more dynamic with respect to statistically predictable MEV trading volume, which accounts for over 75% of all OHM trade volume and the majority of large swaps. This makes MEV bots a far greater market mover than humans.

        Creation of a more complete model that can capture the impact of OHM illiquidity as a consequence of features like OHM Bonds and lending.

        The paper specifically models a topological model on the historical sushiswap LP dataset for OHM and lending pools such as Rari and Vesta. Although just at the beginning of the era of OHM lending, it's very clear already that there is a significant relationship between liquidations and MEV trading volume.

        MEV volume represents the majority of trading volume as well as the largest swap sizes implies that MEV bots are a non-trivial actor within the OHM ecosystem implies efficiency can be increased by understanding and catering towards this large subset of OHM users. Liquidation volume is even greater because 100% is driven by MEV bots. Humans don't liquidate anything.

        It doesn't appear that there were any considerations in the report for MEV and its possible impacts on RBS over time. Why isn't this topic included as an additional area of further research?

          I have voted in favor of this proposal but I have a few questions and points of clarification that I wanted to put on the record.

          • I think that there should be definitions for each of the parameters.  I see some explanation in Sections 2.2 and 3 of the report but the naming conventions aren’t exactly the same.  At any rate, I think that the definitions should be consolidated to a single section/location of either the report or the OIP.  

          • Max Liquidity Ratio:  I may be misremembering but I think that the current metric for liquidity is 20% of the market cap.  Does a liquidity ratio of 14.375% result in more or less than the current POL in Balancer at the launch of RBS?

            • The report states, “max liquidity ratio: Establishes the treasury ratio between liquidity and reserves. The treasury will dynamically adjust its composition based on this ratio.”  Further down, the report explains that the three options were to use TWAMM (not available right now), rebalance manually with buy/sell orders and rebalance by minting/burning LP shares.  Just to clarify, at launch, RBS will use the third option of minting/burning LP shares which will be handled manually by the policy multisig?

          • Ask/Bid Factor (aka Reserve Factor) & Cushion Factor: Is this saying that 9.5% of the Treasury reserves will be used for both the upper and lower “market operation” zones.  For example if there’s $100M in the Treasury, this would mean that $9.5M is available to the upper wall, the upper cushion, the lower cushion and the lower wall.  Correct?  If so, 30.75% of that $9.5M, or $2.9M, would be used for the cushions.

            • Let’s say that the price goes to the upper cushion zone and $1M worth of Reserve bonds are sold before the price goes down.  In this scenario, reserves would have increased by $1M.  Does that mean that there is now $3.9M available for the lower cushions or is the budget recalculated to account for the increase in reserves (i.e. reserves now = $101M * 9.5% = Reserve Factor of $9.59M and Cushion Factor of $2.95M)?

          • Cushion/Wall Offset: I know that this was discussed in the Policy channel earlier today, but I think that it should be clear that these are measured from the 30dma.  So the total spread from wall-to-wall is 59% and from cushion-to-cushion is 33.5%.

          • Reinstate Window: 18/21 epochs is roughly the same as 6/7 days, correct?

          • Budget for Keepers:  

            • Who runs the keepers? 

            • Is the OHM meant to reimburse the keeper’s gas cost?  If so, why not pay them with ETH?

            • Where is the OHM coming from?  DAO Treasury?

            • Assuming the OHM is meant to reimburse the keeper’s gas, what happens if there’s a significant spike in gas prices which depletes the OHM for the keepers?  Do the keepers stop or will they run on credit until the contract is funded?  If they stop, what are the implications?

            • Given that the function performed by the keepers is “critical to running RBS”, should an interruption in keeper operation be added to the list of emergency stop triggers?

            0xEvan those are useful analyses! and I think there is value in dynamic parametrization of RBS for multiple reasons. My understanding is:
            1. This isn't the final form of RBS and it almost surely will go through upgrades.
            2. Any upgrades that make the mechanism more complex (any dynamic parametrization will e.g.) need to be balanced against security considerations. The mechanism as it stands right now is elegant in its simplicity.

            (P.S. not to nitpick, but that is not a Math paper… it's a data analysis report, that doesn't diminish its importance but it's better to call things what they are so that the misnaming doesn't detract from your ideas.)

                thomasscovell
                To add a bit, we're also building alert bots that monitors on-chain data -> our data solution -> alert Discord channels, and devs, the data&metrics team and policy is also setting up on-call rotations to make sure someone is always available.

                @guerrillatrader about the max liquidity ratio: max liquidity ratio is calculated a bit different in RBS. Previously it was liquidity to market cap. In RBS it's calculated as liquidity to total reserves. At launch it will not be very far from current liquidity.

                    I think MEV will become more of an issue/opportunity for RBS when TWAMMs become the dominant mechanism.

                    z_33 no you're right it is more accurate to call it a data analysis report than a math paper. That was poor terminology by me. Your other points 1. and 2. are also good points and I certainly agree with you on those matters too.

                    @abipup I agree with you. I think MEV will only become more of a bigger issue as time goes on and not the other way around. I would take it one step further and say that a requirement for any DeFi mechanism to be successful/economically secure is that it needs to have strong symbiosis with MEV. If this isn't done from a first principles point of view at the beginning, then it only becomes a matter of time before someone takes advantage of the economic opportunity via MEV

                        0xEvan Agreed and in fact I've added MEV in general as a topic for further research in the report.

                        One thing in particular I see is something I actually hoped to explore and implement when Rari was still alive: graceful exits from overleveraged positions. As written in your report, all liquidations are done via MEV bots. I wonder how the RBS system could be upgraded to either intercept those liquidations, or incentivize MEV bots to liquidate in a way beneficial to the ecosystem (versus selling on the open market, which can lead to cascades).

                          guerrillatrader Thanks for the reply and well thought questions!

                          Agree we should make sure to have harmonized terminology. The docs would be good place to be updated with that.

                          As cpt_zeke said, liquidity ratio uses current Liquidity and Reserves, and we'd target similar liquidity to today with the proposed ratio.

                          You are correct on the Reserve and Cushion factors. They do change based on the amount of reserves available.

                          I clarified in the Report and in the proposal above that the offsets are from the 30d MA, thanks for that!

                          Reinstate window confirm roughly 6/7 days.

                          @indig0 can you answer on the keepers setup? I'm not 100% sure on them and don't wanna give incorrect info here.

                              abipup I think this is a huge step forward, the more features that can be written into code (that is then battle tested) the more trust will be built around ohm. I think many in defi already trust ohm's team and vision but in many ways there is nothing as reliable as code and automation. Very exciting to embark on this journey towards an even more robust automated and trustworthy ohm.

                                abipup After at least 1 month of the RBS system being active, the community should re-evaluate the need for this emergency shutdown authority. The hope is that with enough time, the system can be proven enough to warrant a fully autonomous and automated operation.

                                I get the sentiment here but I don't think we need to telegraph when we will possibly be moving to a fully autonomous operation. We need to find weaknesses in this system sooner rather than later, and putting a (potential) date on things gives some information advantage to a hacker.

                                Can we make this language a bit vaguer?

                                    dodecahedron agreed that full handover to the automated system should not have a definite date. We just mean to add language suggesting a periodic review of the system.

                                      I am against the proposed configuration because I think that it will result in a sudden drop in the OHM price by 16.75%. Currently, inversed bonds absorb sell pressure at any price point, which the lower cushion won't. This is concerning for stakeholders that purchased believing that inverse bonds would defend the price and push the market price towards liquid backing.

                                      5 days later

                                      I think we have come to a position where we can not introduce regular bonds to get dollar stables. More of this ohmbuying means more of loss for us. work on some thing to get in more dollar stables to boost up the treasury.

                                      Write a Reply...