Risk Assessment Resources

Members who want to act as Risk Assessors can use resources on this page.


Any member can act as a Risk Assessor within the mutual, but some members have more experience than others when it comes to analysing code and assessing risk. Risk Assessors who want to dig in and learn more about the various risk factors, such as smart contract weaknesses or oracle failure, past exploits, or risk assessment tools can utilise the sections below.
This page is a living resource that will be updated over time. The below sections cover risks related to Protocol Cover and Yield Token Cover. A Custody Cover risks section is forthcoming.
Members should not rely solely on the information provided. Anyone who acts as a Risk Assessor should review the Risks page.
There are multiple ways that smart contract failure can lead to a loss of funds within a smart contract system. Several of the other risk factors below can be caused by smart contract vulnerabilities, so the entry regarding smart contracts in the Protocol Cover wording is broad and reads as follows:
"1.1. Code being used in an unintended way;"
Below are resources regarding smart contract security and known weaknesses within smart contract systems.
There are different approaches to prevent or mitigate severe vulnerabilities. Risk Assessors can use audits, bug bounties, incident handling reports, and various risk assessment resources to evaluate a protocol. For a general overview, members can refer to the different resources below where risks have previously been assessed.


ConsenSys Blockchain Security Database: The Blockchain Security Database is an open-source database created by ConsenSys Diligence to act as a repository of security information organised by projects. The database contains a catalogue of blockchain projects with details pertaining to their security including audits, bounties, and security contacts.
ConsenSys Diligence | Select Public Audits: ConsenSys Diligence has helped a wide range of projects across the blockchain ecosystem to ensure their protocols are ready for launch and built to protect users.
OpenZeppelin | Security Audits: Repository of publicly available audits conducted by OpenZeppelin.
Solidified Audit Database: This repository contains actual reports delivered to clients.
Trail of Bits Publications: Academic papers, conference presentations, datasets, podcasts, security reviews, and workshops. Many resources for review.

Bug Bounties


Incident Handling

Crytic/Blockchain Security Contacts: This directory is a community-curated resource for contacting security teams. It identifies the best way to contact an organisation's security team so that hackers can report vulnerabilities directly to the organisations that can resolve them.
Igor Igamberdiev's Twitter Account: Research analyst at The Block. Always provides comprehensive postmortems after attacks, exploits, etc.
Origin Protocol's Catalogue of Security Incidents in DeFi: DeFi attack postmortems used by Origin Protocol team to prevent attacks of the same nature, provide ongoing education for team, and spread knowledge within team about Origin contract security.
Solidified | Most common smart contract bugs of 2020: A walk through of the most common bugs and security vulnerabilities found in Solidified audits during 2020.

Risk Assessment Resources

Better Programming Encyclopedia of Smart Contract Attacks and Vulnerabilities: Though this list may cover known attacks, new exploits are still being discovered regularly, and, as such, this should only be the beginning of your research into smart contract security as an engineer.
Certik Security Leaderboard: Certik-run leaderboard for various protocols with security score, audit history, and other factors.
ConsenSys | DeFi Score: The DeFi Score is a framework for assessing risk in permissionless lending platforms. It's a single, consistently comparable value for measuring protocol risk, based on factors including smart contract risk, collateralization, and liquidity.
DeFi Defense DAO | DeFi Risk Tools List: Included is a list of the available tools, projects, and protocols for analyzing and managing risk within DeFi. Note that this list is focused on technical, centralization, and liquidity risk of DeFi protocols, NOT price risk of tokens.
DeFi Safety: this site uses a simple scoring matrix, and users should read the Process Quality Review Process section to understand the approach taken in determining scores.
Ethereum Foundation Security Entry: Article and resources on the foundation's website about security as it is related to smart contracts on the Ethereum network.
ImmuneFi's Learn Page: This is an introductory guide and an external resources page (v0.1) for learning about the basics of blockchain, smart contracts, and smart contract security on a more conceptual level. The goal is to provide a launching pad for hackers, researchers, devs, and companies to quickly get up to speed on the technology, so they can start hunting for bugs and collecting bounties
rekt: Reviews of past exploits and DeFi hacks. There is a comprehensive list of protocols that have suffered losses due to some form of exploit in the past.
SlowMist Hacked: This is a search engine that allows users to query protocols, exchanges, blockchains, etc. by name for records of hacks/exploits.
SWC Registry: Smart contract weakness classification and test cases.
The entry on severe oracle failure in the Protocol Cover wording reads as follows:
"Severe oracle failure where the oracle price is either:
1.3.1. deliberately manipulated so that it is materially outside observed market rates; or
1.3.2. 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"
Below are some basic resources about oracles. These are simplified explanations, and they are presented to give members insight into what an oracle is; who the major oracle solution providers are; and what the possible weaknesses of oracle solutions are at the protocol level.

What's an oracle?

For a more detailed explanation of what oracles are, what they do, and the problem they solve, see the Ethereum Foundation's Oracle entry.

Centralised Oracle Solutions vs. Decentralised Oracle Solutions

Since blockchains cannot query data directly on-chain or communicate data to the real world, then an oracle solution is necessary to bridge the blockchain and the real world through communication of bi-directional data.
A centralised oracle solution acts as the middle point between the real world and the blockchain but if a centralised oracle solution fails, it's also a centralised point of failure. Using centralised oracle providers nullifies the benefits offered by using decentralised technology, which is why decentralised solutions emerged to solve this problem.
Chainlink has a great video that outlines the oracle problem that exists for decentralised systems: What is a Blockchain Oracle? What is the Oracle Problem?
Decentralised oracle solutions use nodes to run the oracle software, and the nodes communicate data between the real world and the blockchain. This is a distributed system, so if some nodes fail, other nodes are still operational and communicating data. With no central point of failure, greater security is delivered to the network.

