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
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.
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.
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 ) 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.
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!
) will join forums for discussion.