Over the next few weeks/month I’ll start outlining my thoughts on future developments/roadmap on three main topics:
Product roadmap
Capital scaling
Decentralisation
The first one is product. We’ve shared some direction on this previously but now we’re specifically after input on what you as members of our community think we should focus on.
Our broader vision is to enable the mutual to take on any type of risk; smart contract risk, oracle risk, other crypto risks but also risk outside crypto like earthquake and hurricane. So some of the following items are fundamental building blocks that will enable many more products in the future and others are more specific product items that might help cover growth in the near term. In visual form:
Now that we have Pooled Staking and Simplified Pricing in place we have created a shortlist of items that we believe are good next steps for the protocol. I’ll briefly expand on each item below:
Link Claims to Actual Loss – I strongly believe this is required for a sustainable product in the medium to longer term. Experience tells me it’s quite challenging when interests between the cover holder and the mutual are potentially misaligned.
This would involve something like providing a signed message from an address directly impacted by the hack before a claim could be accepted. While this isn’t absolute proof it would limit claims to the actual loss incurred. More details to be worked through. This could apply to Smart Contract Cover (on a forward looking basis most likely) but would also be a more general building block for future products.
NFT Based Cover – this would turn cover into an NFT, which would mean cover could be sent to other addresses. It would allow easy renewal or adjustment processes, so cover periods could be extended, cover amounts could be increased etc.
Partial Claim Payouts – this is key functionality that is required to open up many future product options. Instead of a simple Yes/No claims outcome, the voting would be “how much?” with some sort of averaging process. This allows products to be built that reimburse actual loss much more closely.
Stacked Risk Cover – A specific product that allows protocols that are represented by a token to be covered not only for themselves but all underlying protocols AND all types of risk in one go. The idea is to allow the cover holder the ability to swap their protocol token for a fixed amount of another token (eg aDAI for USDC) at a fixed rate. If the cover holder sends in 100 aDAI then they can get eg 90 USDC in return. So if aDAI drops in value past the 0.9 USDC threshold for whatever reason then downside risk is protected.
Severe Oracle Failure – A specific product that pays the full cover amount if there is severe oracle failure. Needs to be ‘severe’ as a full claim payout is triggered but we believe this could be delivered with terms and conditions development only, rather than core protocol changes. Would likely start with Chainlink oracles to begin with.
I’m strongly supportive of all of these items based on positive feedback we’ve received so far. Priorities are a bit trickier though, so please provide specific feedback here as well if you can.
Great to be a part of the discussion! Will there be an official polling available as part of the governance process? Something like the YFI governance polling, I find that quite useful to gauge the interest of the mutual members and potentially where the demands may lie. Can consider offering the polling here in the forum as well if we think the gas costs are not worth it.
Personally after constantly lurking around twitter and discords plus my own yield farming experience, I believe currently there are more interests on the Stacked Risk Cover, and subsequently to cover the Severe Oracle Failure. Severe Oracle Failure cover might be more feasible and sustainable after the feature of Partial Claim Payouts is enabled though.
Its cool to see that Partial Claim Payouts might enlarge the universe of products that the mutual can offers. Exciting. So I think it should be high up in the development order.
At current stage, the priority should be set at attracting more capital and covers, rather than limiting the potential loss. So Link Claims to Actual Loss should be considered at a later stage.
While for NFT based cover, this is such an interesting idea! But I think it poses more questions rather than answers at this stage. Does this mean the cover is not linked to a single address? That it functions like buying an option where anyone can claim it? How would the KYC process further complicate the transfer? I failed to imagine how this can make the process of renewal and cover adjustment easier, more details on the expected implemented would be appreciated.
So based on my opinion, the priority would be
Stacked Risk Cover
Partial Claim Payouts
Severe Oracle Failure
Link Claims to Actual Loss
NFT Based Cover
The way I see it is that we can aim to satisfy the short term demand of stacked risk cover first, then only work on long term demand enabler - partial claim cover. Moving on to offer oracle products, then limiting our loss ratio at the end. Then only after that seek to have innovative distribution process such as holding the cover in the form of NFT.
It would be great to have some insights on the difficulty of implementing these proposals as well, such as roughly how many months are required. Understand the complications of promising certain deadline, a range such as 1-3months, or 9-12 months should be sufficient.
After having read @Hugh’s ideas a couple times, it seems to me that Severe Oracle Failure has the potential to move the needle for Nexus communication-wise (new product, significant risk currently, Chainlink community marketing ) more than the other points raised - and potentially drive more capital (and attention) to the Mutual.
My general thesis is that we are in land-grab mode in DeFi, both as far as attention and capital are concerned. Over the longer term sky could be the limit, but with scaling capital (without compromising on the core) in the short term increments that make up the long term, compounding advantages might arise - by proving security, cap efficiency and building loyalty at the margin, continuously.
As such, I would prioritise Severe Oracle Failure and roll out the rest while the afterburn effect of said launch is taking place - possibly creating some nice momentum for the rest of them.
Relevant to the above, the following extract is from the new Aave token econ paper. Oracle failures will slash Aave stakers if they lead the protocol to be in deficit. To be rolled out over the coming months. Screenshot 2020-07-29 at 20.41.14|690x370
This is a bit off topic from the roadmap items identified, but I think one risk that is holding back crypto assets is self custody of private keys. If Nexus Mutual could provide cover from the loss/theft/hack of private keys, I believe there would be a huge demand for the product. I’d love to see Nexus Mutual offer this product.
Thanks for outlining this @Hugh. Would it be possible for you to give an indication of technical difficulty or development effort related to each of these avenues? Maybe out of 10 just to make it super simple.
Thanks for summarising the envisioned product features for the next months. I agree with NFT based cover, which allows for more flexibility, but the other features seem pretty redundant to me.
Let me explain:
If we were to have tokenized cover, i.e. wrapped insured tokens, this would solve for:
Link claims to actual loss - You either own an insurance wrapped token or not
Partial Claim Payout - It is easy to calculate exactly how much each address lost
Stacked Risk Cover - That’s basically inherently supported by allowing for wrapped tokens.
Severe Oracle Failure - Similar to option-based insurance. Wrapping the tokens that would be exploited during a severe oracle failure will cover this.
I understand that there is a KYC issue for tokenized cover, but since we actually want to move away from that in the medium to long term anyway…
Also, let’s look at this from an engineering standpoint:
Building 4 standalone custom features vs building 1 feature, which would also allow for more flexible use cases that we can’t even envision yet.
This is certainly interesting and would love to hear from team Nexus whether that’s indeed a silver bullet. Just one thing to clarify, along the lines of the questions raised by @luciusfang, is the idea that the address (and its exposure) that holds the NFT is the one that is covered? I can see why someone would want to hold the NFT separately.
I think more details on that implementation are needed in order to prioritize.
I think this can dramatically accelerate growth for Nexus Mutual. Believe Nexus’ addressable market is far beyond crypto but the most efficient way to bootstrap initial users + ambassadors is via the crypto native DeFi crowd (of which we are all a part I assume).
I like the idea of a third party UI wherein a user who does not like KYC buys wNXM off exchange, deposit into a third party contract (not controlled by Nexus team) that swaps it for NXM and buys the specified coverage, then sends NFT to address.
Any update from the discussion with @HeyChristopher? If so, what was the decision.
About private key insurance asked by @Jeffshaw, it is really hard due to the fact that there is no reliable way to prove that a key is lost or stolen.
Hey Ken - there is a specific set-up where this can work. You’re right that you can’t cover the keys directly.
Smart contract wallet which has a recovery agent who operates under a time delay. You can block the recovery agent from doing anything within the time delay but if you lose keys they can restore for you.
With this set-up you can then provide Cover for: Smart Contract Cover (against the wallet) + Cover the recovery agent against failure.
This gives a comprehensive solution.
It requires a few parties, and established players like Argent so will take some time, but we’re working towards it.
) more than the other points raised - and potentially drive more capital (and attention) to the Mutual.