| description |
|---|
Here are some of the things we do to ensure protocol security |
Ensuring the security and optimisation of a live protocol requires a multi faceted approach. In addition to a macro-level architecture and a robust governance decentralization plan, the micro-level architecture, code formatting, documentation, testing procedures and auditing play vital roles in the process.
Open reward pool for discovering and reporting vulnerabilities in the mStable protocol. It can also be viewed on Immunefi.
{% page-ref page="mstable-bug-bounty.md" %}
****Consensys Diligence - Q4 2020
Report available here or PDF below.
{% file src="../../.gitbook/assets/mstable-audit-2020-07.pdf" %}
Initial audit performed by Bramah Systems - Q2 2020
{% file src="../../.gitbook/assets/mstable-audit-bramah-systems.pdf" caption="Audit report" %}
Certik audit - Q1 2021
{% file src="../../.gitbook/assets/rep-mstable_18_01_2020.pdf" caption="REP-mStable_18_01_2021" %}
https://certik.org/projects/mstable
Peckshield Audit - Q1 2021
{% file src="../../.gitbook/assets/peckshield-audit-report-mstable-icsmm-v1.0.pdf" caption="Audit report" %}
This audit was carried out on the previously proposed ISCMM (an AMM prototype) which did not make it into production and was instead replaces by MIP-7. The report however is still useful as a broader assessment of mStable's codebase at the time.
DeFi Safety mStable Process Quality Review - Score: 97%
https://docs.defisafety.com/finished-reviews/mstable
{% hint style="info" %} The mStable-contracts repository underwent full unit and integration testing. See the report on Coveralls here {% endhint %}
mStable contracts are tested with both integration results and invariants in mind.
Tests are written in Typescript, using Typechain to generate typings for all contracts. Tests are executed using truffle and ganache-cli.
Ganache-fork
mStable-contracts test suite is built to support execution on a mainnet fork of ganache. This allows tests to be ran using all mainnet dependencies (bAssets, lending protocols). To do this, certain mainnet accounts need to be unlocked to allows tx to be sent from that origin.
Running tests on a fork of mainnet allows us to validate that all connections act as assumed before performing a real mainnet deployment.
Coverage
Solidity-coverage is used to run coverage analysis on test suite.
This produces reports that are visible in the /coverage folder, and navigatable/uploadable. Ultimately they are used as a reference that there is some sort of adequate cover, although they will not be a source of truth for a robust test framework. Reports publically available on coveralls.
All contracts have undergone static analysis using Slither and Securify, with resulting outputs either fixed or dismissed.
One of the core principles of our architecture design is the separation of concerns. Many critical modules are immutable, and those modules which are upgradable have an option to be permanently locked into place, subject to a governance process. Contracts that implement Open-Zeppelin's Upgradable Proxies are governed and upgraded by a DelayedProxyAdmin, via mStable governance.
mStable uses common standardised contracts, for example Open-Zeppelin where possible and learn from previous smart contract systems by applying security measures like ReentrancyGuard in Solc v 0.5.x.
The Nexus supports the system by providing read access of all modules, as a sort of system registry. This centralises the burden for updates and reduces the chance of a mishap.
Deterministic and battle tested deployment scripts play a vital role in ensuring that live contracts are instantiated with and attributed to the correct addresses.
Code should be easily understandable and so write with the average reader in mind. mStable's contracts are formatted for optimal comprehension and supplemented with comprehensive comments.
For example:
- Using descriptive and verbose variable and function names
- Using error messages for every revert, require or assert statement
- Avoid function and variables shadowing
- Remove unused functions, variables and parameters
- Always declare function & variable visibility
Capitalising on the growing ecosystem of tooling available for writing contracts on Ethereum, we use such tools as:
- Code coverage with solcover
- Gas reporting and optimisation with eth-gas-reporter
- Implanting linter, gas and testing rules into a CI task
{% hint style="info" %} Got a question or concern about security? Email directly to [email protected] {% endhint %}