Tokenomics Update - May '23

[Rei]

Hi everyone,

Will be providing updates in this section of the forum from the team & the engineering effort as we work through the detail of implementation.

First up is a slightly modified version of @Hugh’s recent Discord update.

Aiming to post here regularly to keep people up to date.

The Nexus Mutual Foundation and DAO teams had an offsite in Lisbon recently, and dedicated time to review the tokenomics changes members have signaled support for.

The goals of the workshop sessions were to:

• Understand the mechanics in detail
• Identify any big technical challenges that might require revisiting the business requirements documentation and/or proposed Ratcheting AMM (“RAMM”) design
• Identify any areas of concern from an edge case and/or attack perspective
• Discuss the need for a TWAP and brainstorm potential solutions (biggest gap in the current business requirements)

The workshops went really well. During discussions, Hugh & the engineering team didn’t run into any obvious technical issues. There is one potential attack scenario, where oracle manipulation could take place on the TWAP, so this will be top of mind while reviewing solutions.

The team has identified several potential solutions, which will be further researched, reviewed, and discussed. Worth noting that finding a solution is more of an optimisation issue than any big research work to be concerned about.

After the offsite, the next step is for the engineering team to draft the detailed technical specifications & for myself/Hugh to support with ad-hoc scenario analysis and decisions around specific edge cases that arise.

Once this step is complete & the engineering team move to implementation, we will kickstart the community discussions around parameterisation, focussing on initial and ongoing liquidity injections into the RAMM pools.

It was agreed that some of the engineering team will focus solely (as much as possible) on the tokenomics project. This will ensure we continue to make progress.

There is no firm timeframe for the tokenomics project like many have requested. Security is our first priority, and we will provide regular status updates and keep members informed of next steps.

[logic]

New here, so let me know if I missed something in my understanding.

TWAP on price oracle makes sense, and probably doesn’t even have to be that long. Likely on the order of 2 or 4 hours. Could align it with pool-update keeper cadence parameter for mental consistency.

Realistically if price spikes down that hard and there’s a protocol-backed redemption mechanism (that will eventually correct things), any market participant and their mother is going to buy up the dumped NXM. The down-spike will be very short lived in the context of a 2 or 4 hour window and the “attacker” will instead feel immense pain at a disgustingly costly sell overshadowing a few % upside.

TWAP can be approximated in a contract friendly way with EMA type time smoothing.
TWAP is fixed window and requires keeping that window available any time the oracle price is required. Would need to be an external compute.
Exp smoothing only requires the last value and its time. Can be stored and computed live in contract.

[Rei]

Further update on ongoing work from my end.

Aiming to post another update by end of week on:

• engineering implementation progress
• moving price target work (see below)

Next week myself & the engineers are working in person to finalise outstanding design issues (whether the price target can move & TWAP design) based on numeric simulations & viability of engineering implementation.

“Can we stay at 2x BV in medium-term” modelling examples
Aim here was to confirm that we can sit at a price point that’s different to book value in the medium term.
This would mean that (a) we can actually capture capital in some realistic scenario, and (b) that there is a need to move the “system price” (used for pricing covers in NXM & emitting staking rewards) away from Book Value.

Chose 180 day period and used an opening price of 2x current book value & current size of capital pool.
Some examples of results & conclusions:
1.

Here, if members inject 25.1 ETH/day (equivalent to $48,000 at current prices, or about 3% of current daily wNXM volume) coming in would roughly keep the price at 2x Book Value if the target liquidity for the “above book/buy” pool is 2500 ETH. Seems reasonable that the mutual here would be a price taker of the market. We would capture roughly 4500 ETH over the course of 180 days.

Doubling ETH liquidity in the RAMM pool to 5000 ETH would result in a linear increase in the amount of ETH (2x compared to previous example) required to maintain 2x Book Value (~50.4 ETH/day or ~$96,000, which is 6% of typical daily wNXM volume). This scenario would also capture double the ETH in the capital pool at about 9000 ETH over the course of 180 days.

3. Different Ratchet Speeds
   
   

Big impacts can be observed from changing the ratchet speed, even a 0.5% of BV/day change moves the outcome to either the NXM price skyrocketing or falling down towards book value. However, in practice, at the discussed levels of volume required, likely outcome would be incoming ETH amounts changing to solve for market price, rather than internal RAMM price diverging from market view.

