Pre-Discussion Phase: RAMM Education Guide, Call for Questions

[BraveNewDeFi]

Overview

Over the last several months, the DAO R&D team and the Foundation Engineering team have worked together to finalise the mechanism design. Currently, the Foundation Engineering team is part way through the implementation work, where they are coding the RAMM in Solidity. During this phase of the new tokenomics project, the R&D team will start the parameter discussions with the wider Nexus Mutual community.

Timeline for parameter discussions

• Pre-Discussion: Education and call for questions
  • Timeframe for discussion: 3 weeks | 24 July to 14 August
• Liquidity Parameters: How much ETH should go in the pool and how quickly
  • Opening parameters for liquidity, liquidity injection speed and ratchet speed
  • Long-term parameters for target liquidity, injection speed and ratchet speed
  • Transition from opening to long-term state
  • Timeframe for discussion: 4 weeks | 14 August to 12 September
• Oracle Buffer, Internal Price, and Initial Price Parameters
  • Timeframe for discussion: 2 weeks | 12 September to 26 September

The Pre-Discussion: Education and call for questions post is included below.

Preparing for New Tokenomics Parameter Discussion: An Educational Guide to Understand the Ratcheting Automated Market Maker (RAMM) System

This guide is designed to provide a simplified overview of the Ratcheting Automated Market Maker (RAMM) design, where we explain:

• How the RAMM works
• What the parameters are and why they play an important role in the RAMM’s launch

Our goal is to further simplify the explanations provided in the draft whitepaper, draft technical specifications, and the regular tokenomics updates ahead of the parameter discussions. We want to ensure all members understand how the system works before the parameter discussions start, so all members can engage in productive discussions and understand the impact and importance of each parameter.

The R&D and Community teams will be available to answer questions throughout this two week period. Please ask questions if there’s something that is unclear!

How the RAMM Works

The Ratcheting AMM is a two-pool system, which is built on the Uniswap V2 design with added features–namely, the ratchet, which, in the absence of members selling NXM or buying NXM, will move the price toward the Book Value, i.e., the value of assets in the capital pool per NXM.

The Below Pool and Above Pool are the two pools present in the system. These pools would contain a defined amount of ETH liquidity–which will be determined in the first parameter discussion–paired with “virtual” NXM. This creates two internal pools, which have one-sided ETH liquidity; the NXM reserves in the pool will be represented by a virtual NXM balance that changes over time as NXM is sold and purchased.

The two pools are described below:

• Below Pool. This pool handles swaps below the Book Value. NXM sold in this pool is burned and ETH is distributed from this pool. NXM can be swapped for ETH in this pool only at an NXM spot price less than or equal to the Book Value. NXM can only be sold in this pool; NXM buys occur in the Above Pool.
• Above Pool. This pool handles swaps above the Book Value. ETH is contributed to this pool and, in return, NXM is minted. NXM can be purchased from this pool only at an NXM spot price greater than or equal to the Book Value. NXM can only be purchased in this pool; NXM sells occur in the Below Pool.

Above Pool	Below Pool
1) When NXM is purchased in this pool, the price increases as the ETH liquidity increases and the virtual amount of NXM decreases.	5) During periods where no NXM is being redeemed for ETH, the ratchet mechanism will move the price back toward the Book Value.
2) This pool operates within the following price range: [(100+x)% * Book Value,∞)	6) This is the Book Value, which the ratchet mechanism will “ratchet” up to in the absence of NXM redemptions in this pool.
3) During periods where no NXM is purchased, the ratchet mechanism will move the price back toward the Book Value.	7) When NXM is redeemed in this pool, the price decreases as the ETH liquidity decreases and the virtual amount of NXM increases.
4) This is the Book Value, which the ratchet mechanism will “ratchet” down to in the absence of NXM purchases in this pool.	8) This pool operates within the following price range: (0, (100-x)% * Book Value]

How Liquidity is Managed within the System

Once the Minimum Capital Requirement (MCR) floor, which is 162,425 ETH, is removed, the MCR will be driven by the Total Cover Amount. When MCR is driven by actual cover sales, the MCR will equal:

• f(Cover) = Total Active Cover Amount / 4.8
  • As at 2023/06/14, this would result in an MCR value of approximately 7000 ETH

When this change is made, the protocol will have capital in excess of the MCR.

In the first parameter discussion, members will determine:

1. How much liquidity will be allocated to the Pools
2. How quickly liquidity will be replenished
3. Parameter adjustments for the opening phase

