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
- 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
- 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