Smart Contract Cover - General Direction

Our first product has been out there for about 10 months, we’ve paid our first claims, rejected some and now have quite a lot of feedback to work from. Here is my summary of what’s working well and what needs improvement and the general direction I think we should head.

What’s Working:

  • Demand for the product - especially for lending protocols like Compound, dydx etc. But also for projects that want to cover their own code, they want lots of cover eg $1m+ and often many times greater. This is honestly a huge positive for Nexus.
  • Pricing level - most protocols hit the minimum price of 1.3%, this generally works very well for lending protocols or any other protocol that earns yield (when interest rates are 5%+).
  • Claims Assessment - voting process is providing clear results, even when submitted claims have complicated and quite technical aspects.

What Could be Improved:

  • Pricing Dynamics - pricing would benefit from more differentiation by protocol, current model is too sensitive to staking and it drops from uncoverable to minimum price too quickly.
  • No link to actual loss - great for a simple first product but harder to make it long term sustainable.
  • Width of Coverage - users want to know they’re covered for bad unexpected events where they lose money, whatever that is.
  • Capacity Dynamics - if perceived risk of a protocol changes materially (eg like bZx) then we want the capacity limits (and pricing) to be more responsive, rather than the Advisory Board shutting off quotes and asking members if they should be opened again.
  • Staking for new protocols - it’s sometimes challenging to source enough staking for new protocols. Pooled Staking will help but higher rewards are also likely required.
  • Upgradeable Contracts - the original product was designed for “pure” smart contracts, like Uniswap, with no upgradeability. Upgrade exclusion is really bad from a customer point of view and impacts sales.
  • Stacked Risk - money legos involve layers of systems interacting together. Cover needs to be bought on all for complete coverage.

General Direction on Solutions

  1. Revamp pricing model to make it more flexible and dynamic.
    This would also enable cover to be widened as we push the difficulty of wider Risk Assessment on to the stakers (taking it away from the end consumer). Which is where it best lies. Doing so can address the following issues:
  • Dynamic Pricing
  • Capacity Dynamics
  • Width of coverage - additional risks handled by Risk Assessors
  • Upgradeable contracts - additional risk handled by Risk Assessors
  1. Increase Risk Assessment Rewards
    We need an active Risk Assessment network to enable cover purchases. Pooled Staking will increase reward potential materially, but a substantial increase in base rewards is likely required. Probably from current 20% to 50% of cover price. This also syncs quite nicely with the plan for wider coverage and more expertise. This can be changed at any time via Governance.

  2. Stacked Risk
    This is trickier, though we do have some ideas on how to make it work for token based protocols. We’re going to explore more over the coming month or so.

  3. Link to Loss / Partial Claims
    I believe a link to actual loss incurred is needed for a long term sustainable product. Having the ability to gamble is nice, but experience tells me it is much better to align incentives. Also, to increase the flexibility on the types of products we can offer we need the ability to pay partial claim amounts (rather than the full amount or nothing). We started without both of these items for simplicity reasons so we could launch earlier.
    While proving loss absolutely can be challenging there are ways of doing this that can work and I strongly suggest we move in this direction.

Appreciate this is a long list of items but they are all quite related. I wanted to set the context for the direction we intend to progress but am very open to feedback.

5 Likes

Should this be “Capacity Dynamics”?

This seems like a good direction of travel Hugh, thanks for outlining.

It would be useful to understand what you feel is a top priority and also resource requirements. I suspect there is some low hanging fruit but also some changes that would require significant technical development and economic incentive reseach and simulation.

Specifically on the risk assessment network, it feels like staking from certain actors (e.g. the company developing the protocol, or a security audit firm) should be weighted more heavily vs staking from a random member. This could be part of the dynamic pricing formula. Thoughts?

1 Like

Thanks! Corrected above.

1 Like

On effort and priorities:

Pricing: We’ve done a lot of work here already. Aiming to share more soon with the goal of releasing shortly after Pooled Staking. There can then be further governance actions to decide on coverage width and upgradeability (which are low effort). High priority.

Increase Risk Assessor Rewards Can be implemented via governance at any point. Effort depends on how much analysis the community wants. High priority.

Stacked Risk High Effort. Suggest we come back with detailed structures first before building. Med Priority.

Link to Loss / Partial Claims Med-High Effort, could be released in stages. Med Priority.

1 Like

On the certain actors counting more re staking. We can’t do that at the core protocol/pricing level. It would require overlaying some sort of reputation system and I don’t think we should be going that direction.

However, known trusted experts provide solid signal and it probably makes sense to add more social elements to staking in the future eg follow stakes of another expert.

1 Like

Thanks for this, Hugh. Appreciate it.

I’d also like to advocate for connecting Reputation to member profiles.

As we grow, I think it will be valuable to know which members have a history of staking well (a kind of prediction market/wisdom of the crowds), plus it is a kind of soft power that will help us determine governance issues.

