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:
- Bringing the internal protocol NXM price and open market price close together
- Increasing Book Value over time
- Initially providing significant exit liquidity at a price close to Book Value
- Eventually following the open market price
- 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.