[RFC]: Amending Protocol Cover Wording to Better Enforce Principle of Indemnity

[BraveNewDeFi]

Overview

When Protocol Cover launched at the end of April 2021, it transitioned our main product offering from Smart Contract Cover to the more comprehensive Protocol Cover that the Mutual underwrites policies for today. While I believe Protocol Cover provides the best protection available within the DeFi market, the current cover wording can be amended to provide clarity for prospective Cover Holders and better define the mutual’s stance on certain edge cases where a loss occurs and a Cover Holder cannot receive compensation within a reasonable time frame.

Below, I will:

• Compare certain provisions in Protocol Cover Wording and Custody Cover Wording

• Cite examples where existing cover wording does not provide enough clarity for users

• Outline revisions to amend existing cover wording to better define the coverage provided

Protocol Cover: Lack of Clarity for Repayment Events in Existing Wording

After the Yearn hack on 4 February 2021, Cover Holders received claims payouts. It’s important to note that these Cover Holders purchased cover before the proof of loss requirement was added to the smart contract cover wording, so they would have received a payout in any event. However, Claims Assessors debated about a situation like the Yearn hack: where the mutual paid out claims and the affected protocol then reimbursed users.

The 72-hour cool-down provision was included to address situations where affected protocols choose to make affected users whole, and the cool-down period also gives Claims Assessors adequate time to review the details of an incident. While it would seem evident that reimbursement from the affected protocol would negate any losses, I would be in favour of adding a provision within the Exclusions section that explicitly states:

• Any outcome where the affected protocol announces a Plan for Complete Reimbursement before a claim is reviewed by Claims Assessors

We would then add this phrase to the Definitions section:

Plan for Complete Reimbursement means reimbursement of 100% of funds for users who experienced a loss of funds due to a defined within Sections 1 through 5.

Since the current Protocol Cover wording already includes language regarding partial claims when the mutual has the technical ability to do so, the existing language is future proofed as it relates to partial payments.

Shortcomings of Existing Language as it Relates to Repayment Plans

The C.R.E.A.M. Finance exploit that occurred on 30 August 2021 is a great example of a repayment plan that falls into a grey area within Protocol Cover wording due to the ill-defined provision for a repayment event.

To quote from the post-mortem report:

We will be replacing the stolen ETH and stolen AMP so that there’s no liquidity issues for users. We will commit to allocating 20% of all protocol fees toward repayment until this debt is fully paid. In the meantime, we will post a CREAM collateral with the Flexa/AMP team to secure this debt.

If you are an impacted user, please submit your details through this google form.

While the team has a plan to compensate impacted users, it is unclear how long the repayment plan will take to make all impacted users whole.

What if the repayment plan takes one (1) year and the price of ETH drops from the price at the time of the exploit ($3,228.46 / ETH) to $1,200 / ETH by the time the repayment is complete? While a user has the lost funds repaid, they cannot access repayment within a reasonable timeframe. The Mutual does not cover loss of value, but a user would be missing out on any potential yields for their would-be productive assets while they wait for repayment. In my opinion, this is the value of a cover policy: to recover funds within a reasonable timeframe after an event where funds are lost due to a technical failure.

Let’s compare Protocol Cover Wording to Custody Cover Wording as it relates to recoveries:

With Custody Cover, the mutual has a provision to seek reimbursement when a Cover Holder receives a claim payment and is then compensated by the custodian in the future. I think most members would agree that self-custodied funds will only be sent to the mutual if interests are aligned for a Protocol Cover scenario where the mutual reimburses a Cover Holder and they are reimbursed in future. Good faith should not be depended upon in a trustless system.

We can include an entry within the first section of covered events which states:

• The designated protocol announces a reimbursement plan that does not occur within a reasonable timeframe; and

• A tokenised position is available to represent a claim on any future reimbursement from the affected protocol (e.g., crTokens, aTokens, cTokens, etc.); and

• A Cover Holder swaps their tokenised position for a claim payment and said tokenised position can be used as a future claim on any reimbursement from the affected protocol

Language as stated above would enable the mutual to provide greater value to cover holders, while ensuring that claims paid to Cover Holders would not result in a duplicate payment from the affected protocol. The mutual can redeem the tokenised position(s) for a claim payment if, or as, it becomes available.

We can also add another provision under the Exclusions section that refers to the aforementioned language where untokenised positions with no way for the mutual to hold a future claim on reimbursements cannot be covered as defined in provision [X]. We could widen wording to include scenarios where repayment is tokenised and such tokens were swapped with the mutual for a claim payment as well, but covering all events regardless of a tokenised position will result in too much friction, imo.

