Summary: The primary supply emission structure of Olympus has the protocol offer new tokens when the market for OHM is at a premium. This proposal suggests the installation of upgraded automated infrastructure for this process.

Proposal: Install the Emissions Manager into the protocol, providing it with minter privileges to allow it to emit new supply. The functionality of the contract is described below:

Description of Smart Contract: The emissions manager operates with two main policy variables, the base emissions rate and the minimum premium, and computes emissions based off of premium (which equals market price / backing price). This occurs every 3 epochs and is triggered by the heart.

When premium is greater than the minimum premium, the protocol will create a Bond Protocol market offering a computed amount of OHM in exchange for new reserves (in the form of USDS). The equation for this emission is: new supply = total supply * base emissions rate * (premium + 100%) / (minimum premium + 100%).

For example:

  • total supply of 15m OHM
  • base emissions rate of 0.02%
  • premium of 200% (price of $30 with backing of $10)
  • minimum premium of 100%
    new supply = 15m * 0.0002 * (2 + 1) / (1 + 1) = 4,500 OHM.

This calculation and emission occurs once per day given premium is greater than the minimum premium.

The new supply equation creates a linear increase in emissions as premium goes up. It is important to note that implicit in premium rising is a rising price per token. Thus, reserve inflow to satisfy emissions increases exponentially with a rising premium. This ensures that the system scales with the market, increasing and decreasing the impact of its emissions exponentially with free market movement. It should also be understood that any reserve inflows due to the emissions manager will increase backing and thus decrease premium at the same price, allowing the inflow requirement of a given price to decrease exponentially the longer it is sustained.

You can see this dynamic graphically below (ignore the actual numbers and focus on the shape/amplitude of the curves):

Supply vs Premium Curve:
Supply vs Premium Curve

Inflow vs Premium Curve:
Inflow vs Premium Curve

Suggested Policy Variables: I will first list how I think about these, and then give suggested initial values.

Minimum Premium: This variable dictates what premium the market must reach before the protocol begins emitting liquidity in the form of new OHM. This is the more arbitrary of the two, but my heuristic is that new supply should be accompanied by tangible benefit to backing. Otherwise, it is simply inflation of supply with no systemic benefit. 100% to me is a simple threshold that satisfies this base consideration.

Base Emissions Rate: This variable dictates the rate at which emissions occur. A too low BER diminishes the growth rate potential of the network at premium and may also allow for undue volatility in the market as the protocol fails to provide adequate supplementary liquidity. On the other hand, a too high BER would act as a suppressant against more significant premiums, which diminishes the ability for backing to grow. My suggestion is to set it at 0.02%, which was the average rate during 2021 (I derived this from historical data and you can see it here).

Motivation: Ensure the system is ready to grow treasury, backing, and supply upon an increase in demand for OHM sufficient to push higher premiums.

Timeline: Discuss now, move to OIP and OCG when applicable. Code entered an audit on Monday 4 November with an expected end date of Monday 11 November. A pull request for the code can be found here.

Proceed to OIP?

This poll has ended.

can you speak a little bit more on how this would play along with RBS? would this require any changes to RBS?

  • Zeus replied to this.

    z_33 yeah i have a longer version of this to post but imo RBS is a tool for contraction or equilibrium states, not growth, and it should be disabled when emissions manager comes in (along with an increase in POL). tldr allow volatility for growth, suppress volatility for contraction/stasis

      A PR with the code has been added to the original post but here is the link again. A few technical things to note that I forgot to add:

      • this uses an internal backing calculation that computes on every order. for example, if a order added 1% to reserves and 0.1% to supply, it would increase its internal backing by 0.9%. this isn't perfect since it ignores anything that might be happening between orders. OCA will fix this by providing a backing feed for it to look at on-chain, but this should be an adequate solution prior to its installation, which will be easiest to do after kernel ownership has been passed to the timelock. this has been communicated to the auditors to ensure it does not present any security risk -- the worst case should be that its calculation of premium is not perfect and thus emissions vary slightly from what they optimally would be.
      • minimum premium and base emissions rate are both configurable at any time by governance. they need initial values, but they can always be tuned in the future to achieve better function.

      As soon as price is below the premium threshold, you re-enable RBS?

      For those reading that like fewer words:

      • Price goes up a lot, we issue lots of bonds and grow the treasury. The original things you love OHM for…
      • Otherwise, price ideally stays within RBS setup.

        Don_G_Lover I think you automate reactivation if min target price is hit but otherwise leave to governance reactivation. if you look at it right now, rbs isn't doing much, so delay isnt a big deal. if it was coming off expansion wave and into contraction though, the lower cushion/wall might hit before protocol buys much more supply under backing -- so why frontrun and extend those bids above backing?

        gov is still nimble so its easy to fallback on such structures but it would definitely be worthwhile to quantify and implement such rules into the system.

          In the current version, I think the existence of RBS is doing the market psychology piece.

          I'm more keen on something automated to reinitialize the RBS parameters versus a governance vote - but ig it may not matter right now. If I had to take a shot in the dark what might be interesting to automate around, I'd say it's volume. If the volume on something like the POL dips <30dma for 7d in a row, trigger the emissions manager.

          My guess is that we'd want this manager to inspire volume in the market for people to start trading/buying/selling

          I agree with your parameter proposal fwiw

          Interesting. Turning off RBS in these market conditions makes total sense. While Emissions Manager has some similarities to RBS Upper, I agree with your choice to package it as separate product. This communicates to the market that OHM is growth-focused & volatility-friendly going forward.

          Setting base emissions rate may present a problem as it's detached from any market context. Intuitively, emissions should ramp up as premium diverges upward from minimum premium (e.g. OHM emitted at +200%, then even more at +300%, then at +400%). That said, this is a first step to understanding market behavior so I don't see a problem with starting with 0.02%.

          Thought should be given to the name. While it's technically correct it's a manager of emissions, you're highlighted the wrong part (emissions). The key here is that this will accelerate treasury growth and backing appreciation. Positioning the name around this outcome could make it easier to market & talk about.

          Bullish on OHM.

            unbanksy33 base rate is multiplied by the premium so it does scale - just maybe not as fast as we would like in certain conditions..

            • Zeus replied to this.

                bowtiedohmie base rate is a mutable variable so it can always be adjusted if insufficient but if you derive equivalent rate for 2021 it was roughly 2 bps and that worked pretty well i would say, so as a starting point it'll hopefully be good. if not gov can always tune

                  Would support with the following parameters:

                  • Minimum premium of 100%
                  • BER of 0.02%
                  • YRF enabled below 100% premium and disabled above 100% premium
                  • RBS disabled
                  6 days later

                  ser bls re-add the pictures.

                  Write a Reply...