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:
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.
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.
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.