Smart Contract Cover was first released in June 2019 and we now have a lot more experience with actual hacks and what users want cover for.
In general, I believe we need to widen the cover wording to:
- Explicitly cover events that users feel should be covered, like oracle/flash loan attacks and others.
- Cover non-ethereum protocols and Layer 2 protocols (eg Thorchain, Polkadot, Optimistic rollups, zk-rollups etc)
Draft wording was circulated recently and we asked members to assess historic hacks against the new wording, to back test it. In summary the new wording performed quite well with clear results on most cases but there are a few cases worth highlighting. Note that the cases chosen were deliberately the more contentious ones to really test the wording.
MakerDAO Black Thursday
The difference of opinion comes down to whether this was an economic incentive failure or network congestion.
Compound DAI Oracle
After speaking to several of the people who responded the difference of opinion comes down to wether you believe the Coinbase oracle was deliberately manipulated to cause liquidations or was a wider event that was isolated to Coinbase for other reasons. That is, was this just normal operation of the protocol or not.
Lendf.me - ERC-777
Difference of opinion on 1) known bug or not, 2) issue with the DEX or outside code. The ERC-777 issue in general was quite widely disclosed but the interaction with the Compound v1 fork wasn’t specifically disclosed and wasn’t known by the Lendf.me team.
Adjustments to cover wording
I believe it’s very hard to adjust wording to handle MakerDAO or Compound events more clearly. I don’t believe we should be covering miner or network congestion issues for Maker, so we can’t explicitly widen the coverage wording for all miner issues, this will inevitable leave some grey areas. Similarly with Compound, the distinction on the intention behind the oracle manipulation is also very hard to define. So I believe we have to live with uncertainty here and rely on claims assessors interpretation for future events.
With Lendf.me I have clarified the exclusion on known issues to also exclude known issues in the parent of a fork. This likely doesn’t resolve the difference of opinion but I believe it’s a more general point that should be clarified, especially with the increase in number of forks.
I’m interested on any specific feedback here and if more adjustments are required. In particular is there anything that should be clarified to specifically include the Lendf.me event? It feels like it should be paid.
Wording Draft - Please Comment
Summary: Users of the protocol suffer material financial losses due to severe failures in either the protocol code, economic design, governance set-up or oracles.
Subject to the Exclusions section (6 - 11), the Mutual may pay a claim under this Protocol Cover if:
1.During the cover period, the designated protocol loses user funds as a direct result of one or more of the following components of the designated protocol failing:
1.1 Code being used in an unintended way; or
1.2 Economic design failure resulting in the unintended confiscation or seizure of funds deposited into the designated protocol for either collateral, liquidity provision or staking purposes only, or
1.3 Severe oracle failure where the oracle price is either;
a. deliberately manipulated so that it is materially outside observed market rates; or
b. materially different from the intended data source;
resulting in either the unintended liquidation of collateral or unintended extraction of funds from the designated protocol; or
1.4 a governance attack where;
a. a small group gains control of the designated protocol, and
b. the designated protocol is altered to confiscate or seize funds from regular users;
The designated protocol loses user funds with funds either;
2.1 Moved to another address with the original owner or owners do not control; or
2.2 Made permanently irrecoverable;
The Covered Member provides cryptographic evidence that links ownership of the impacted account to the Covered Members account that is submitting the claim; and
The impacted account has suffered a material loss; and
The Covered Member submits a claim during the cover period or within 35 days of the cover period ending.
Protocol Cover will not pay a claim for any of the following:
Any events or losses due to phishing, private key security breaches, malware, exchange hacks or any other activity where the designated protocol continues to act as intended;
Any events or losses where the protocol was deployed primarily for the purpose of claiming on this Protocol Cover and not for real usage by customers;
Any events or losses occurring during the cover period if;
8.1. the event occurred; or
8.2. either a public bug disclosure or warnings related to the event were made for the designated protocol, or where the designated protocol is a fork its parent protocol;
before the cover period began;
Any events or losses where the designated protocol continues to operate as intended including events or losses as a result of miner behaviour.
Any events or losses resulting from movements in the market price of assets used in or relied upon by the protocol.
Any events or losses resulting from owners or controllers of the designated protocol confiscating or stealing funds from users in line with the permissions of the designated protocol (“rug pull” exclusion).
Cover Amount means the amount of Cover specified by the Covered Member at purchase of Protocol Cover.
Cover Period means the period of time that a Covered Member is protected under this Cover, chosen by the Covered Member when purchasing Cover and stated in the Member Smart Contract Data.
Cryptographic Evidence means;
- where the Covered Members account is impacted directly, the submission of a claim will be taken as that evidence;
- where an account that is not a Covered Member is impacted;
- a cryptographically signed message from the impacted account that references the Covered Members account address; or
- the transaction hash of a zero value transaction from the impacted account to the Covered Members account; or
- other equivalent cryptographically signed evidence that links the impacted account to the Covered Members account.
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.
- far exceeds gas related costs involved in operating the contract;
- If the mutual has the capability of paying partial claim payments then 10% of the cover amount, otherwise at least 20% of the cover amount.
Designated Protocol means open source code running on a public blockchain network including any directly linked layer two components but excluding the underlying blockchain network and its mining activities.
Cover ends when:
• the full Cover Amount has been paid as claims; or
• the Cover Period specified at purchase has ended.
Claims Amount Guidance
The following guidelines shall be used by Members when deciding on claim amounts:
Where losses actually incurred are less than the Cover Amount a partial claim payment should be made if possible, otherwise a full claim payment of the entire Cover Amount should be made.