To understand why these parameters are important and how they impact the system, let’s review how liquidity is managed in each pool.

Liquidity in the Below and Above Pools

Members will decide the target liquidity for the pools, or the amount of ETH the pool will maintain over time. If the amount of ETH in pools drops below the target liquidity, then liquidity will be injected into the pools over time.

As members redeem NXM for ETH, there will be less ETH held in the pools until more liquidity is injected to reach the target liquidity value–this happens automatically, given the system checks if the liquidity in the pools is less than the target liquidity value at each swap. The only scenario where liquidity will not be added to the pool will be when the ETH balance in the Capital Pool is less than or equal to the MCR plus the target liquidity.

• Capital Pool < MCR + target_liq

As members purchase NXM with ETH, the amount of ETH liquidity in the pools will increase. If the ETH liquidity is greater than the target liquidity, then ETH will be removed over time and returned to the Capital Pool–this also happens automatically, given the system checks if the liquidity in the pools is greater than the target liquidity value at each swap.

During periods where members are not redeeming NXM for ETH or contributing ETH in return for NXM, the ratchet mechanism moves the price. We’ll review that in the next section.

How the Ratchet Mechanism Works

The ratchet mechanism allows for price discovery over time by either moving the price toward the Book Value over time in the Below Pool and/or the Above Pool. The selling price will decrease when NXM is redeemed in the Below Pool and the buying price will increase when NXM is purchased in the Above Pool, but the ratchet mechanism moves the prices to the Book Value over time.

In the first parameter discussion, members will determine:
4. How quickly the ratchet will move the NXM spot price toward the Book Value

Ratcheting Up in the Below Pool

During periods when NXM is not being redeemed for ETH, the ratchet will move the spot price by reducing the number of NXM in the virtual pool.

In the example below, you can see a scenario where NXM is redeemed for ETH at Step 1 and Step 6.

The graph on the left shows the spot price dropping in Steps 1 and 6 when NXM is redeemed for ETH and subsequently increasing again as the ratchet moves.

In the graph on the right, you can see the amount of ETH in the pool. As NXM is redeemed for ETH, liquidity is reduced. When the liquidity in the pool is below the target (e.g., in this case, 5000 ETH is the target), more ETH is injected into the pool over time. As the pool reaches the target liquidity, no more ETH is injected into the pool.

Ratcheting Down in the Above Pool

During periods when NXM is not being purchased with ETH, the ratchet will move the spot price by increasing the number of NXM in the virtual pool.

If someone purchases NXM, the price will increase and then, if no other NXM purchases are made, the ratchet will move the spot price back toward the Book Value in the Above Pool.

The graph on the left shows the spot price increasing in Steps 1 , 6 and 17 when NXM is purchased with ETH and subsequently decreasing again as the ratchet moves toward the Book Value.

In the graph on the right, you can see the amount of ETH in the pool. As NXM is purchased with ETH, liquidity increases. When the liquidity in the pool is above the target (e.g., in this case, 5000 ETH is the target), more ETH is removed from the pool over time. As the pool reaches the target liquidity, no more ETH is removed from the pool.

Oracle Buffer

The Oracle Buffer is the percentage value that accounts for oracle lag when calculating Book Value in ETH terms. It also serves to create a spread around Book Value. The Below Pool ratchet will actually be capped by the price ceiling and the Above Pool ratchet will be capped by the price floor.

• Price ceiling. Once the NXM spot price for the Below Pool has reached this value, the ratchet stops moving the price upwards.
  • Price ceiling = (1 - oracle buffer) * Book Value
• Price floor. Once the Above Pool NXM spot price has reached this value, the ratchet stops moving the price downwards.
  • Price floor = (1 + oracle buffer) * Book Value

This value is important, since it provides an extra layer of protection against arbitrage opportunities resulting from slight mispricings of the values of the different assets in the capital pool.

As an example, imagine there is a delay in updating an oracle for one of the assets in the pool and the true value of the pool is 1% higher than used in the instantaneous Book Value calculation. An actor who knows this could buy NXM at a cheaper price, wait until the Book Value updates and the ratchet mechanism moves the price up, then sell the NXM for a profit.

In the second parameter discussion, members will determine:

1. The parameters for the Oracle Buffer.

How the Internal NXM Price is Determined within the System

Within the Nexus Mutual protocol, NXM is the default currency. Cover capacity, cover fees, staking rewards, claim assessment rewards, and NXM burns (when claims are approved) are all denominated in NXM terms. An unstable NXM price can have significant negative impacts on the protocol’s core functions.

For this reason, the RAMM needs to determine an internal NXM price using a stable, reliable oracle. The proposed solution is to use a Time Weighted Average Price (TWAP), which is based on trades in the Above Pool and Below Pool.

In the second parameter discussion, members will determine:
2. The parameters for the Internal Price and the initial spot prices.

Time Weighted Average Price (TWAP) and Internal Price

The TWAP mechanism would work by calculating the TWAP on trades in each pool, where:

• The TWAP in the Above Pool is represented by twap_a
• The TWAP in the Below Pool is represented by twap_b

In order to avoid arbitrage, the TWAP mechanism also needs to have a limit set for both average prices equal to the spot prices:

• Price in Above Pool (price_a) = min(twap_a, spot_price_a)
• Price in Below Pool (price_b) = min(twap_b, spot_price_b)

The final internal price is determined by moving both the Price in the Above Pool and the Price in the Below Pool toward Book Value at the same speed: one price will reach Book Value and the other price is the one that will be used. This is represented by the following formula:

• internal price = price_a + price_b - book_value

TWAP Min and Max Values

To avoid large swings in cover capacity and provide extra protection against manipulation of the internal price, a minimum (min) TWAP and maximum (max) TWAP value will be used within the system. Those TWAP values are subject to discussion, but will likely be expressed as percentages of the Book Value.

If the actual market price sat outside of the TWAP (min, max) range, then the TWAP min/max values would provide a boost/dampener to the available cover capacity respectively, which would work in favour of the mutual in bear/bull market scenarios.

List of Parameters

Parameter	Description
book_value	Capital Pool in ETH / NXM Supply
oracle_buffer	Margin to allow for oracle lag when calculating Book Value in ETH. Secondary function - create spread.
liq	ETH liquidity across both pools
liq_NXM_a	Notional NXM reserve in the Above Pool
liq_NXM_b	Notional NXM reserve in the Below Pool
target_liq	Target ETH liquidity across both pools
liq_speed_out	Max amount of ETH that is removed from the pools daily
liq_speed_in	Max amount of ETH that is added to the pools daily
spot_price_a	Current price at which members can exchange ETH for NXM
spot_price_b	Current price at which members can exchange NXM for ETH
ratchet_target	Value towards which the spot_prices move
floor_price_a	Value towards which spot_price_a moves
ceil_price_b	Value towards which spot_price_b
ratchet_speed_a	Daily decrease in spot_price_a price when above target value
ratchet_speed_b	Daily increase in spot_price_b price when below target value
twap_duration	Duration over which the TWAPs are calculated

Parameter Discussions

Discussion #1: Liquidity Parameter Discussion : How much ETH should go in the pool and how quickly

This will be the main body of the parameter discussion. We will mainly focus on the amount of ETH that is available in the pools immediately after launching the mechanism, in the short term and in the long term.
The parameters to be discussed are summarised in the table below.

Parameter	Description
liq	ETH liquidity across both pools
target_liq	Target ETH liquidity across both pools
liq_speed_out	Max amount of ETH that is removed from the pools daily
liq_speed_in	Max amount of ETH that is added to the pools daily
ratchet_speed_a	Daily decrease in spot_price_a price when above target value
ratchet_speed_b	Daily increase in spot_price_b price when below target value

While the parameters fulfil separate functions, they are interlinked in many ways and setting one at a specific level to achieve one outcome often has knock-on effects on other parameters in order to preserve parity elsewhere.

There are often ways in which to achieve similar outcomes with different parameter adjustments.

We may also want separate short-term and long-term parameters, with triggers for transitioning from one set to the other.

Some of the behaviours of the mechanism affected by the parameters in this section:

Total ETH available for member exits over time

Chiefly impacted by the liq_speed_in and the opening liq value. The combination of those two parameters sets a limit on how much ETH can exit the protocol and how quickly.

Slippage

How much the price changes upon each buy and sell. Depends on the liq in the pool, which is influenced by target_liq and liq_speed parameters.

Price outcomes

Price outcomes will depend chiefly on open market behaviour, but the RAMM pool parameters can provide a greater or lesser influence on the market.

The larger the liq in the pool, the stronger the ratchet pull towards the Book Value will be, as arbitrage trades will move the RAMM price less and the open market prices more.

Ratchet_speed parameters by themselves are unlikely to significantly impact the final price outcome (assuming arbitrageurs are always active), but will enable faster price discovery within the RAMM if set to high values, but also lead to a more volatile spot price within the RAMM.

