Request for Comment - Tokenomics Design Detail

Nexus Mutual Updates Tokenomics
1

Hi all,

This post is intended as a place to discuss the next level of detail regarding the model outlined in Nexus Mutual Tokenomics Proposal - Design v1.3 following the snapshot vote to proceed in this direction.

It also contains an update & description on the current workstreams, building on the previous update.

The next milestone is an updated specification doc that contains the next level of detail compared to the design doc linked above and can act as a basis for the engineering team to commence their work.

Following this milestone, we can proceed to setting parameters for initial/ongoing liquidity, ratchet speeds, etc., so please do not discuss numeric parameter values under this topic.

The target deadline for this next step is the end of March, so any additions, comments on the below and following updates should be made by those wishing to contribute before March 31st.

Updates on workstreams following in-person session last week:

  • Currency of redemptions
    • Working on the basis of keeping ETH as the only entry/redemption currency due to technical simplicity
    • Not relevant in current capital position, but if we get closer to Capital Pool = MCR, there will need to be a balancing between (1) Entry/exit pool liquidity, (2) “cash” for claims, and (3) investment assets, both liquid and illiquid
    • All of this can be managed using the swap integrations present in the v2 smart contracts, but defining a more formal plan for how to change the parameters under different circumstances will be required in parallel to the technical implementation work
  • Buying/selling availability
    • To improve UX and price discovery it’s better to have member buys above book value and member redemptions below book value enabled at the same time
    • This would lead to operating 2 distinct pools in parallel - an entry pool and exit pool, with separate liquidities. In the entry pool, liquidity would be deposited into the pool via user entries and withdrawn by the system. In the exit pool, liquidity would be deposited by the system and withdrawn by users
  • TWAP for establishing system price. A system price needs to be established by a weighted average of recent prices in the two pools.
    • Needs to be immune to manipulation, with the main likely attack vector being driving the price of NXM down to an extremely low value and then minting staking rewards through cover buys
    • Standard time-weighted geometric mean approach might not work as price might change significantly through the ratchet mechanism with no buys/sells occurring in the meantime
    • Some options: very long duration and/or reduced weights on price movements outside of x% of current TWAP.
    • Working to model scenarios & cost of attack vs. oracle responsiveness, aiming to come up with a formula suggestion ASAP
  • NXM price shock upon transition from Bonding Curve.
    • Don’t want instant shock on system NXM price, which would have a large impact on staking value and, hence, capacity
    • Plan A to avoid temporary transition code is setting the initial parameters of the TWAP so as to ensure smooth transition
  • Oracle safety buffer
    • There is the possibility that Book Value as per the system is slightly out due to oracle errors / delays on assets held in the capital pool
    • Expecting to implement a buffer of +/- 1-2% around book value. This should prevent the majority of arbitrage opportunities and essentially acts as a buy/sell spread around book value
  • Soft launch
    • There have been some suggestions that we should test out the system on-chain without deploying the full amount of opening liquidity ahead of full launch
    • This approach could test the technical implementation, but not the market impact, which very much depends on the liquidity deployed
    • Hoping that “soft launch” approach is unnecessary, as should be able to prove hard limits on worst-case scenarios through parameter setting and technical robustness can be assured through usual testing & audits approach
    • In unanticipated extreme scenarios could be possible to use emergency stop button
8 Likes
2

First of all, thank you very much for your work. I appreciate the efforts made to keep it simple and understandable while facing complex design challenges.

In regard to the necessity of a soft launch, I believe it would be more efficient to run multiple scenarios and analyze data before the launch.
A soft launch without actual economic conditions will likely only be a “test in prod” for the code, which should be focused more on the development stage with audits.

4 Likes
3

Hi Rei

Ty for your hard work. Wanted to chime in w feedback as a member excited for this change.

  • Agree ETH should stay as the redemption/entry currency. There should be a future proposal to switch to some liquid staked eth product but I don’t think it should involve this change.

  • Liquidity for exit pool should be significantly large. We have spent a long time below book value and many have been frustrated and want out. It would be quite nasty if there was small liquidity and members who want out were forced to pvp with each other. The goal here is to create trust and good vibes where nobody is complaining or angry.

  • One idea to assess size of the liquidity needed would be to hold a snapshot vote (WNXM probably needs to be included). It would just be a signalling vote where members could say “yes I am considering leaving” or “no i am not”. It would be non binding, but just give us a sense of how much nxm is considering exiting.

  • I think I don’t understand the twap point so well so I’ll follow up in discord.

  • For how long it should take to get to book value, I think we should have a goal of within 30d of new tokenomics launch.

  • Agree that a soft launch is not needed

4 Likes
4

It’s quite sad to see lack of engagement here from community so I made account to express my gratitude for all hard work going into this tokenomics change. Thank you for that! Hopefully in future more members (and non members - plz remove kyc :sweat_smile:) will join forums for discussion.

Now my 2c of feedback.

  • Currency of redemptions - ETH as entry/exit currency is obvious choice. This could be discussed in future in case Capital Pool asset allocation changes significantly (if ETH and ETH equivalents stop being highest % holding)

  • Buying/selling availability - Initially exit liquidity pool should be significantly larger and we should be ready to swiftly increase it if sell pressure turns out being higher than expected. Later, when that initial spike of sellers runs out and market price stays around book value comfortably we can adjust parameters to lower this pool to optimize for investments.

  • TWAP for establishing system price / Oracle safety buffer- Does it have to be TWAP of wNXM price? Wouldn’t it be safer to implement two oracles. One oracle that informs about current book value per NXM and 2nd oracle that is based on wNXM market price with some TWAP implementation (sorry I’m not rly math guy so no suggestion on what formula might work here). I’m aware that such “Book Value Oracle” can be very tricky to create, especially if we would want to expand on investing front. IF it could be implemented it should provide huge safety net against any wNXM price manipulation. When protocol sells/mints NXM it could take higher from those two responses to minimize amount of new NXM entering circulation and protect from manipulations trying to mint more than it should be able to.

  • NXM price shock upon transition - That’s a tough one. I’m agreeing that it can’t be single daily candle that takes us to BV, something would break 100%. Looking at daily rate of change in price of wNXM/ETH pair I see multiple instances of daily price movements by more than 10% (with outliers going as far as 30%). If nothing broke at those days we should be fine here. Aiming for 4-6% daily move just to be on safe side should do the trick while not prolonging it unnecessarily. I think it’s pretty much what Hugh said in initial discussion about ratchet mechanism.

  • Soft launch - I highly doubt soft launch would meet with same reaction from market participants as real thing. If code works as intended it’s good enough.