Yes I think those sort of signals are very powerful and should somehow transpire from the staking UI and also be reflected in the pricing of cover.

Great to see some sort of roadmaps, interesting to see that more and more product features are being considered. Appreciate the effort in seeking feedbacks.

Some improvements that I think might worth considering.

Clearer UI

  • For some reason the UI for risk assessment staking doesn’t show the dapps name but just contract address. The claim voting section also don’t have details about the claim but just the contract address. I actually have to figure the details of the claim through the discord group. The dashboard should be more intuitive.

  • nexustracker.io is a great start but the UI can still be improved and some metrics can be shown clearer. Such as total premiums received, total claims paid etc. The website should have a link from the main website? Understood that the loss ratio calculation is still being figured out, looking forward to see more metrics regarding the capital sufficiency and pricing adequacy.

Stimulate demand

  • Integrate the ability to buy cover through the interface of various dapps. Direct integration might require lots of effort as kyc is needed to buy cover but maybe just put an ad banner?

  • Now that the cover/capital ratio is below 100%, we might not need to attract much capital injection now but what are the critical ratio we should look out for as a hint that capital might not be enough?
    Might be worthwhile showcasing the return by investing in NXM tokens as an ETH or DAI investment? Like a traditional ROIC?

  • Worth considering accepting Dai or USDC as a payment method to buy NXM token? As more and more people prefer holding the Stablecoins. Plus we have some covers on DAI but our funds are mainly on ETH. In the worse case scenario of ETH price falling sharply we might not be able to pay the claim?

Thanks, very helpful feedback.

A few comments:

  • new pooled staking UI will be much easier to use, so we’re focused on that.
  • we’re working on distribution models right now.
  • while cover/capital ratio is below 100% I believe capital is still a critical item. There is lots of demand for larger cover amounts that we can’t meet right now. We need more capital to get access to a different customer segment.
  • DAI/USDC we can do this, I’m personally unsure on how big the benefits are and believe we have higher priorities atm. Yes, we’re mismatched on assets vs liabilities now, not too much of issue at the current size but we need to address it as we grow.
1 Like

Great post. Reminds me of this epic Reddit post by Vitalik being very open about what sucks about Ethereum. You can only improve by clearly seeing what isn’t great, and I see too many projects perma-shilling and not transparently tackling challenges head-on. So kudos for that.

Looking forward to pooled staking.

I also welcome potentially increasing rewards for stakers. I think that incentivized markets are great at figuring out solutions and prices, and I like that staking on Nexus Mutual leaves it to the market to figure out what is insurable, how much and at what price. So in a vague way, I advocate for the staking model to answer these 3 questions.

I also see that expectation management from the user side needs to be improved. For most, insurance is insurance without wanting to differentiate between smart contract code bugs and economic attacks like oracle manipulation. So naturally, not getting any payment for on oracle attack is a disappointment.
One way to fix that is by increasing the width of coverage into different categories and implementing these clearly into the user journey in the UI, for example:

Choose your cover against:

:white_check_mark: Technical Risk (code error)
:white_check_mark: External Risk (i.e. oracle attack)
:green_square: Economic Incentive Failure Risk (i.e. zero DAI bids)

Activating cover for another set of risk updates the price of the “shopping basket” in real-time.

I think this way it would be obvious that getting cover on Nexus Mutual doesn’t guarantee a payment for any type of loss incurred.

5 Likes

Here is some more detail on how we actually progress on these items.

Step 1: Pooled Staking
This is a building block for many other items, it doesn’t directly impact the above but it helps fuel everything. Keep an eye out for timing on release, we’re getting close.

Step 2: Simplified Pricing
See the related pricing thread Smart contract cover pricing algorithm

This is another fundamental building block that will not only address several items (dynamic pricing, capacity dynamics, allow greater width of coverage, allow upgradeability coverage), but it will also enable the mutual to build new products relatively easily, including cover for stacked risk. More details on the proposed mechanics will be shared soon.

Step 2a: Increase Risk Assessor Rewards
Needed to encourage an active staking network. Implementation is simple as it just requires a governance vote to change the parameter. We appear to have quite broad agreement based on the recent signalling vote so we will push this into governance soon (likely synchronised with other changes to help with voter participation)

Step 2b: Remove Upgrade Exclusion
A small but important step in widening the risk coverage. This is effectively blocking cover on Synthetix and other protocols that more regularly upgrade. It is also quite difficult to enforce from a claims perspective. Very easy to implement, just requires re-drafting the current wording document and a governance vote.

Future steps: Partial Claims, Link to Actual Loss, New Products
Exact details still to be decided including priority order, so looking for feedback here. The partial claims one is a larger build effort but also opens up many possibilities on the product side so is a key building block for the future.

2 Likes

i see it now…“or buy Comprehensive coverage…”