1 | <br/>
|
2 | <img src="https://mstable.org/assets/img/email/mstable_logo_horizontal_black.png" width="420" >
|
3 |
|
4 | ![CI](https://github.com/mstable/mStable-contracts/workflows/Test/badge.svg)
|
5 | [![Coverage Status](https://coveralls.io/repos/github/mstable/mStable-contracts/badge.svg?branch=master&t=BVkH5s)](https://coveralls.io/github/mstable/mStable-contracts?branch=master)
|
6 | [![Discord](https://img.shields.io/discord/525087739801239552?color=7289DA&label=discord%20)](https://discordapp.com/channels/525087739801239552/)
|
7 | [![npm version](https://badge.fury.io/js/%40mstable%2Fprotocol.svg)](https://badge.fury.io/js/%40mstable%2Fprotocol)
|
8 |
|
9 | <br />
|
10 |
|
11 | This repo contains all contracts and tests relevant to the core mStable protocol. mStable is a protocol built to make stablecoins easy, robust and profitable.
|
12 |
|
13 | mStable Assets ([mAssets](./contracts/masset/Masset.sol)) are tokens that allow minting and redemption for underlying Basket Assets (`bAssets`) of the same peg (i.e. USD, BTC, Gold). The InvariantValidator applies both min and max weights to these bAssets, and enforces penalties and bonuses when minting with these assets to provide low slippage swaps. This Invariant applies progressive penalties and bonuses on either end of the weight scale - having the result of having a large area of low slippage. `bAssets` are integrated with lending protocols (initially Aave, Compound) to generate interest which is accrued in `mAsset` terms. mAssets can be deposited to earn native interest through their respective Savings Contract, just like you would with a savings account. `bAssets` within an `mAsset` can also be swapped with low slippage (provided they remain within their [validator](./contracts/masset/InvariantValidator.sol) limits), with a `swapFee` credited additionally to Savers.
|
14 |
|
15 | Core mAsset contracts utilise OpenZeppelin's [InitializableAdminUpgradeabilityProxy](https://github.com/OpenZeppelin/openzeppelin-sdk/blob/master/packages/lib/contracts/upgradeability/InitializableAdminUpgradeabilityProxy.sol) to facilitate future upgrades, fixes or feature additions. The upgrades are proposed by the mStable Governors (with current governor address stored in the [Nexus](./contracts/nexus/Nexus.sol) - the system kernel) and executed via the [DelayedProxyAdmin](./contracts/upgradability/DelayedProxyAdmin.sol). Both changes to the `governor`, and contract upgrades have a one week delay built in to execution. This allows mStable users a one week opt out window if they do not agree with the given change.
|
16 |
|
17 | mStable rewards those who contribute to its utility and growth - for more information see [MTA](https://docs.mstable.org/mstable-assets/functions).
|
18 |
|
19 | <br />
|
20 |
|
21 | 🏠 https://mstable.org
|
22 | 📀 https://app.mstable.org
|
23 | 📄 https://docs.mstable.org
|
24 |
|
25 | <br />
|
26 |
|
27 | ## Bug bounty
|
28 |
|
29 | Found a bug? Claim a reward from our open [Bug Bounty](https://docs.mstable.org/protocol/security/mstable-bug-bounty) by reporting it to mStable (following the [responsible disclosure](https://docs.mstable.org/protocol/security/mstable-bug-bounty#responsible-disclosure) policy)
|
30 |
|
31 | <br />
|
32 |
|
33 | ---
|
34 |
|
35 | <br />
|
36 |
|
37 | ## Branches
|
38 |
|
39 | - `master` contains complete, tested and audited contract code, generally on `mainnet`
|
40 | - `beta` is for the pre-release code, generally on `ropsten`
|
41 |
|
42 | <br />
|
43 |
|
44 | ## Artifacts
|
45 |
|
46 | We publish the contract artifacts to an npm package called [@mstable/protocol](https://www.npmjs.com/package/@mstable/protocol). You can browse them via [unpkg.com](https://unpkg.com/browse/@mstable/protocol@latest/).
|
47 |
|
48 | <br />
|
49 |
|
50 | ## Dev notes
|
51 |
|
52 | ### Prerequisites
|
53 |
|
54 | - Node.js v10.22.0 (you may wish to use [nvm][1])
|
55 | - [ganache-cli][2]
|
56 |
|
57 | ### Installing dependencies
|
58 |
|
59 | ```
|
60 | $ yarn
|
61 | ```
|
62 |
|
63 | ### Testing
|
64 |
|
65 | Tests are written with Hardhat, Ethers, Waffle & Typescript, using [Typechain](https://github.com/ethereum-ts/TypeChain) to generate typings for all contracts. Tests are executed using `hardhat` in hardhats evm.
|
66 |
|
67 | ```
|
68 | $ yarn test
|
69 | ```
|
70 |
|
71 | #### Suite
|
72 |
|
73 | Key folders:
|
74 |
|
75 | - `/contracts/z_mocks`: All mocks used throughout the test suite
|
76 | - `/security`: Scripts used to run static analysis tools like Slither and Securify
|
77 | - `/test`: Unit tests in folders corresponding to contracts/xx
|
78 | - `/test-utils`: Core util files used throughout the test framework
|
79 | - `/machines`: Mock contract machines for creating configurable instances of the contracts
|
80 | - `/types`: TS Types used throughout the suite
|
81 | - `/generated`: Output from Typechain; strongly-typed, Ethers-flavoured contract interfaces
|
82 |
|
83 | #### Coverage
|
84 |
|
85 | [Solidity-coverage](https://github.com/sc-forks/solidity-coverage) is used to run coverage analysis on test suite.
|
86 |
|
87 | 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](https://coveralls.io/github/mstable/mStable-contracts).
|
88 |
|
89 | _NB: solidity-coverage runs with solc `optimizer=false` (see [discussion](https://github.com/sc-forks/solidity-coverage/issues/417))_
|
90 |
|
91 | ### CI
|
92 |
|
93 | Codebase rules are enforced through a passing [CI](https://circleci.com) (visible in `.circleci/config.yml`). These rules are:
|
94 |
|
95 | - Linting of both the contracts (through Solium) and TS files (ESLint)
|
96 | - Passing test suite
|
97 | - Maintaining high unit testing coverage
|
98 |
|
99 | ### Code formatting
|
100 |
|
101 | - Solidity imports deconstructed as `import { xxx } from "../xxx.sol"`
|
102 | - Solidity commented as per [NatSpec format](https://solidity.readthedocs.io/en/v0.5.0/layout-of-source-files.html#comments)
|
103 | - Internal function ordering from high > low order
|
104 |
|
105 | <br />
|
106 |
|
107 | [1]: https://github.com/nvm-sh/nvm
|
108 | [2]: https://github.com/trufflesuite/ganache-cli
|
109 |
|
110 | ### Command Line Interface
|
111 |
|
112 | [Hardhat Tasks](https://hardhat.org/guides/create-task.html) are used for command line interactions with the mStable contracts. The tasks can be found in the [tasks](./tasks) folder.
|
113 |
|
114 | A separate Hardhat config file [tasks.config.ts](./tasks.config.ts) is used for task config. This inherits from the main Hardhat config file [hardhat.config.ts](./hardhat.config.ts). This avoids circular dependencies when the repository needs to be compiled before the Typechain artifacts have been generated. This means the `--config tasks.config.ts` Hardhat option needs to be used to run the mStable tasks.
|
115 |
|
116 | Config your network. If you are just using readonly tasks like `mBTC-snap` you don't need to have a signer with Ether in it so the default Hardhat test account is ok to use. For safety, the mainnet config is not committed to the repository to avoid accidentally running tasks against mainnet.
|
117 |
|
118 | ```
|
119 | mainnet: {
|
120 | url: process.env.NODE_URL || "",
|
121 | accounts: {
|
122 | mnemonic: "test test test test test test test test test test test junk",
|
123 | },
|
124 | },
|
125 | ```
|
126 |
|
127 | **Never commit mainnet private keys, mnemonics or provider URLs to the repository.**
|
128 |
|
129 | Examples of using the Hardhat tasks
|
130 |
|
131 | ```zsh
|
132 | # List all Hardhat tasks
|
133 | hh --config tasks.config.ts
|
134 |
|
135 | # Set the provider url
|
136 | export NODE_URL=https://mainnet.infura.io/v3/yourApiKey
|
137 |
|
138 | # To run the mBTC-snap task against mainnet
|
139 | yarn task mBTC-snap --network mainnet
|
140 | ```
|