Oracle Buffer, Internal Price, and Initial Prices

The second stage of the parameter discussion will focus more on technical parameters, which should not have a significant long-term impact on the goals the system can achieve.

The oracle buffer will be the main point of discussion, as it will also act as a buy/sell spread in certain scenarios.

Parameter	Description
oracle_buffer	Margin to allow for oracle lag when calculating Book Value in ETH. Secondary function - create spread.
spot_price_a	Current price at which members can exchange ETH for NXM
spot_price_b	Current price at which members can exchange NXM for ETH
twap_duration	Duration over which the TWAPs are calculated

Questions and Comments

For the next three weeks–starting on 24 July 2023 and ending on 14 August 2023–we will be in the Pre-Discussion phase, where we are focused on educating all members ahead of the parameter discussions. Our goal is to answer any questions now and make sure all members are on the same page ahead of the discussions, so everyone understands the importance of each parameter and how each one impacts the system.

During this phase, @Rei and @BraveNewDeFi will make themselves available during Office Hours, which will be held in the Community Calls channel on the Nexus Mutual Discord from 3:00pm UTC until 3:30pm UTC every Tuesday and Thursday.

In the meantime, if you have any questions, please share them below and we’ll provide an answer as soon as we are able to.

[NXMBull]

Thanks Brave / Rei - extremely informative write up!

My first comment would be on the timeline, it seems relatively arbitrary and my suspicion is that this is rather over-kill. Don’t think we need 3 week for a pre-discussion given that many members already knew the structure of the Tokenomics upgrade plan as well as the methodology (we voted for it after all). So if discussions become a limiting/constraining factor to shipping this earlier I would implore the team to reduce the allocated discussion time (by at least half). It certainly shouldn’t take 2 months+.

Regarding the actual parameters, I had a few comments: I think it’s worth working backwards to reach the right Liquidity quantum. Taking into account the amount of excess capital over MCR at this stage, I think the right ball park amount of price impact, for a $100k redemption of NXM should be not more than 1%, we should choose the liquidity figure that gets you around that ballpark. 1% for $100k is obviously not very scientific so if anyone has a better way of quantifying the amount of price impact incurred then I would welcome their suggestion.

I also want to stress that Starting Liquidity should absolutely be more weighted to the Below Pool at the expense of the Above Pool for the time being and especially during roll-out given WNXM is still nowhere near BV (I noticed in one of the examples modelled that they were equal). I also think the {liq_speed_in} parameter should really be governed by common sense rather than anything else. If the liquidity position of the below pool is chronically undersupplied for days at a time then we shouldn’t hesitate to bump it up. Feels like 20% of Target Liq makes sense for now (i.e. 1,000ETH if Liquidity is 5,000ETH).

[go.crpyto]

Dear @BraveNewDeFi and @Rei , could you please explain in a few sentences, what RAMM is, why it is needed, and how this fits into the whole ecosystem / tokenomics / structures? Thank you.

[Rei]

Thanks for starting the discussion!

Timelines
Given the requirement for thorough testing and solidity audits on the technical implementation, the timeline here is unlikely to hold us back.
Appreciate that many people will be familiar with the design, but there will also be many who have not followed that closely, so this is an opportunity for them to join in and participate.
I think leaving 4 weeks for the main body of the parameter discussion is very reasonable, we really want no stone unturned. Given the complexity, number of intermingling parameters, and high level of community interest, I would want to support heavily with numeric simulations and examples based on what people say in the forum - hoping to do this quickly but it is not instantaneous.

Liquidity
Just to note, there is no separate liquidity for the above and below pools, there’s just one pot of ETH in the pools that increases with buys, decreases with sells and moves towards its target over time.

And agree that liq_speed_in (and ratchet_speed_b) should start pretty high to allow good amounts of redemptions at the start.

[NXMBull]

Have you read any of the past discussions? or joined the community discord discussion calls?

[go.crpyto]

Hi, I pitched at the same event as Hugh back in 2017 (Blockchain Summit in Zug), when Hugh was working on an earthquake coverage. No, I am not deep into the structures of NXM. Maybe you can produce a 200-500 words summary of documentation/forum articles via ChatGPT for me and the others who are not insiders of NXM so far? That would be great. Thanks.

[Rei]

The RAMM is a new way for members to mint new NXM tokens by providing ETH to the mutual and redeem their current NXM for ETH from the mutual. It will replace the current Bonding Curve implementation.

The current Bonding Curve has not fully met its original objectives:

• Capturing capital when lots of it wants to come in (e.g. summer 2020)
• Provide an internal value for NXM that is market-consistent (now)

The RAMM is an attempt to solve those problems while also removing the current asset lock imposed on the Bonding Curve & allowing members to redeem their NXM directly from the mutual again.

The RAMM basically has two parts:

• Two Uniswap pools that sit either side of a price line. One pool is for buying, one is for selling. You can only buy new NXM above this price line and redeem NXM below this price line. Every time someone buys, the buy price goes up, every time someone sells, the sell price goes down. The price line will be the Book Value = Capital Pool / NXM Supply. This is the ‘AMM’ part.
• As each pool is buy-only or sell-only, you need to discover at what price the buying and selling should happen. This is why we have a ratchet - the price automatically moves towards the price line in both pools. In the Below Pool, the price moves up, in the Above Pool, the price moves down. This is the ‘R’ part.

There is also a formula based on the prices in the two pools that calculates what value the mutual should assign to 1 NXM for the purposes of staking rewards, capacity calculations & buying covers using NXM.

This page might be really helpful: Token model | Nexus Mutual Documentation

[cuna_trade]

as an investor (whom unfortunately bought in @ 120-150% MCR pricing) I hope to get a return on my investment and not have to sell near or at NAV price. I’m worried about the following points:

1. how vNXM price (in the ‘above pool’) will go up if there are market makers that will probably provide liquidity for wNXM at tighter spreads on exchanges?

2. why would anyone buy NXM (using/backed by ETH) when NXM staking APY are at around 5%? they could simply stake ETH on lido with lower risks. Are APYs supposed to increase by ~4.8 (change in MCR)?

[Rei]

1. In the above pool, price goes up when people buy NXM from the protocol, and goes down over time. There isn’t really a spread to speak of unless you’re very close to the NAV (i.e. book value) - once the price is above NAV + buffer, only the above pool really gets used and there is no ‘spread’ to speak of, just a single price.

That price staying high depends on two things:

• Market values NXM above book value and the open market price sits high somewhere. That means whenever the Above Pool of the protocol drops the price sufficiently, someone buys that NXM, wraps it and sells it on the open market at a profit.
• Liquidity in the RAMM is low enough for that arbitrage effect to win out, instead of just pulling the price down.

The parameter discussion has just started, and expecting that second bullet point to be a major goal of setting liquidity levels.

2. That basically just relies on Nexus Mutual being a competitive entity.

• sell profitable covers in large volumes. Typically large tradfi insurance companies expect a return on risk-adjusted capital of around 8-10%, no reason why Nexus Mutual can’t achieve at least a similar amount. Also bear in mind that stakers only take on 50% of the risk of the covers, the rest is carried by the mutual itself.
• Make good investments with the float (e.g. we already have ~37.5% of the capital pool in ETH staking ourselves).

[cuna_trade]

Thanks for clarifying Rei.
So is it possible to sell NXM in the above pool? I though this pool was going to be used only for buying nxm.

[Rei]

You’re right - that pool is only used for buying NXM. Exiting above book value has to be through the open market - the protocol itself only allows redemptions of NXM at or below NAV - some buffer.

There’s basically 3 states we can be in assuming everyone is acting rationally with this mechanism:

1. ‘Real price’ above NAV + buffer:

• NXM Buys happen from protocol and open market
• NXM sells only happen on open market

2. ‘Real price’ below NAV - buffer:

• NXM Sells happen on protocol and open market
• NXM buys only from open market

3. 'Real price between NAV - buffer and NAV + buffer

• All activity on open market

[logic]

One point to make on the yield competitiveness of the protocol.

We’re currently overcapitalized. So cover fees are being spread thin across a large NXM base.
If folks exit, the NXM supply will shrink, and the remaining holders will enjoy a fatter yield from cover fees.

ETH staking yield will obviously scale with the size of the treasury, but the Nexus-specific source of yield, cover fees, will increase in concentration to remaining NXM as outstanding tokens are burned.

[GordonGekko]

This. My own experience was that cover was slightly underpriced in the v1 beginning. V2 makes the relationship between pricing, capital pool and yields much more dynamic. Members doing the above {ETH LST vs NXM yield} comparisons do not appreciate that cover pricing is now more dynamic, and there is survivor bias to yields. Also ETH LST yields will trend downwards inexorably towards ~3% over the coming year as total Ethereum staking goes up to more normal levels. A surge for the lifeboats among Nexus Mutual stakers will make for an interesting dynamic for the stakers remaining on the ship…fingers crossed!