Tokenomics Update - June '23

[Rei]

Hi everyone,

Had a successful week in person with the engineering team ironing out the final kinks in the design.

• Solidity implementation details around the ratchet and liquidity mechanisms finalised.

• We have a TWAP mechanism that we’re happy with for the internal price.
  The mechanism combines separate Uniswap-style TWAPs above [price(a)] and below [price(b)] book value, then finds the final price using price(a) + price(b) - Book Value

• We have a solution for a smooth transition from the current bonding curve price to the new internal price by appropriately setting the initial prices of the above and below pools.

• We have a solution for the case where the Capital Pool approaches the MCR amount to keep a market consistent price. We’re planning to allow the price ratchet target to move away from book value and letting the buy price drift below BV.

• Examined a range of edge cases in the context of the new elements and the design as a whole

I have a bunch of simulation work to do on the new design, converting it to be closer to the required solidity implementation and testing some of the new mechanisms. Will also write up the solutions in a separate full document for public scrutiny.

Next steps for engineering are to finalise the technical specs based on the design discussed above and move towards implementation.

Generally, we’re happy with the system behavior qualitatively in pretty much all cases, now begins the work of fully battle testing it from an economic and technical perspective, including technical tests, audits and simulations.

[0xLux]

Great update here @Rei !

I’m glad you guys landed on a mechanism design that checks off your criteria.

Still seems like there is a lot of work ahead. Can you provide us with a rough timeline for next steps regarding the points below?

• simulation work on new design
• converting it to be closer to the required solidity implementation
• finalzing the technical specs based on the design above and moving towards implementation

From where things are now to launch, whats a realistic estimate?

[ycyc]

Would you mind to explain what you mean by allowing buy price to drift below BV?

[Rei]

@0xLux
The first three bullets you mentioned are being worked on at the moment and we should have an updated simulation environment and tech specs within the next few weeks.
As an example for the simulation, price ratchet & liquidity injection functions should only update on actual member interactions with the system, as that’s how it would work in the solidity implementation.

As for launch, hard to put a timeline on it. There is indeed a lot of work ahead & the focus is on making sure we cover off everything, do it once and get it right.

@ycyc

The solution generally treats Book Value (Capital Pool / NXM Supply) as:

• the line below which swapping ETH for NXM is not allowed, as the mutual would be “selling cheap” NXM, Book Value would decrease & existing members would get diluted
• Below this line, members can still redeem their NXM for ETH, as the mutual is happy to “buy cheap” NXM from members
• to enable price discovery with the market below this line, the price at which the protocol lets members swap NXM for ETH moves automatically towards the Book Value target (we call this the ‘price ratchet’)
• this price discovery works well as long as there is sufficient ETH liquidity in the pool so that the AMM price movements from members selling and the speed of the price ratchet balance each other out to find the right market price

However, if the amount of capital we have approaches the MCR (i.e. the amount the mutual needs to reliably pay claims), liquidity stops getting injected into the pools.

With low liquidity, it’s possible that users stop trading with the mutual and the internal price gets pinned to the Book Value target, while the wNXM market price is below that. This is likely a bear market scenario & could result in NXM price decoupling from wNXM price, which would again reduce the mutual’s ability to attract capital & cause issues with cover & capacity mispricing.

Therefore, for this scenario, we came up with a solution that allows the price ratchet target to start moving below book. Basically, instead of the price ratchets moving towards BV, they move toward each other instead. This is triggered by the Capital Pool’s proximity to MCR.

This means that a) the NXM <> wNXM price gap should not be significant, even with low liquidity in the pool, and b) the mutual starts capturing capital as soon as the market price rallies again, rather than waiting for the wNXM price to move up towards book value.

Hope this answers your question. While we’re happy with the trade & internal price solutions for this range, how the liquidity in the pools operates in this range to avoid dilution and manipulation is the one outstanding bit - we’ve got a workshop on Thursday to cover it off.

Once we’re fully happy with that aspect, I’ll write up the updated mechanisms in full (a sort of whitepaper) for the community to examine & refer to.

[ycyc]