@BowTiedIguana recommended an approach where claims on repayments would be tokenised to include tokenised and untokenised positions alike, but this would require cooperation from all listed protocols, which I do not think is realistically feasible. Not every listed protocol will cooperate with such an issue, and as the mutual becomes more decentralised, I do not think we should depend on the cooperation of other protocols to fulfil payment. If protocols see the value in the Mutual providing compensation in the short-term while the team provides repayment in the longer-term directly to the mutual, that solution will emerge as the behest of a listed protocol.

Open Discussion

After the C.R.E.A.M. Finance exploit, I realised the existing Protocol Cover Wording could be amended to better protect our members, while protecting the mutual from issuing double compensation to affected users. The language presented above is preliminary, and I’m hoping my fellow Mutants can help me identify the unintended consequences that I may have missed when thinking through this issue.

In the past, cover wording has been amended to improve the existing language or add provisions that better serve the mutual and its members. Adding a couple provisions that allow Claims Assessors to use their discretion to determine reasonable and unreasonable repayment timelines and including provisions that ensure the mutual holds future claims on any repayments issue when a claim has been paid out to a Cover Holder for a loss event.

Comments on Other Proposed Changes to Protocol Cover Wording

@BowTiedIguana has made a couple of great posts, and I thank them for the time and thought they put into their discussion around cover wording. I see merit in having a larger discussion about some points within the existing cover language as BowTiedIguana points out.

There was one comment I don’t think is necessary for future revision:

This essentially says if your software or hardware wallet is compromised and your funds are removed from your custody and, thus, you incur a loss, that isn’t covered. If a flash loan allows an attacker to drain funds from an AMM, that would be covered. This provision excludes instances where a user has their wallet compromised.

Community Sentiment

I welcome any feedback, comments, or criticism. As I used to say to my copy editors once upon a time: take a look, tear it up, make it better.

[BowTiedIguana]

I thought the final limb of the clause was problematic “or any other activity where the designated protocol continues to act as intended”.

Perhaps the whole clause could be reworded to

Any loss of funds from user-controlled custody including losses caused by private key security breaches, computer malware, social engineering attack, or any other event where loss arose from actions directed at an Externally Owned Account rather than at the designated protocol

[Hugh]

@BowTiedIguana Thanks for the input here

Can you elaborate a bit more on why you think that exclusion is too broad, perhaps with another example? I don’t quite understand the situation you’re concerned about.

In your AMM example, with the oracle manipulation, the claim should be paid because of the oracle manipulation so I don’t think the exclusion is relevant in that example. The goal behind this exclusion is to make sure the cover is limited to what is included in the main triggers section rather than leaving it more open.

@BraveNewDeFi I really like the goal and intent behind these proposed changes.

1. I support the clarity by adding the Plan for Complete Reimbursement aspect. My only slight concern is what if the plan is made after 5 days etc, is it fair that some people get a claim and others who claim later may not. Not quite sure how to deal with that though. It’s how the cover operates now, so I’m happy to live with it but if you have any bright ideas I’d love to hear them.

2. Recoveries. I love the principle and intention. The main challenge here is the process behind it, driven from the fact that every reimbursement situation is going to be different, and putting expected development obligations onto the mutual may be challenging. My primary concern is requiring members reimburse obligates development work to set up escrow contracts and process claim payments that reimburse the tokens etc. This is very hard to set up in advance because there are so many different ways it could be implemented by the impacted protocol.

So I’m a bit hesitant to include a payout trigger if the reimbursement plan isn’t “timely” on the basis that a recovery is made. Again, open to ideas if there are some solutions here.

[BowTiedIguana]

Should have lurked longer and understood better before trying to contribute. Was trying to apply what I learned during a formal legal education, brief professional experience, and a career in business to a discretionary mutual where the adjudicators are intelligent, informed, and motivated to deploy common sense to achieve a fair outcome.

Much respect for what you’ve built and I hope you see it grow to replace the ‘old’ way of working.

[Hugh]

your input is much appreciated ser!

[nexudm]

By far the most common question I get asked when suggesting Nexus cover as an option is
‘Will they actually pay out though?’

It is worth keeping in mind that as you add more exemptions or the more complicated exempt scenarios become the more people will dismiss the value of buying cover out of hand.

While extra clarity on what proof of loss means in regards to a situation involving compensation would definitely be helpful, I believe that the expectation of payouts should remain strictly an agreement between the mutual and it’s members. If protocols/custodians can influence whether or not a payout happens by releasing ambiguous statements of future compensation, it may undermine confidence.

The Rari Capital exploit springs to mind, users compensation would be provided after 4 years and denominated in USD rather than ETH which basically no one would be happy with.