Decentralised Oracle Solutions

Alpha Oracle Aggregator: Uses Band Protocol and Chainlink data feeds "to ensure scalability, flexibility, and security."

Examples of Past Oracle Failures

18/02/2020 | bZx Oracle Manipulation Attack: The first flash loan attack on bZx was discussed in the Nexus Mutual postmortem report, but bZx was exploited several times in 2020. This is in reference to the second attack, which was disclosed as an oracle manipulation attack by bZx CVO and operations lead Kyle Kistner. In the second attack, the hackers took out a flash loan from Aave, manipulated the price on the Kyber Network by executing large trades, which drove up the prices of certain assets. With the prices inflated on the Kyber Network, the attacker took advantage of the price difference and used arbitrage to drain funds from the bZx pools. At the time of the flash loan attack, bZx was only using Kyber to source the API for prices.
14/11/2020 | Value DeFi Oracle Manipulation Attack: You can see from the transaction that the Value DeFi exploit was intricate. Because Value DeFi used the Curve Fi AMM as a price oracle for the MultiStables Vault, the attacker was able to create an imbalance in the 3Pool, which drove up the price of USDC. Through a series of swaps that used the inflated USDC price to use an arbitrage strategy to drain $7.4m from the MultiStables Vault. Emiliano Bonassi provided some great commentary on the exploit here.
26/11/2020 | Compound Oracle Manipulation Attack: When market prices dropped on 26/11, liquidations on Aave, MakerDAO and other lenders were relatively small compared to the $89m of liquidations that occurred on Compound. Compound's oracle used Coinbase as the API to track price feeds for the protocol. It was speculated that someone maliciously manipulated the price of DAI from its normal $1 range to $1.30 at the time of attack. Compound used Coinbase as the only source for price feed data, and insufficient liquidity for stablecoin pairs caused an increase in the DAI price. The Compound oracles were providing the $1.30 per DAI price, which meant users' debt ballooned and resulted in the protocol liquidating many positions. Because the oracle provided inaccurate prices compared to other DeFi lending protocols, users on Compound were liquidated.
You can see Arthur's Tweet (@Arthur_0x) and ChainLinkGod.eth 2.0's Tweet (@ChainLinkGod) regarding the Compound liquidations mentioned above.
All of the above examples of price manipulation resulted from having only one API for a price feed. To protect against the risk of flash loan attacks and price manipulation, a protocol should use multiple independent oracle data sources with deep liquidity.
The entry on economic design failure in the Protocol Cover wording reads as follows:
"Economic design failure resulting in the unintended confiscation or seizure funds deposited into the designated protocol for either collateral, liquidity provision or staking purposes only;"
Below are resources that provide insight into economic design failure and outline an example of economic design failure.

What constitutes economic design failure?

Unlike other types of events that cause material losses such as an exploit, a loss of funds due to economic design failure was not covered according to the previous terms in the Smart Contract Cover wording. Protocol Cover was designed to cover events that fall outside of previously defined loss events in Smart Contract Cover.
‌Economic design failure can be defined as a loss event triggered when a design feature allows funds to be withdrawn or liquidated during a period of extreme stress on a smart contract system when there is no attack vector from an outside actor and the smart contract system functions as designed.
‌The above definition is one possible interpretation of economic design failure, though the term "economic design failure" is open to interpretation by all members of the mutual.
The case study for such a scenario is the MakerDAO Black Thursday event in 2020.

Example of Economic Design Failure

12/03/2020 | MakerDAO Black Thursday Event: On this day, a severe downturn caused prices to drop rapidly. The Chainlink oracle solution struggled to keep up with market prices as they continued to drop. While prices were dropping, the MakerDAO protocol was put through a stress test. Liquidators were able to bid on auctions with minimal amounts of DAI and win these auctions, which resulted in a net loss for the MakerDAO protocol. The oracle solution functioned, albeit with some delay, but the economic design was the key factor that allowed for the sale of collateral for minimal amounts of DAI and this led to under-collateralised positions that resulted in a net loss for the protocol.
The entry on governance attacks in the Protocol Cover wording reads as follows:
"1.4. a governance attack where;
1.4.1. the designated protocol is controlled by holders of a governance token that is programmatically linked to an on-chain governance system; and
1.4.2. a small group or individual gains control of the designated protocol by manipulating the on-chain governance system; and
1.4.3. the designated protocol is altered resulting in the unintended confiscation or seizure of funds deposited into the designated protocol for either collateral, liquidity provision or staking purposes only;"
Below are resources that provide insight into governance attacks and outline examples of centralised risk in various DeFi protocols.

Risks of Centralisation in DeFi

Many DAOs use token-based voting for governance, and it is possible for a few large holders or delegates to directly influence votes to pass proposals that may be beneficial for large holders and detrimental to the overall community.
"Decentralized governance in DeFi: Examples and pitfalls", a paper written by Stroponiati, Abugov, Varelas et al., outlines the risk of centralisation in leading DeFi protocols. Because large holders are typically team members, venture capital firms, and early-stage investors, the actual voting power of the community can be negligible when voting power is skewed toward an influential group of token holders. By definition, this is governance run by oligarchy, a small group of people having control of a protocol's governance process.
As defined in the Protocol Cover wording, governance attacks that alter a protocol in such a way that results in users' funds being seized by a member with majority voting power are covered for cover holders during an active cover period.