Over the last month, members have reviewed and discussed two proposals that recommend changes to Nexus Mutual's bonding curve and tokenomics.
This vote is a non-binding signaling vote, which will be used to gauge members' support for either proposal or if there is demand to seek alternative proposals to the two existing tokenomics proposals.
For the last two years, members have not been able to redeem NXM for ETH since the minimum capital requirement ratio has been below 100%. This has prevented the mutual from attracting more underwriting capital since members can buy wNXM below the bonding curve price for NXM.
The two proposals put forth potential solutions that would allow for members to redeem NXM for ETH, close the price difference between the market price of wNXM and the book value of NXM, and allow the mutual to attract underwriting capital to drive growth.
To date, members have posted two different tokenomics proposals that each provide a different solution to the current redemption lock.
Ratcheting AMM design. Posted by Rei of the tokenomics working group. The proposal's TL;DR written by Rei:
When NXM is minted from the protocol by contributing ETH, the system price goes up; when NXM is redeemed, the price goes down. This is achieved via an internal automated-market-maker pool similar to Uniswap v2, with the mutual itself as the only liquidity provider. The mutual will continue to provide liquidity to the pool subject to assets exceeding the MCR. The MCR floor is removed and MCR is driven by Cover Amount. Minting NXM from the protocol is disabled below asset-value-per-NXM ("book value") and redemptions are disabled above book value. A ‘ratchet’ mechanism moves the protocol NXM price towards book value over time instead.
Modifying the existing bonding curve design. Posted by community member ReeseWickham. The proposal's TL;DR written by Reese:
This proposal supports the idea that the optimal solution for Nexus Mutual’s tokenomics is the existing model, based on a bonding curve, as described in the white paper. The reason why redemptions have been disabled and other undesirable effects happened, can be traced back to a single parameter defining the minimum capital requirements. Removing this parameter would not impact mutual’s solvency or operations, it would solve redemption issues and it would make the mutual much more capital efficient and profitable. This proposal also explains how this change is technically feasible and easy to implement.
The next stage is dependent on the outcome of this signaling vote. If Option A or Option B receive the majority vote, then the next stages will involve:
Technical development. The Engineering team would develop the smart contracts necessary to implement the chosen proposal. This would include development, testing, and audits of the design.
Determine parameters of the chosen design. Members will discuss and select the initial parameters for the chosen design and approve the implementation through an on-chain vote for the final protocol improvement proposal.
You can choose from one of the following options when you cast your vote: