MakerDAO

The Maker Protocol provides all of its smart contract addresses and their Application Binary Interfaces (ABIs) in a centralized location, the Chainlog (chainlog.makerdao.com). The Chainlog provides information for both the Ethereum Mainnet and the Ethereum Goerli Testnet. It provides contract addresses with links to Etherscan and their respective ABIs. This information is easily accessible and clearly labeled, meeting the criteria for a 100% score.  

The protocol's documentation mentions the use of Github for hosting their codebase. This suggests that they have a public software repository on Github.  

Multiple contributors to the GitHub repository are public.

Devs did not respond to our comment on the #developers of their discord for 3 days.

Location: https://docs.makerdao.com/​

Excellent architecture documentation is included.

Maker's documentation is impressive and covers all deployed contracts in a highly organized fashion.

There is clear association from the documents to the code, but there is no explicit traceability to the implementation.

Organization and clarity is excellent.

As per the SLOC, there is 222% testing to code (TtC).

Code coverage is mentioned, but proof could not be found. Nevertheless, there's evidently heavy testing on this protocol.

Code coverage is mentioned, but proof could not be found. Nevertheless, there's evidently heavy testing on this protocol.

The protocol had runtime formal verification performed.

The protocol has undergone multiple audits prior to deployment. The documentation provides transparency to the community with respect to the results of the Multi Collateral Dai (MCD) Audits, Bug Bounty Program, and Formal Verification. These audits are publicly accessible, and any feedback from these audits have been implemented by the protocol's developers. This is evident from the regular updates on MCD Security Roadmap and the publication of the Runtime Verification Audit. Therefore, the quality and adequacy of the protocol's smart contract audits are high.  

No explicit matrix of audit applicability was found. However, there are a small number of audits and all are clearly applicable to the multi-collateral DAI deployed. For this reason the intent is met and a 100% score is given.

MakerDAO initiated the Bug Bounty program privately for selected researchers (Private testnet on June 3rd). This does not count based on our process. They launched a public bu bouty program through HackerOne. With a top payout of 100k, this scores 70% as per our guidance.  

Maker is a very mature protocol where dynamic on chain variations can have significant impacts on the protocol. For this reasoning bots for may aspects have always been a big part of the protocol, such as auction keepers and market maker keepers.

Based on the provided sources, there is evidence of one out of four security measures. The documentation mentions that the website is protected by Cloudflare, which provides DDoS protection. However, there are no explicit mentions of DNS steps to protect the domain, intrusion detection protection on the front end, or unwanted front-end modification detection.  

The code is upgradeable via spells which have timelocks and roles and it executes automatically based on MKR votes.

50% Code is upgradeable with minimal explanation. The detailed documentation on spells does not clearly describe the capability. The language is very specific and would not be clear to an finance person without extensive MAKER experience.

Evidently all code changes are executed via spells. Spells are automatically executed after a MKR vote, meaning their are no admins. This not clearly explained. The language is very protocol specific.    The provided documents contain information about various aspects of the protocol but do not specifically detail the admin addresses, roles, and capabilities. While the documentation does provide in-depth details about contract mechanisms, parameters, and authorizations, it does not clearly define or explain the roles and capabilities of admins within the protocol. The information appears to be dispersed and fragmented, requiring further investigation and potential inference to identify admin-related details.  

Evidently all code changes are executed via spells. Spells are automatically executed after a MKR vote, meaning their are no signers per say.     The detailed documentation on spells is not clear on this even after it is explained, you cannot find clear words in the documentation.    

Evidently all code changes are executed via spells. Spells are automatically executed after a MKR vote, meaning their are no signers per say. For this reason a transaction signing policy is not required and a 100% score is given.    The provided documentation does not appear to contain a transaction signing policy as outlined in the research instructions. The documentation mainly focuses on the operation and governance of the protocol, but does not provide any specific procedures or requirements for transaction signing, such as the use of specific wallets, browsers, or VPNs, or requirements for the physical and digital environments in which transactions are initiated and executed.  

The protocol's Oracle is sufficiently documented. The Maker Protocol's Oracle Module is thoroughly outlined in the technical documentation which includes details on its core components, Median and OSM contracts. It provides information on the function of the Oracle Module, which is deployed for each collateral type and feeds price data for a corresponding collateral type to the Vat. The documentation also explains the mechanism of the Oracle, which includes the whitelisting of addresses and how price updates are broadcasted off-chain, fed into a median, and then pulled into the OSM. Additional details are provided in the Median - Detailed Documentation which explains the function and behavior of the median in the Oracle Module.  

The Maker Protocol has implemented a Flash Mint Module which allows anyone to mint DAI up to a limit set by Maker Governance with the condition that they pay it all back in the same transaction with a fee. While this could potentially open up the protocol to flashloan attacks, the module has been designed in a way to exploit arbitrage opportunities without having to commit upfront capital. This makes the DeFi space safer overall as it allows for exploits requiring a large amount of capital to be found quicker. The fees also provide an income source for the protocol. Therefore, the protocol has implemented countermeasures against flashloan attacks.