Right now we are at 89.5% of the MCR, so we could reduce the capital pool by $28mn. What happens if a significant quantity more than that wants to swap their wNXM? I view this as the most likely scenario.

I understand that the internal BV will drop as well as the wNXM swap price, but isn’t that just going to result in the same problem as today?

Is there a lower bound price for wNXM swaps? How low can the “internal” BV go?

Shouldn’t Nexus Mutual start to prepare significant amounts of liquidity for this process to ensure there is enough and we don’t get a scenario where there isn’t enough liquidity for people wanting to exit their wNXM?

[Rei]

The MCR floor of ~162,425 ETH is being removed as part of the changes, and the current formula-driven value is around 7,000 ETH, so any locks due to the MCR shouldn’t be an issue in the short-medium term.

Exactly how much NXM wants to exit directly from the system is unknown, but the intention at least for my part is to put in a significant amount of liquidity in the pool to begin with to enable those who want to exit to do so at a price close to the Book Value & then have an ongoing injection of liquidity. Exactly what those numbers are will be the subject of an upcoming governance debate & we’re getting pretty close to starting that.

The book value itself should only improve through buys/sells as per the design of the system, which doesn’t allow dilution - all member swaps of ETH in exchange for NXM are above book value and all member swaps of NXM for ETH are below book value.

[ycyc]

Thank you Rei, that makes sense. Greatly appreciate your responses and hope you don’t mind me peppering you with questions.

How could 7,000 ETH be used to cover the $59,000,000 in cover that we have outstanding? Isn’t that undercollateralized?

Also, is there any updated timeline for potential implementation? I know initially we were thinking Q4 2023 but it looks like that may be pushed back?

[0xLux]

Thanks for the clarity Rei - I’m gunning for a timeline re: launch because things usually get done more efficiently with a deadline, we’ve also been discussing new tokenomics for many many months already and the market conditions and sentiment around eth have shifted greatly.

Given that you have the process laid out ahead of you and action items, can you give your best rough estimate?

[Hugh]

On timelines, from the Foundation perspective we’re not going to give any dates. We will continue to provide clear communication on status and what the key remaining steps are. The project is still our highest priority for the engineering team.

We know everyone wants this asap but we also need to do it right. Releasing something with a flaw is much worse than a delay.

[Rei]

Update 16/06:

This week focus was on the following.

Finalising mechanics of low-capitalisation range and transition to that range

We spent time with engineering on finalising an outstanding mechanism question - how liquidity operates in the ‘close-to-MCR range’

Generally, if we allow the buy and sell prices to operate in the same range, we need to have the above pool and below pool liquidities be equal. Otherwise, there is the opportunity for extractive arbitrage and/or significant dilution of book value.

Notes about decisions made this week added for reference, not very tidy & will expand more in the upcoming “whitepaper”:

(a - above pool, b- below pool)

Price transition & Moving target Range:

• Behaviour of swaps based on position at time directly before transaction
• Internal price in the Price Transition Range can be calculated using the same ratios (PR and 1 - PR) as the ratchet target value as
  PR * (price_a + price_b - BV) + (1 - PR) * (price_a + price_b) / 2
  where price_a = min(TWAP_a, spot_price_a) and price_b = max(TWAP_b, spot_price_b)
• If Capital Pool = MCR + X is the value where the Moving Target zone starts (& liquidity injection stops), and MCR + X + Y is where the Price Transition Range starts,
  R = Min(1, Max(0, (Capital Pool - MCR - X) / Y ) )
• From a solidity implementation point of view, need to write both spot_price_a and spot_price_b upon every buy or sell, allowing for ratchet in the meantime in order to capture the most appropriate Moving Target value.

Moving Target Liquidity:

• In Moving Target Range & Price Transition Range:

• buys (liq_a up) and sells (liq_b down) both followed up with setting liq_a = liq_b

• Liquidity has its own transition range (Liquidity Transition Range), where we calculate a linear liquidity ratio (LR) in the same was as we calculate PR for price transition.