While obviously double payouts are not an ideal situation, I don’t believe jumping through hoops to ensure no one gets a double payout is an effective use of developer resources, from the perspective of the mutual it should not really matter if the individual receives a reimbursement or not if the event is one that warrants payout based on the cover purchased.
Not paying out due to a protocol suggesting it will reimburse users only to have it later renege on that promise would be vastly more costly in reputational damage to the mutual.

[BraveNewDeFi]

I often get the question, “But how will I know the mutual will pay out?”

And I always direct users to the Claims History section of the docs where all past events are catalogued with payments noted. To date, the mutual has paid out ~$2.4mm in claims, and that number isn’t adjusted for the value of those assets now.

For proof of loss questions, I direct users to the Proof of Loss section.

Any DeFi coverage provider needs to have safeguards in place so that users don’t abuse the system. Proof of loss just verified a user has control over their affected wallet/address so it can be checked against those addresses affected by an exploit or loss event.

With the issue of indemnity, which in this case refers to paying out when a user has or will be compensated by the protocol directly, the mutual needs to have safeguards in place to ensure users don’t abuse the system. It’s necessary for the mutual to scale.

I would argue the cover language for the various cover products is not that complex, nor is it very long.

I’d be more worried about buying coverage from a protocol offer “insurance” that really isn’t insurance or a provider with no past payouts. While everyone needs to get started and scale, I’d rather go with a protocol that has a history of successful claim payouts. That’s why I’m a member of the mutual.

[nexudm]

The cover language is currently not complex, however what I was trying to get across is simply that there is a direct link between the perceived value of cover and how many situations result in a claim being denied.

For example, I know that for custodial cover, should I be unable to withdraw for 90 days I am covered regardless of the circumstance. That is unambiguous and therefore highly valuable.

If a protocol should have an event that is applicable under protocol cover, I would expect to receive a payout promptly after the 72 hour cooldown period and assessment, however with a change to wording I would also have to be concerned about a protocol suggesting they will reimburse users in the future (regardless of whether they do or not) which could render my purchased cover useless.

This dramatically lowers the value of cover and I believe small changes like this materially reduce cover buys.

I also don’t believe you should characterise users receiving a successful claim and subsequently being reimbursed by a protocol as abuse of the system.
I would contest that whether or not users are reimbursed has no effect on the scaling of the mutual, it is my understanding that a tighter restriction on payouts would not allow us to provide additional cover, either we have capacity to pay for the claim or we do not.

[BowTiedIguana]

@nexudm makes some excellent points about the perceived value of the cover.

I don’t think we can rely on the good faith of all users when funds are self-custodied to voluntarily return future reimbursements.

I take @BraveNewDeFi’s point that it will be difficult to negotiate co-operation with all covered protocols.

@Hugh also mentioned that it may be difficult to focus the development resources of an exploited protocol on dealing with tokenized claims.

What I do not believe has been discussed is that Nexus Mutual could itself create a tokenized representation of the loss and airdrop this to affected wallets who are also NXM members, regardless of whether they have filed a claim. If the protocol wording requires the users to surrender these tokens to the Mutual in order to have their claim paid, we have an opportunity to discuss this arrangement with the exploited protocol if they later offer a reimbursement.

While we cannot rely on individual anonymous users to be ethical on average, I expect DAOs to have a higher standard of accountability. Through a governance proposal we could ask that their reimbursements “follow” the address which currently holds the NXM-generated tokenized claims. There would be full transparency of the issue of these tokens, their surrender by the insured, linked with our protocol cover wording.

My assumption is that exploited protocols would be in a better position to deal with the technical overhead of this when they had secured sufficient capital to make reimbursements. And we don’t need to prospectively negotiate with all protocols which is prohibitive, but only persuade the ones which have been exploited and for which the Mutual has paid out substantial sums to covered members.

Step by step

1. The Mutual learns of an exploit affecting a covered protocol.

2. When full details of the loss are known (affected wallets and amounts), NXM creates a new token representing claims related to the incident.

3. These new tokens are airdropped on all affected wallets who are registered as members of the mutual (and who had cover in force).

4. The cover wording requires members to surrender these tokens to the Mutual before their claim is paid.

5. Nexus contact the exploited protocol to ask them to respect our members voluntary assignment of their reimbursement rights to the mutual in a document which strongly highlights the importance of insurance in DeFi and the fact that the mutual has just paid out substantial funds to the protocols’ affected members.

6. When the protocol is in a position to make a partial or full reimbursement, ideally it respects these arrangements and adds the following logic to its deployment:
   a. did the beneficiary address ever receive [address of Nexus-created token specific to the incident]
   b. did the beneficiary address transfer any of these tokens?
   c. if so, replace the beneficiary reimbursement entitlement to follow those tokens (pro rata)

7. Optionally, NXM could arrange to return 10% of these recovered payments to the affected protocol as a “white hat bounty” to offset their development costs in implementing the above logic.