This is mentioned as a high level topic in the product road-map discussion but I thought I’d elaborate more on what we’re thinking.
Issue: cover for each protocol has to be bought individually and coverage is limited to smart contract risks.
Solution: use an option approach to provide stacked risk cover where the protocol is represented by a token.
Details:
Say we are looking to cover the Curve yPool. The user would purchase yPool tokens by depositing stablecoins into Curve. They can then take out Stacked Risk Cover on Nexus which would have the following terms and conditions (broadly):
User chooses cover amount and time as usual, say 1000 USDC worth of cover.
A claim can be submitted at any time by sending in 1.1x cover amount, so $1100 notional value of yPool tokens. Where notional value of yPool tokens assumes each stablecoin in Curve is worth $1 and then making the adjustment to allow for accrued fees (this can easily be determined by a fixed formula and abstracted from the user).
If the user sends in the required number of yPool tokens then the claim is valid, no other claims criteria.
Conceptually, this means that if yPool tokens materially de-peg for any reason, by an amount greater than the buffer (1.1x in the example), then it makes sense for the cover holder to submit a claim. As 1000 USDC > $1100 notional of yPool.
So it covers the following broad classes of risks:
smart contract risk of Curve plus any underlying protocol
economic incentive failure of Curve or any underlying protocol
governance failure of Curve or any underlying protocol
USDT de-pegging or other stablecoins failing for whatever reason.
The main risk it doesn’t cover against is if the token is frozen and can’t be traded, as then a claim can’t be submitted.
It would be particularly useful for any stablecoin related use case and can also be applied to any protocol that is tokenised. eg Synthetix could be covered against all risks by doing a sUSD vs USDC option.
Risk Assessors
when a claim is made Risk Assessors would have their NXM burned as usual but they should receive their share of the yPool tokens. eg if 50% of the claim value is burned in Risk Assessor stakes, then 50% of the yPool tokens submitted are proportionally allocated to Risk Assessors.
The remaining yPool tokens go into the mutual to be sold for ETH/DAI at a later point.
Net claim payment is: Cover Amount - value of yPool tokens. Which is quite neat because the mutual effectively pays only the value that is actually lost.
Enhancements required:
Add additional “currency” assets to purchase cover in (eg USDC)
Create a deposit contract that handles the yPool tokens and distributes them to Risk Assessors as required. If the claim is denied the yPool tokens would be returned to the user.
Way to sell the remaining yPool tokens in the capital pool and convert to ETH/DAI etc
Product wording
Associated UI changes
Considerations:
Biggest potential issue is correlation, and accumulation of risk. If the mutual starts offering many different stacked risk covers then risk will accumulate at the lower end, eg DAI, USDT, USDC failure. This likely needs to be dealt with by setting lower capacity limits on related risks and is where more complex governance is required.
Could release the selling aspect later if we wish to release faster (a good solution is likely gnosis protocol)
Thanks @Hugh. I have to admit I need to think this through a bit more as the example didn’t immediately make sense to me. Is this 1.1x parameter specific to the stacked risk in question, or would it be selected by the user seeking cover?
What happens if while the claim is assessed, the asset regains its peg?
What price feed would claim assessors rely on to assess the validity of the claim? In fact, is there any need for claim assessors at all? Presumably the only fact that the right amout of [ypool] tokens are sent is enough to demonstrate the validity of the claim? If that’s correct understanding, what attack vectors does this introduce, if any?
Would the same pricing model apply to this (i.e. driven by net staked NXM)? Presumably a smaller factor (eg 1.01x) would cost more than a higher factor (e.g. 1.1x)?
Could we start with DAI for instance? This would also mean not requiring point 1. from ‘enhancements required’.
Is this 1.1x parameter specific to the stacked risk in question, or would it be selected by the user seeking cover?
1.1x would be a specific parameter in the cover wording, so not selected by the user. The idea is for the factor to be large enough to not pay-out on shorter term volatility, but small enough so coverage is meaningful. At 1.1x you effectively have a 10% “excess”, so de-pegging would have to occur to the 10% level, rather than something smaller eg DAI fluctuating +/- 5%.
What price feed would claim assessors rely on to assess the validity of the claim?
Don’t need a price feed, as the amount of tokens required to be sent in can be calculated directly at any time using on-chain info. In theory you could automate the payouts but to be consistent with our general architecture we just have claims assessors to a validity check, eg have enough yPool tokens been sent.
What happens if while the claim is assessed, the asset regains its peg?
Person making the claim would receive the claim payout and effectively lose 10% “excess”, as they’ve given up the yPool tokens. So claim would proceed.
Would the same pricing model apply to this?
Yes that’s the idea.
Could we start with DAI for instance?
We can start with DAI, if we do it means the stacked risk cover doesn’t also cover the DAI de-peg risk.
Cool thanks, much clearer now! I think it’s worth considering whether automated payouts for this sort of risks makes sense (particularly if it’s technically doable). There’s been some debate on whether manual governance can scale to orders of magnitude from where we are, and I think this would be an opportunity to add some scalability to the system. Thoughts?
There’s been some debate on whether manual governance can scale to orders of magnitude from where we are, and I think this would be an opportunity to add some scalability to the system. Thoughts?
There are two approaches here. First, you could automate decision making where possible which would require changing the underlying protocol quite regularly as new products get added. The alternate approach is leave the voting aspect in claims as is, but provide tools for claims assessors to automate their decisions themselves. My preference is for the second as it gives you both scalability and flexibility.
This cover will expose us to much more diverse set of risks. But the demands for this kind of product is clear and it seems like there are adequate amount of different products to ensure diversification.
I would suggest to start covering the depegging risks first. For example for usd (DAI, USDT, USDC, TUSD etc…) and btc (Renbtc, sbtc, wbtc and etc …) before offering cover for ypool token which involves more protocol and economic risks.