The Maker Foundation's highest priority is the security of the Maker Protocol. As such, we have dedicated many resources (internal and external) to our security efforts surrounding the launch of Multi-Collateral Dai (MCD) on November 18. We will, of course, continue these efforts thereafter. 

On July 24, we published the first security roadmap update, which introduced our security tracks. Today, we are excited to provide the outcomes of those efforts: findings from our Bug Bounty Program, MCD formal verification and audit report results, and progress updates on our Integration Partner Program. 

Bug Bounty Program Findings

In July, we launched our first public Bug Bounty Program, and we are happy to see that it turned out to be a success. Three high-severity bugs and one critical-severity bug have been discovered, resulting in bounty reward payments totaling $90,000.

The vulnerabilities consisted of unwanted interactions between the Dai Savings Rate (DSR) module and the Maker Protocol in one case, and the emergency shutdown module and the auctions in another case. The discoveries were in line with our expectations, as these modules either required additional scrutiny or were the most recent ones to be integrated with the system.

Given that the security of the system remains our highest priority, we will continue the bug bounty program indefinitely.

Formal Verification Results

The MCD system's core contracts have been formally verified, and the verification of peripheral and helper contracts is in the final stage. We are now working on the formal verification of the tokens being considered by MKR voters as new collateral types, focusing on the secondary contracts as well as on the governance contracts in the system. Additionally, we have incorporated formal verification into our continuous testing and release processes. 

Formal verification completed thus far:

• Core system
• Dai token contract
• Auction contracts
• Dai Savings Rate (DSR)
• Emergency Shutdown Module (ESM)

As expected, our formal verification approach proved complementary to the other security tracks. While formal verification isn’t a silver bullet in defense of system threats, the methodology has been reconfirmed as a highly effective tool that significantly improves the overall security of the system.  

We will, of course, continue the formal verification process and update past proofs as audit and bug bounty findings deem necessary.  

Security Audits

In addition to conducting formal verification, traditional security audits have been performed.

Runtime Verification Update Summary

Runtime Verification, an Illinois-based software analysis company, uses runtime verification-based techniques to improve the safety, reliability, and technical “correctness” of software systems. The Runtime Verification team has completed its high-level model of the core MCD system and has begun building models of the other modules. The team expects to complete their work late this fall, likely by the end of November. 

Trail of Bits Final Audit Report 

Trail of Bits (ToB), a world leader in security, has audited our MCD smart contracts. ToB reviews a broad variety of software, creates security tooling, and consults on the modifications necessary for secure system deployment. Its audit consisted of manual review, automated analysis, and bespoke tool development. Read ToB’s final audit report.

Summary of Findings

• The Trail of Bits team identified two medium-severity issues, four low-severity issues, and eight informational security issues.
• In its audit report, the ToB team noted that our use of formal verification eliminated much of the “low-hanging fruit” in terms of vulnerabilities, and recommended continued use.
• The ToB team also developed several security analysis tools specialized to the MCD codebase. These tools were used throughout the course of the audit to discover bugs, and then delivered to the MCD team once the audit was completed.
• ToB had one specific finding concerning the DSR that we want to address here (source, pp. 22). We understand the perceived issue and are exploring the possibilities of how we could apply the DSR to Dai throughout the system. In the meantime, we agree with the risks of users' non-standard ERC-20 proxies for the DSR and have begun R&D on a proof-of-concept implementation. As always, we recommend users practice caution when using third-party smart contracts to interact with the MCD system.

PeckShield Final Audit Report 

PeckShield, a security services organization based in China, had previously and independently verified the Maker DSChief vulnerability that was patched in May. Therefore, we contracted them to do a formal audit. Read PeckShield’s final audit report.  

Summary 

• The PeckShield team identified one high-severity issue (previously discovered through the bug bounty program), one medium-severity issue, four low-severity issues, and 10 informational security issues.
• In its audit report, the team recognized our independent security efforts: “We always recommend proceeding with several independent audits and a public bug bounty program to ensure the security of smart contract(s).” 
• Zero bugs noted in PeckShield’s “17 Typical Smart Contract Coding Bugs” list were found. 

Third-Party Audit Results

In addition to the audit results provided by the three contracted organizations noted above, we were contacted by a third-party security firm, Certora, who presented findings after reviewing the MCD code on their own and with their own tools. We want to thank Certora for independently verifying two important vulnerabilities.

Overlapping Findings

Given the thorough and broad nature of the Trail of Bits and PeckShield audits, our Bug Bounty Program, and the Certora audit, we expected, correctly, that some overlap in coverage and findings would result.  The audit overlaps detailed in the diagram below represent the benefits and strength of combining our own security efforts with outside oversight. For a detailed definition of the findings, see the individual audit report links above.

Overall, security audits have covered the following areas within MCD:

• The core Maker Protocol
• Incentive reasoning
• DoS, Replay, Front-running, System/Blockchain-level attacks 
• Governance Attacks
• Governance (general)
• Front-end contracts and collateral adapters
• Oracles
• Off-chain price-feed infrastructure
• On-chain oracle contracts
• System deployment and Permissions correctness
• Auctions
• K-dss

Integration Partner Program

The campaign to promote projects that have integrated and tested their products and services within MCD has been successful thus far. As of this writing, we have shared the following content with the community and with our partners to help ensure their projects will be ready for the launch of MCD launch:

• The MCD Roadmap (regular updates on the progress of MCD).
• An explanation of the MCD smart contracts (detailed in MCD 101).
• The Migration Guide (an overview of the process for upgrading existing Dai and CDPs to MCD).
• Integration tooling (detailed in our Developer Guides).

Next, we will walk partners through the final steps of preparation for MCD and the Dai Savings Rate. 

In Summary 

Our efforts from all four security tracks have resulted in the discovery of a number of bugs, including some high- and critical-severity issues. We’ve taken steps to evaluate and mitigate these issues, and we will continue to work with auditors to verify that we have completely addressed them pre-MCD launch. 

Next Steps

Moving forward, we will continue to ensure that our security efforts surrounding MCD are rigorous. We will follow our security roadmap, including our formal verification efforts, carry on with the Bug Bounty Program, and, of course, maintain threat monitoring. Security auditing is a continuous effort; should additional issues be identified after launch, we have the mechanisms in place to upgrade the system with permission of MKR holders. 

In terms of more immediate next steps, we will focus on the following:

• A staged MCD rollout.
• Upgradeability of instant-access modules, which contain the components to make direct, bounded changes to the Dai Credit System without consensus in DS-Chief.
• An Emergency Shutdown and redeployment test run.

Finally, we are looking forward to continuing to work with the best security partners in the industry. Their audit reports provide deep dives into areas of coverage and concern, and we are happy to share them with our community to help everyone better understand how Multi-Collateral Dai works. 

For more information on security audits, the bug bounty program, and our formal verification efforts, visit security.makerdao.com. To follow us on our path toward MCD, be sure to review and bookmark the MCD Roadmap.