Following on from the snapshot vote concluding yesterday, wanted to briefly mention how I see the immediate next steps.
As per the snapshot vote ,and as mentioned by @BraveNewDefi above, to get to launch, we need to complete two parallel strands:
- Technical development. The Engineering team would develop the smart contracts necessary to implement the chosen proposal. This would include writing the smart contracts, 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.
The next milestone will be to create a specification document that can be handed to the engineering team - hoping to do this within a month.
Some aspects of fine-tuning the chosen design will influence the design spec, e.g.
- any transition mechanisms that require their own code,
- any edge cases that may force a design change, and/or
- any technical limitations discovered by engineering team themselves
Other aspects will not, e.g. setting the numeric parameters of the system, like opening price, liquidity and ratchet speed.
Therefore, my initial focus will be on nailing down those aspects that will influence the design, so that what’s handed over to the engineers is as robust as possible.
Some examples of the sorts of things I mean:
- Currency of redemptions. Currently everything is modelled/calculated in ETH, but the capital pool is denominated in more currencies, with stETH being chief among them and may be diversified into further investment assets in the future. Should we be enabling/setting withdrawal to be in multiple currencies according to the current split of the capital pool or should we set aside a pool of ETH cash specifically for withdrawals?
- NXM price transition. Detaching the price from the current bonding curve level to a market-consistent level would create a capacity shock. Should we trend it down over time, if so, what’s the best approach?
- Oracle safety: There is the possibility that Book Value as per the system is slightly out due to oracle errors / delays. Is this a concern in the range around book value and, if so, should we introduce some sort of buffer around Book Value?
- TWAP for system price: how defined, what time frame, etc.
Meeting some of the foundation team next week to brainstorm the next level of detail on the points above and more, and intending to collate a list of suggestions and discussion points for the wider community + post them in a separate forum post, so that we can get a wide range of interested brainpower working on this.
In the meantime (ideally by end of Tuesday 24th Feb), I’d encourage everyone here to highlight anything that jumps out to you in the current design that gives you concern.