Liquidity Parameters Discussion (Part 2) | What parameters do we need to achieve the outcome members' signalled support for in Part 1?

[BraveNewDeFi]

Liquidity Parameters Discussion (Part 2) | What parameters do we need to achieve the outcome members’ signalled support for in Part 1?

Overview

In this discussion, members will discuss and share their views on what parameters are needed to achieve the outcome that members’ signalled their support for in the Liquidity Parameters (Part 1) Snapshot signalling vote.

The aim is to review the parameters, analyse R&D’s simulation and modeling of different potential parameters and how they impact the RAMM (shared below), and share our respective thoughts on the parameters that would help members’ achieve the outcomes that were discussed during the Part 1 discussion.

Members signalled support for the following:

• [Question 1] Option C: 30% | 2,028,000 NXM, 43,750 ETH
• [Question 2] 1 month
• [Question 3] 3 years

During Part 2, we have four (4) main parameters to review, analyse, and discuss.

Goal

At the end of the Part 2 discussion (29 August to 11 September), members should have several potential parameter packages (i.e., different parameter groups) that can be used to create a Snapshot signalling vote, which will be used to gauge member sentiment on the starting parameters for the RAMM at launch.

Parameters discussed in Part 2

The parameters that will be discussed will be:

Parameter	Description
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 (long-term)
fast_liq_speed_in	Max amount of ETH that is added to the pools daily before the initial_budget is redeemed
initial_budget	ETH amount to be redeemed before switching from fast_liq_speed_in to long-term liq_speed_in
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

We shared a primer on the parameters in the RAMM Education Guide, which we’ll include below to ensure everyone understands how the three (3) questions in Part 1, which were supported in the signalling vote, affect the RAMM’s performance.

While the parameters fulfill 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.

Total ETH available for member exits over time

In Part 1, members signalled support for initial liquidity of 43,750 ETH. This value will influence the target_liq and initial_budget parameters, with the target_liq as the amount of ETH members want to maintain in the RAMM over time.

During the Part 1 Snapshot signalling vote, members respectively voted for the following:

• 627k NXM signalled support for 43,750 ETH as the initial liquidity for the exit period

Members also signalled support for an initial exit period of 1 month, with a long-term timeframe to reach the cover-driven MCR of 3 years.

The liq_speed_in will determine how quickly members can redeem NXM for ETH and how long it takes to replenish RAMM liquidity, if the liquidity in the RAMM drops below the target_liq value.

Slippage

The slippage—how much the price changes with each NXM buy and sell—members realise when they redeem NXM for ETH or buy NXM with ETH will depend on the liquidity (liq) in the pool, which will be influenced by the 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.

Timeframe for discussion

This discussion will take place from Tuesday (29 August) until Monday (11 September).

• During the third week (29 August to 11 September), members can discuss, share analysis, and edit/suggest the potential parameter packages, which will be presented as choices during the Snapshot signalling vote.

Snapshot signalling vote

Once members have shared their views, the R&D team will use the community’s responses to create a non-binding Snapshot signalling vote to gauge sentiment around the parameter package that should be used for the RAMM’s launch.

The Snapshot signalling vote will be held from Tuesday (12 September) until Sunday (17 September). The results of the Snapshot signalling vote will be posted on the forum on Monday (18 September).

Overview & Resources

We’ve outlined the scope of the Liquidity Parameters Discussion in the Overview post. You can refer to this post for an introduction to both Parts 1 & 2 of this discussion.

If you have questions about the Ratcheting AMM (RAMM) or you want to learn more about the RAMM itself, please see the Pre-Discussion Phase: RAMM Education Guide, Call for Questions post.

If you want to catch up on the Liquidity Parameter Discussions (Part 1), see the Liquidity Parameters Discussion (Part 1) | How much ETH liquidity do we start with? post on the forum, where you will also be able to find the results of the three Snapshot signalling votes.

[ReeseWickham]

Is that R&D’s simulation and modeling of different potential parameters and their impacts on the RAMM still going to be shared imminently? is there any problem?

[Rei]

Thanks @BraveNewDefi for the overview.

Wanted to put forward a potential set of parameters that in my view would achieve the goals implied by the results of the snapshot signalling votes. Please comment, pick apart, suggest changes, come up with alternatives, etc.

Note that as the modeling developed based on the outcomes of Stage 1, I decided to just put forward one parameter package from my end.

The modeling scripts can be found here. The runs included here were done on a deterministic basis, and only include interactions with the protocol itself.

The following parameters are included in this part of the discussion as per the whitepaper and overview post.

Parameter	Description
target_liq	Target ETH liquidity
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.
fast_liq_speed_in	Max amount of ETH that is added to the pools daily before the initial_budget is redeemed
initial_budget	ETH amount to be redeemed before switching from short-term to long-term liq_speed_in
ratchet_speed_a	Daily decrease in spot_price_a when above target value
ratchet_speed_b	Daily increase in spot_price_b when below target value

The system is being developed with one ETH liquidity across both the Above and Below pools. Therefore, it is important to select a target ETH liquidity in the pools that achieves the goals set in Stage 1 of the discussion, while allowing for proper price discovery in the context of the rest of the market, as well as allowing growth via the Above Pool in the upside scenarios.

As a reminder, the broad goals for the RAMM are:

1. Bringing the internal protocol NXM price and open market price close together
2. Increasing Book Value over time
3. Initially providing significant exit liquidity at a price close to Book Value
4. Eventually following the open market price
5. Sustainably capturing capital in the mutual when open market price exceeds book value

(1) and (2) are achieved by definition via the design of the RAMM mechanism. (3) Was addressed in Stage 1 of the discussion, and therefore some parameters will be locked in. This conversation should, in my view, mainly focus on how to best achieve (4) and (5) given the constraints from (3).

For me, the main topic in this conversation is setting the slippage on buying and selling NXM via the RAMM, and then finding an appropriate ratchet speed to enable price discovery.

Parameters Derived from Stage 1

Interpretation of Results

Here’s my perception of the outcomes from Stage 1 of the discussion:

Question 1:
The snapshot vote had almost half the votes go towards the 30% option, with the weighted average outcome landing at 28.6%, so targeting 30% of NXM exiting near book value seems appropriate.

Question 2:
~80% of NXM voted for a 1 month period over which the initial exit amount would happen. Weighted average lands at about ~1.2 months, targeting 1 month for simplicity seems reasonable.

Question 3:

~80% of NXM voted for a 3 year period over which the remainder of the ETH could exit. The weighted average landed at 2.63 years, so I believe it’s reasonable to target 3 years for simplicity.

Finally, there needs to be an interpretation of what ‘near book value means’ - for the following parameter suggestions I’m going to use at least 95% of BV to mean ‘near’.

Stage 1 Parameter Suggestions

Taking the above interpretations of the results as fixed, and opening with our target liquidity to immediately set the slippage to that desired, we can derive some of the parameters as follows:

• initial_budget = 30% of Capital Pool = ~ 43,835 ETH
• fast_liq_speed_in (short-term) = initial_budget / 30 days = ~ 1,500 ETH
• liq_speed_in (long-term) = (70% of Capital Pool - MCR) / 1,066 days = ~100 ETH / day

Potential Parameter Package

In this section I will put forward a potential set of other parameters that, combined with those derived from Stage 1 above, could achieve the outcomes agreed in Stage 1, as well as some of the broader goals of the RAMM.

Note that because of the goals agreed by the community in Stage 1, I will be proposing long-term and short-term ratchet speeds that work in the same way as the long-term and short-term liquidity injections.

Some additional goals that were set to put some lines in the sand during the modeling:

• The long-term ratchet speeds are adequate for price discovery at a reasonable time-frame - a maximum of weeks, not months, even after large market shifts.
• Suggestion would be that we allow the price to start significantly moving upwards/downwards at around 100 ETH incoming/exiting / day, which would equate to capturing just over 10% of typical daily market volume.

liq_speed_out

This parameter - the ETH removed daily from the pools - only kicks in if liquidity is above target, meaning the RAMM is actively trading in the above pool.

A high withdrawal rate means the slippage remains largely constant with respect to ETH entries, allowing the price to rise steadily relative to the incoming ETH.

A low withdrawal rate means the slippage decreases with higher entries, dampening the price increase.

Therefore, suggest setting liq_speed_out = 100 ETH / day in order to not dampen the price rise when 100+ ETH enters the system per day.

Setting to this value also has the additional benefit of having symmetry with the long-term withdrawal value and therefore not setting preferred treatment to buyers or sellers from the start.

target_liq, ratchet_speed_a, fast_ratchet_speed_b

Setting these parameters involves balancing out slippage (high slippage advantageous to long-term holders, disadvantageous to immediate buyers/sellers) with a ratchet speed that allows reasonable price discovery in the above pool, and moves the price up quickly enough during the initial phase in the below pool.

The triangle between the three parameters of target_liq, ratchet_speed_a and fast_ratchet_speed_b is ultimately what resulted in putting forward a single set of parameters instead of a high slippage/low slippage version as originally intended.

The suggested parameters are as follows:

• target_liq = 5,000 ETH
• ratchet_speed_a = 4% of BV / day
• fast_ratchet_speed_b = 50% of BV/day