• Liquidity mechanisms are then calculated with an LR weighting to the way liquidity is calculated in the high capitalization zone (incl. injection) and a 1 - LR weighting to the liq_a = liq_b setting.

Drafting the whitepaper to capture the updated mechanics from both last week and this week
This is basically the business-spec version of the mechanism. Aiming to share this with community next week.

Modelling
In parallel, updating the python simulation model to capture the low-capitalisation zone & transition mechanisms for price and liquidity. Outputs should be ready to be produced next week & we can quantitatively test the solutions we’ve come up with (even though we’re quite happy from a qualitative point of view).

Engineering Weekly Update - June 16th

• worked on the technical spec - to be released publicly next week
• worked with the research team on shaping mechanics in the low capitalization zone + transition zone
• worked on project planning, to identify the list of items to be checked off before we can launch + breaking dependencies as a consequence of the smart contract changes

Next steps
Next week we’re planning to release the whitepaper and technical specification in an RFC for public scrutiny and comment.

In parallel, engineering team will work on the skeleton solidity implementation.

Once members are happy with whitepaper and tech spec, next step is for the team and community to set parameters, supported by modelling efforts.

[Rei]

Undercollateralization is indeed the way to go - we’re not expecting to pay out 100% of our covers so should not be holding 100% of the cover amount in capital. It’s crucial to be undercollateralized and capital-efficient in the long run to be able to compete with incumbent risk-takers.

Even the Cover Amount / 4.8 value is high compared to what a TradFi insurer would hold, but due to the risks we currently have on our books it pays to be somewhat conservative.

See Hugh’s comment above on timeline.

[0xLux]

Thanks for the note Hugh. Do you guys at least have an internal estimated timeline? My fear here is this becomes a Parkinson’s Law situation. Parkinson’s Law is the adage that work will expand to fill the time allotted for its completion.

And no one is advocating to do it fast rather than right. Timelines can also be extended. But unless there are internal timelines and workflows that aren’t communicated, I find it strange that a P0, $15+m community-facing project doesn’t have that amount of clarity around it.

[0xLux]

Epic progress here! Thanks for the update.

[Rei]

23/06

Short update this week:

• Both teams spent time working on and cross-checking the whitepaper and technical spec, which have both been published today here.
• Continued debate on the liquidity transition mechanism (outstanding in both docs above). Explored about 3-4 distinct options, with one clear leader (captured in the ‘draft’ section of the whitepaper), but a few small kinks to still be ironed out, specifically around “completing” the transition.
• Hoping for a solution early next week so we both teams can split off and move to next steps - building the system & integrations with other parts, parameterisation and lots of tests.

[Rei]

30/06

• Spent time working on the python model, changing variables to be consistent and integrating some of the new features in the Low Capitalization zones.
• Liquidity transition - ran into a few walls & spiraling complexity as we explored solutions, now thinking more widely about whether we can get rid of this requirement entirely. Good progress in a brainstorming session today & draft document written where considered:
  • having a hard line instead of a transition zone to join the liquidities, or
  • simply setting the above and below pool liquidities to be equal from the start
• Started scoping out the community parameter setting stage, working with Community team. Initial step will be education on the proposed mechanism to ensure those who want to participate in the discussion can do so confidently without asking too many questions about how the system works in the first place. Currently putting together explainer materials.

Engineering progress

• Solidity Implementation WIP
  

  

• Working to reduce formulas from business requirements to suit implementation
  

  

[Hugh]

7-July Update

Posting this as Rei is away for a few days.

• R&D Simulation Work: testing approach of using liq_a = liq_b from the start, also adapting model to produce graphs for education phase of upcoming parameter discussion
• Community team continues working on education materials over the coming days to ensure maximum participation in the upcoming discussions
• Leaning towards implementing the whole solution in two stages, starting with the BV target / High Capitalization zone in Stage 1, followed by implementing the Low Capitalization functionality in Stage 2. Updated whitepaper as a result. No material impact on how solution works, but simplest path to get to launch as quickly and safely as possible. Likely also provides a solution to the Liquidity Transition issue.
• Approached two firms to quote for an independent economic audit of the approach.
• Engineering implementation progressing well.