3 Likes
5

Hey Rei and Team, thanks for putting this together.

Like Wazzup I’m also kind of shocked at the lack of engagement here, but it is what it is.

  • Currency of redemption being ETH makes a lot of sense - no need to swap to an alternative currency

  • I agree with dcf and wazz here that the liquidity provided for this initiative needs to be significantly large to allow members an exit, I like the idea of doing a snapshot vote to gauge initial liquidity needs here. Of course as people swap out at book value, liquidity needs will likely diminish

  • I don’t really understand " TWAP for establishing system price . A system price needs to be established by a weighted average of recent prices in the two pools." could you provide some clarity (an ELI5) whats meant by a systems price based on recent prices? Wouldnt you just want to twap up to book value less any buffer?

  • Creating a buffer spread of +/- 1-2% makes sense to me

  • Proceeding with a soft-launch doesn’t make much sense

Looking forward to this getting implemented as soon as possible now that v2 is live!

2 Likes
6

Some thoughts/comments on the TWAP stuff:

Need for a “system price”

When members buy cover, the system mints NXM equal to 50% of the cover fee and pays it out to those staking.

Premium is in ETH/DAI, but rewards get paid in NXM, so we need an NXM price that is used by the system to figure out how much NXM gets paid.
NXM price is also used to establish how many covers of a specific type the protocol will allow users to buy, so also need an NXM price for this part.

Can’t really use the last price for a buy/sell in the AMM pool, as that can fluctuate quite a lot & bounce between buys above book / sells below book, you want something more stable over time.

To be clear, buy/sell prices would still based entirely on the AMM pool, what we’re talking about here with the TWAP is the NXM price used to determine capacity and rewards for cover buying.

Attack vector description when there is no average price

One problem is that users with lots of NXM can drive down price on the buy/sell pool to a very low level then mint NXM rewards via cover buys.

For example, let’s say the liquidity of the Ratchet + AMM pool is 5000 ETH and a current price of 0.01 ETH, so there is 500,000 NXM notionally in the pool.

This means, in theory, someone with 2m NXM can sell all of it and get out 4000 ETH. There’s now 1000 ETH in the pool, and 2.5m NXM, so the end price per NXM is 0.0004 ETH.

If the system took the price as 0.0004 ETH immediately, the attacker could buy a cover on a pool where they are the only staker using the ETH they obtained and mint 50% * 4000 / 0.0004 = 5m NXM, so they’ve basically just conjured 3m NXM out of nothing.

Having some sort of average price over time calc makes sense to prevent this.

Having played around with it a bit, I’d also think we might want to consider a floor for the system price of e.g. 33% or 50% of book value in addition to taking a TWAP of the AMM pool, so that the attack described above is fully impossible.

Using wNXM as a price oracle
One of the reasons behind the proposed mechanism is that we can determine the price internally within the protocol & not have to rely on an external wNXM oracle for the price. For something this fundamental to the protocol, would rather not have an external reliance on an oracle provider or data from external AMMs.

2 Likes
7

Hey Friends,

My name is Curious Rabbit, we recently started a funded research group on Bonding Curves. You can find out more about it here, https://www.notion.so/Bonding-Curve-Research-Group-a0fe00e81d84435a8fddd547a7888063?pvs=4

i’ve been going through all of the documentation on whats happened whitepaper, proposals, forum post and comments etc… for our own case study analysis

I believe the issues you have run into are similar to the issues others have run into. Perhaps this can be quickly summarized as going from a bootstrapping phase that has particular requirements to a more mature phase that has different requirements and planning that transititoin from one to the other

I do not have any answer for you at the moment as to how to solve the problem but i just felt compelled to say something after researching this

  1. Both proposals of retaining the bonding curve but modifying it or introducing a Ratcheting AMM Design have merit

  1. it may be in the best interest of the mutual to pursue the modelling and scenario simulations for both cases. The capital at risk is quite high and this issue is worth it

  2. when i work with clients, we come up with a list of requirements. This list of requirements is then used as a benchmark for several designs. We choose the design that meets these requirements. The requirements were done in the Tokenomics Design, i cant comment to their thoroughness, but i believe it is worth it for the mutual to agree upon requirements first and then model and simulate the proposed designs to see which one stands better. Rather than choose one over the other. Both should be seriously considered and put to the test and its worth spending money to do that

Its no joke to introduce alot of new complexity to your system, it can have unexpected consequences once again and lead to new issues. So there is merit to the simpler solution. But it can be pretty disheartening to have your capital pool decrease in BV so much (as may be caused by modifying the Bonding Curve) and that may not be acceptable. So perhaps there needs to be some adjustments to the proposed designs as well to meet requirements better

Anyways, thank you all for the rigor of thought put into Nexus Mutual, the new proposed designs and everything thats going on. It is a great case study to learn from and will benefit the space moving forward. You guys are Pioneers :blue_heart:

1 Like