This would mean that the slippage encountered on swapping ~$100,000 worth of NXM for ETH near book value (0.021 ETH) would result in slippage of ~1.2% for the user, with the price moving ~2.4% as a result of the swap. In the initial stage, this price movement on redemptions would be reversed by the ratchet in about 1 hour, whereas for mints in the above pool, it would be reversed in about 14 hours.

In the sections below I will often compare outcomes to the target_liq = 10,000 ETH version explored as an alternative.

Initial Stage

Allowing for the Stage 1 parameters, assuming a target_liq and assuming 30% of the supply (~2,025,000 NXM) will want to exit, with a minimum acceptable price of at least 95% of BV, resulted in deriving the fast_ratchet_speed_b.

Linked is a comparison between setting the fast_ratchet_speed_b to 50% vs setting it to 45%.

We can see that in the 50% BV/day version, all 30% of NXM wishing to exit can do so without delay in 30 days, while in the 45% version, there are periods where users have to wait for the price to go back up, and the eventual exit time is closer to ~45 days. Taking the minimum viable value of 50% here is sensible as it enables the maximum price discovery and maximises exits below the assumed 95% of BV threshold.

Above Pool

Given the target_liq and price-go-up-at-100ETH-in-per-day goal, we can derive the long-term ratchet speed in the above pool as the max value that allows the price to go up at 100 ETH of buying/day. The max value that still allows price to move implies the fastest price discovery. This value lands at 4%. The 3% version, as expected, moons much quicker, while the 5% version does not move off the price floor.

Side note - the main reason for rejecting the 10k ETH target liquidity option was that the equivalent outcome required a ~1.5% BV/day ratchet, which is probably too low when it comes to price discovery in a reasonable time frame.

Note also that if users are targeting a particular maximum price at which they’re willing to enter, having a balanced slippage/ratchet combo results in very similar outcomes regardless of target_liq at high BV thresholds - see the 10k version and 5k version with optimal ratchet speeds and users refusing to buy NXM above 2x BV. At lower thresholds (e.g. users refusing to buy above 1.2x BV) the 5k version (with 3.75% ratchet speed to exactly match price growth) allows for more capital capture than the 10k version.

ratchet_speed_b

Propose setting the long-term ratchet speed in the below pool to match that of the above pool.

• ratchet_speed_b = 4% of BV / day

This is again largely to create balance between the opportunities afforded to buyers and sellers.

Proposed Package

Combining the above, this is my proposed parameter package.

Parameter	Description	Value
target_liq	Target ETH liquidity	5,000 ETH
liq_speed_out	Max amount of ETH that is removed from the pools daily	100 ETH
liq_speed_in	Max amount of ETH that is added to the pools daily.	100 ETH
fast_liq_speed_in	Max amount of ETH that is added to the pools daily before the initial_budget is redeemed	1,500 ETH
initial_budget	ETH amount to be redeemed before switching from short-term to long-term liq_speed_in	43,835 ETH
ratchet_speed_a	Daily decrease in spot_price_a when above target value	4% of BV / day
ratchet_speed_b	Daily increase in spot_price_b when below target value	4% of BV / day
fast_ratchet_speed_b	Daily increase in spot_price_b when below target value before the initial_budget is redeemed	50% of BV / day

Next steps

Please suggest alternative packages and scenarios to test, happy to go away and do some modeling to investigate any concerns/scenarios raised by the community.

If a sufficiently robust alternative package emerges from that process, we can have a snapshot vote at the end of the week to get a view as to which set of parameters the community would prefer.

Note also that our engagement of Chaos Labs to provide an independent check of the mechanism and parameters via testing of edge cases and potential outcomes has begun. We will ask them to specifically focus on the parameters agreed here by the community as a base case, but we will/should remain open to being proven that they do not work in certain scenarios, in which case we may have to collectively reassess once they’ve completed their investigations.

Note that the Liquidity Parameters agreed by the community in Stage 1 will remain the guiding North Star in all parameter work - whatever set of parameters is ultimately agreed will need to meet those goals.

[ReeseWickham]

Thanks @Rei for the amazing work and the clear explanation. It looks good and I believe that with the parameters signaled by the community in the snapshot vote, there’s not that much room to play around with the rAMM parameters, your proposed solution is probably the optimal one, and I’m guessing that this is the reason as well why there have been no alternative proposals or suggestions.

Considering that currently there’s only one set of parameters on the table, there should be no need for a new snapshot vote? what do you think @BraveNewDeFi?

Maybe we could move this week directly to discuss the next parameters in the plan that you outlined?
" * Oracle Buffer, Internal Price, and Initial Price Parameters"

[Rei]

Yep, agreed that we currently don’t need a new snapshot vote as there haven’t been any alternatives put forward.

Would think it makes sense to give people to the end of this week to suggest alternatives before starting the next phase and for my part still need to do a bit of work ahead of next discussion.