Conclusions
Given above examples and the low percentage of market volume required to maintain price away from ratchet target, seems entirely possible that the mutual acts as a price taker at a level significantly different from book value. This confirms that capital capture should be possible in “good times” & implies that it’d be difficult to simply pin the system price for cover buys/rewards/capacity to book value without appropriate adjustment mechanisms.

Upcoming parameter discussions with the community should focus mainly on answering the question “what % of daily wNXM volume should we be targeting when the price is above book?”.

Combined Price Ratchet and Liquidity Injection/Removal into a single function in the RAMM simulation
This was done to bring the model in line with the proposed engineering implementation.

Current work: splitting RAMM simulation model into 2 pools (above target and below target) with separate NXM prices.
This is also done to allow for the proposed engineering implementation.

The current python model acts as a single pool that can sit either above or below ratchet target price, with NXM buys from the protocol disabled below target and sells disabled above. The proposed engineering implementation has 2 pools - one above and one below the ratchet target.

The member buy, member sell and ratchet/liquidity functions have been successfully split into two and currently working on adapting the one-day-passes loop to act appropriately when two different RAMM system prices are present.

Splitting the model into two pools is required to properly test the TWAP (see below) & investigate possibility of having a moving ratchet target that isn’t fixed at book value.

Next steps (all with dependency on the split model mentioned above being in place):

• Moving mid value:

  • Problem: can we detach from Book Value & have the ratchet target value more closely follow market sentiment AND not dilute users?
  • Possible solution: Target value starts moving away from BV after some time/volume spent significantly far enough away from current target
  • Liquidity would need to work appropriately:
    • When buy/sell split point moves away from BV, the “dilutive zone” is likely to have lower liquidity
    • Can’t have situation where RAMM pool liquidity movements from buys/sells aid dilution of book value

• TWAP quantitative simulations based on currently favoured qualitative approach:

  • Volume-weighted average of actual RAMM trades within a certain time window
  • TWAP also moves automatically towards target value over time
  • Absolute ceiling and floor as some % of target value
  • Investigations on parameters around those components

• Low liquidity scenarios - confirm the model behaves well when:

  • Combined wNXM and RAMM liquidity is low
  • RAMM liquidity only is low
  • wNXM liquidity only is low

[vincentj]

Awesome work in general, just having trouble getting the high level picture of

1. how the ratchet etc behaves, is it market neutral or applying something similar to buy pressure?
2. how much of nexus eth is gonna be deployed into this mechanism?

[Rei]

Hi Vincent,

1. You should be able to read through the high level design here: Nexus Mutual Tokenomics Proposal - Design v1.3
   Generally, there’s always at least a small amount pressure applied, but can be increased through changing parameters, mainly liquidity.

2. Amount of liquidity to be deployed at the start and on an ongoing basis will be the main topic of the upcoming community discussion on parameterising the mechanism ahead of launch.

[vincentj]

Awesome, thanks @Rei, appreciate this work, and it finally being executed in well thought out manner!

[Rei]

Update before heading off for the weekend.

• Successfully finished splitting the RAMM simulation model into two pools.
• Created a model that allowed for a moving target for the ratchet mechanism away from book value & tested various levels of liquidity.
  Example output of this model, that includes some assumptions around:
  • No one buying NXM at a price 3x above book value.
  • Target liquidity for both buys and sells in dilutive range is 1/4 of normal target liquidity
    
    

Next steps:

• Add back wNXM market impact & arbitrage to 2-pool model & test under different market circumstances.
  Decision to be made whether we want to put this forward as an option. Pro: would avoid the appearance of a book value anchor. Con: Additional complexity and potential for intermittent dilution of book value.
• Quantitative TWAP analysis. Prioritised moving ratchet target testing over the TWAP testing as any changes here would impact the main body of engineering implementation work, whereas the TWAP is more of a standalone piece.

Engineering team have been focussed on developing the environment setup for testing the solidity implementation & providing feedback/challenge on the above.

Next week myself and Engineering team are all together in person to finalise the moving target value issue and the TWAP design before code implementation.
Aiming for a new update after coming back from that.