OIP-123 RBS Launch & Initial Parameters
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?
Send it.
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.
- Edited
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.
send it.
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.
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.