• Proposal

  • OIP-76: Create Inverse Bond Policy Lever

abipup Inverse bonds increase the backing per OHM by reducing the amount of OHM in circulation, while paying out less than each OHM’s backing.

Not sure if I understand the bonding mechanism correctly: If no body buys the inverse bond for a long time, the discount will increase and the next purchase will still likely pay out more than each OHM's backing, right?

      detoo added an example to the OP.

      Inverse bond price has a limit set to the max price it can offer. So it wouldn't be able to sell above backing; the bond would never offer a price above that.

        ProofofSteveGM

        1. I think we shouldn't establish a rigid order at the start, because the attractiveness to keep a certain asset could shift dramatically. So the best answer I can give here is that the policy team would evaluate the right asset to inverse bond at the time that it's needed. Personally, I also don't think it's wise to sell volatile assets at the bottom.
        2. Backing is calculated in the proposal as market value of the treasury, not counting the OHM held in LPs.

            abipup glad to hear about number two. For number one I hear what you're saying that you want to keep flexibility oh, but this is a pretty big decision.

            It's hard to vote in favor of something like this without really knowing what it's going to look like when it's time to implement. At least personally, I would like to see a framework for what decision the policy team will make when/if the time comes.

              The OHM which gets sent to the treasury will be burnt right? Or will it sit in treasury and added to backing?

              abipup I think if we allowed volatile assets to be involved, we should weight them differently. This is mostly important for any asset that has voting power in another protocol. Where as in your example, the backing is $120 and bond cannot exceed it, for a volatile asset with governing power, the inverse bond may not exceed 120*0.80 (max price x 80%) or, $96. Just an idea

                abipup This is the same mechanism as the Float Protocol but applied to OHM, great idea to stabilize the price and protect OHMies from large market downtrends

                  While I love the idea of an inverse bond, I think we need to establish where will the inversely bonded OHM go to? Will it go to the POL or be distributed to stakers as rebases or just burnt off? The latter two option can help reduce dilution and reduce the rate at which we mint.

                  Another thing we have to determine is when will this feature be available? What are the market conditions that we need to satisfy to have it? If we assume that it is always there, I think it will just end up as a form of deterrence instead and never really see utility because people will know there'll be such a thing and the price where OHM trades at never really dips below backed price. An alternate possibility is that when OHM is trading very near to the backed value, whales or the masses that wants out can sell and tank the price then use this inverse bond with their remaining balance to take advantage of the discount which can hurt the RFV of the treasury.

                    Thank you, this is a good innovation because its more structural than crude buybacks, and avoids having the DAO conduct open marker ops directly, which is important for reducing arbitrariness. Gives the market some properly defined expectations to respond to.

                    The APY flywheel alone is no longer as psychologically reassuring as investor protection, given the ongoing APY reduction. This would be good.

                    One query - Currently when a bond is sold, OHM is accrued to the DAO. How would this work in the case of inverse bonds?

                    I agree with everything. I am supporting you from Japan.

                    I think worth specifying in a little more detail or precisely when the DAO can initiate these, to provide clarity and remove all levels of vagueness and questions

                    So the ohm is not burned, just sent to the treasury without being staked. Should we consider burn?

                      Interesting proposal, but a few points come to mind:

                      • How long will be the vesting period for the inverse bonds?

                      • How much of the inverse bonds will be offered? In case of a sold out bond, they cause more psychologic sell pressure for ohm.

                      • The pricing of inverse bonds should be always below backing per ohm to ensure a net positive outcome for the protocol. But with the backing consists of non-stables, it can fluctuate below the already offered bond price in the volatile conditions. This should be carefully taking care of for in the bond mechanism.

                      • Direct bonds price can fall below backing and with the existence of inverse bonds, more arbitrage opportunities will be created. It’s not necessarily a bad thing but shifts the focus more away from the holding incentives and (3,3).

                      Thanks

                      Instinct is I hate the idea, it’s reverse psyops against ohm. How can this be part of the positive flywheel?

                        abipup I think the type of inverse bonds that are authorized need to be agreed upon at the outset. I don't think we want to be selling just any treasury asset. Probably just the stables for this

                          100% For it. Give the market time to see intrinsic value go up for them to take into account growth into the price, you know the drill…

                          1. Can the policy team advise on the capacity of the new inverse bonds? I don't know if this will do what we want it to if the capacity is far below the amount of new tokens issued each rebase.
                          2. I have read on discord that turning this on and off will be a manual process? As we have had some issues with bonds being exploited in the past, can the team give us some reassurance that the inverse bond contracts will be audited or better yet automated, to make sure they are exploit free?

                          Thanks