Add Proof of Loss Requirement to Cover Wording

TL:DR - we should add a requirement that for valid claims proof-of-loss be required.

At present Smart Contract Cover conceptually acts like a credit default swap where cover can be bought without any actual exposure to the underlying protocol. This was done for simplicity reasons as there were lots of items to build initially and we were trying to cut down the initial scope.

Given the recent success it’s now time to revisit this aspect and add in more sustainable product features.

I strongly suggest the following broad terms are added to the Smart Contract Cover wording document:

A valid claim should only be paid if in addition to all the other requirements;

  • a cryptographically signed message from an account who directly lost funds is provided, or
  • where the cover holder is directly related to the team or individual who built and/or deployed the contracts, a cryptographically signed message from the address that deployed the contracts or otherwise sufficient evidence that the cover has been purchased by the team or individual behind the contracts.

(wording to be refined)

This means that the cover holder must effectively prove personal loss greater than 20% of the cover amount before a claim is paid.

The main purpose here is to align interests between cover holders and the mutual more closely, as well as protect the mutual from paying out very large sums when the total loss incurred by the hack could be much lower. From personal experience of shutting down many products, business lines and involvement in insurance company mergers due to large losses, I’m quite certain this type of feature is required for long term sustainability.

Other points:

  • This clause should only be applicable to cover purchased after the date it is implemented. Existing cover will continue to operate on the current terms until it expires.
  • This method isn’t full-proof but it is quite strong, relatively easy to implement and does create significant friction to abuse. It also prevents payouts exceeding total loss incurred.
  • All information would be provided off-chain and assessed by claims assessors.
6 Likes

Would it be easy to combine this proposal with partial claims? That way someone can’t only lose $10k in a hack but buy a cover for $1M and still profit.

1 Like

We need them both in my opinion, by itself this isn’t perfect but it is relatively easy to implement. Partial claims requires more development work.

I’d release this first and add in partial claims later.

2 Likes

Are there any circumstances where this is not technically possible to complete due to the hack itself?

Do you expect any privacy concerns about disclosing the address that suffered the loss to the claim assessors? If so, any possible remedies (e.g. ZKPs to prove the loss without disclosing the address).

I don’t believe so. The only reason a message can’t be signed is because of private key loss.

re Privacy - this is a potential downside as it effectively links two accounts. I’m no expert on ZKP but hopefully we can introduce something like this in the future.

Fair enough. I suppose an insured could hold funds across multiple wallets, including under custody. How would that work in that case?

The custody point is a good one to raise. We should adjust the wording to handle that. If you or anyone else has any particular specific wording suggestion here please raise it. I haven’t dealt much with custodians so don’t know exactly what would work best.

I don’t think one be able to provide cryptographic proof from custody, only maybe something offchain which would not be ideal. Any other thoughts from the rest of the community?

Another question: how would you handle a situation where the insured recouped some of the loss from the company/project that got hacked, via treasury or own insurance fund for example?

Afaik you also can’t sign messages from contracts, i.e. Argent wallets or multi-sigs.

1 Like

Good point. I think we need a bit more color on the technicalities of this.

1 Like

Thanks! Glad we are having this discussion. We obviously need to refine wording here to make sure it captures these issues.

I’ll do some more investigation and revert back.

1 Like

In a CDS (credit default swap) when a credit event is trigger The cds pays the amount determine by the 100 - the residual value of the bonds. The residual price of the bonds is calculated usually by an auction In where bond holders tender their bonds and buyers Make offers. The idea here is that the cds only covers the value lost for a bond holder.

Here is the same right? We will have a method to determine the residual value of a token that has a approved claim. Or they could provide those tokens in exchange for the claim amount and exchange the tokens like in a CDS.

Here is some proposed wording to be added to the Smart Contract Cover definition document.

This information can be collected off-chain relatively easily as it’s either a link to a transaction or a signed message. After investigation I believe it solves the custody, multi-sig and smart contract based wallet issues.

I’m strongly in favour of making these amendments quite soon, before cover growth gets to another level. Importantly, these changes would only be forward looking as we shouldn’t be making retrospective definition changes that are more restrictive.


add the following clause to the Cover section:

The Mutual may pay a claim under this Smart Contract Cover if:

the cover period began after dd-mmm-yyyy, then cryptographic evidence is provided that links an account that suffered a loss, the impacted account, to the Covered Members account that is submitting the claim, where cryptographic evidence could include but isn’t limited to the following:

  • where the Covered Members account is impacted directly, the submission of a claim will be taken as that evidence; or
  • where an account that is not a Covered Member is impacted, either a cryptographically signed message from the impacted account that includes the Covered Members account address, or the transaction hash of a zero value transaction from the impacted account to the Covered Members account.

add the following definition:

Impacted Account means

  • an account which directly suffered a loss as a result of the hack; or
  • where the cover holder is directly related to the team or individual who built or deployed the smart contract system, an account that either deployed the smart contract system or is otherwise publicly known as having built the system.

For reference the current product wording is here: https://nexusmutual.io/pages/SmartContractCoverWordingv1.2.pdf

That makes sense @Hugh, thanks. Just to clarify, how does this solve the custody issue highlighted above?

Is there any wording that would needed to added in relation to NFTs?
Since cover NFTs are being flipped on the market right now, what happens if the person holding that NFT needs to make a claim? Is that completely handled by the yInsure process or do we as underwriters need to include that in the Cover Wording too?

The ETH address which is held in custody can send a zero value transaction (or a non-zero value transaction) as part of the usual custody arrangements. No special smart contract interaction or anything.

We don’t need to add any wording related to the NFT’s, as wording should be exactly the same, but there does need to be a way for the NFT holder to submit the proof of loss. Right now this can’t be done from yearn directly but we can build some UI for Andre to add in that allows it.