If you notice some outdated information please let us know!
Process Quality Review (0.9)
Nexus Mutual V2
PASS
Scoring Appendix
The final review score is indicated as a percentage. The percentage is calculated as Achieved Points due to MAX Possible Points. For each element the answer can be either Yes/No or a percentage. For a detailed breakdown of the individual weights of each question, please consult this document.
Very simply, the review looks for the following declarations from the developer's site. With these declarations, it is reasonable to trust the smart contracts.
- Here are my smart contract on the blockchain(s)
- Here is the documentation that explains what my smart contracts do
- Here are the tests I ran to verify my smart contracts
- Here are all the security steps I took to safeguard these contracts
- Here is an explanation of the control I have to change these smart contracts
- Here is how these smart contracts get information from outside the blockchain (if applicable)
This report is for informational purposes only and does not constitute investment advice of any kind, nor does it constitute an offer to provide investment advisory or other services. Nothing in this report shall be considered a solicitation or offer to buy or sell any security, token, future, option or other financial instrument or to offer or provide any investment advice or service to any person in any jurisdiction. Nothing contained in this report constitutes investment advice or offers any opinion with respect to the suitability of any security, and the views expressed in this report should not be taken as advice to buy, sell or hold any security. The information in this report should not be relied upon for the purpose of investing. In preparing the information contained in this report, we have not taken into account the investment needs, objectives and financial circumstances of any particular investor. This information has no regard to the specific investment objectives, financial situation and particular needs of any specific recipient of this information and investments discussed may not be suitable for all investors.
Any views expressed in this report by us were prepared based upon the information available to us at the time such views were written. The views expressed within this report are limited to DeFiSafety and the author and do not reflect those of any additional or third party and are strictly based upon DeFiSafety, its authors, interpretations and evaluation of relevant data. Changed or additional information could cause such views to change. All information is subject to possible correction. Information may quickly become unreliable for various reasons, including changes in market conditions or economic circumstances.
This completed report is copyright (c) DeFiSafety 2023. Permission is given to copy in whole, retaining this copyright label.
Code and Team
100%
This section looks at the code deployed on the relevant chains and team aspects. The document explaining these questions is here.
1. Are the smart contract addresses easy to find? (%)
The smart contract addresses for the protocol are easily accessible and clearly labeled on the Nexus Mutual SDK website. From the GitHub readme, click Mainnet address. The addresses are listed alongside the name of each contract, such as "Cover", "CoverMigrator", "CoverNFT", "CoverViewer", "Governance", and more. This information is publicly available and does not require any effort to find.
2. Does the protocol have a public software repository? (Y/N)
Location: https://github.com/NexusMutual/smart-contracts
3. Is the team public (not anonymous)?
Over 2 names are public on the GitHub.
4. How responsive are the devs when we present our initial report?
100% Devs responded within 24hours
Code Documentation
50%
This section looks at the software documentation. The document explaining these questions is here.
5. Is there a whitepaper? (Y/N)
Yes, there is the equivalent to a white paper in the docs; https://docs.nexusmutual.io/protocol/.
6. Is the protocol's software architecture documented? (%)
There is a very limited architecture diagram in the docs section. It is not really applicable to the code but rather the flow of information through the protocol. For this reason, we will give it a score of 50% rather than the 75% for basic block diagram.
7. Does the software documentation fully cover the deployed contracts' source code? (%)
There are two types of documentation. The two do not connect very well. In the docs section there is a good top-level description of the protocol and its logic from a users perspective. This information is reasonably complete but does not connect to the software. In the software there is varying amounts of software documentation in comments in the code. In some modules it is quite complete. In others it is nonexistent. In the primary module (Cover.sol) the documentation is mixed. Given that there clearly is some level of documentation but it is not fully detailed or well connected we will give a score of 50%.
8. Is it possible to trace the documented software to its implementation in the protocol's source code? (%)
Traceability is very limited. There is no connection with the architecture and the documentation to the code. Obviously the comments in the code is closely connected to the code. Based on the guidance, a score of 0% is appropriate.
9. Is the documentation organized to ensure information availability and clarity? (%)
Has described previously, the documentation is quite disconnected. The protocol documentation is very clear and well organized though. For this reason a score of 50% is given.
Testing
82%
This section looks at the 3rd party software audits done. It is explained in this document.
10. Has the protocol tested their deployed code? (%)
TtC is 229% so score of 100% Test to Code = 35351 / 15437 = 229% ─────────────────────────────────────────────────────────────────────────────── Language Files Lines Blanks Comments Code Complexity ─────────────────────────────────────────────────────────────────────────────── JavaScript 56 15437 2706 2801 9930 1530 ─────────────────────────────────────────────────────────────────────────────── Total 56 15437 2706 2801 9930 1530 ─────────────────────────────────────────────────────────────────────────────── Estimated Cost to Develop $300,879 Estimated Schedule Effort 8.713709 months Estimated People Required 3.067644 ─────────────────────────────────────────────────────────────────────────────── Processed 518826 bytes, 0.519 megabytes (SI) ─────────────────────────────────────────────────────────────────────────────── ─────────────────────────────────────────────────────────────────────────────── Language Files Lines Blanks Comments Code Complexity ─────────────────────────────────────────────────────────────────────────────── JavaScript 170 33260 5948 1051 26261 556 JSON 1 2091 0 0 2091 0 ─────────────────────────────────────────────────────────────────────────────── Total 171 35351 5948 1051 28352 556 ───────────────────────────────────────────────────────────────────────────────
11. How covered is the protocol's code? (%)
Coveralls indicates code coverage of 82%.
12. Is there a detailed report of the protocol's test results?(%)
Despite the fact that they are very well documented releases of the software, there is no evident dedicated test report. There is however a GitHub coveralls report and that is good for 70%.
13. Has the protocol undergone Formal Verification? (Y/N)
There is no evidence of formal verification reports.
Security
81%
This section looks at the 3rd party software audits done. It is explained in this document.
14. Is the protocol sufficiently audited? (%)
Nexus Mutual has conducted multiple smart contract audits before and after the mainnet deployment with firms such as Solidified, iosiro, and the G0 Group. The audits covered a range of contracts including the stacked risk, on-chain MCR, swap operator contracts, the distributor smart contracts, and the emergency response smart contract. In addition to these audits, Nexus Mutual has also set up a bug bounty program in collaboration with Immunefi, which incentivizes whitehat hackers to disclose vulnerabilities in exchange for payouts. These audits and the bug bounty program collectively demonstrate a commitment to code quality, security, and adherence to best practices in the DeFi space.
15. Is there a matrix of audit applicability on deployed code (%)? Please refer to the example doc for reference.
The Gitbook page of the audits organizes them with adequate detail. However, it is difficult to know which objects are applicable to version 2 of the software. If this was added, 100% score would result.
16. Is the bug bounty value acceptably high (%)
The bug bounty program offers a maximum bounty of $50,000 USD. While this is a significant amount, it does not meet the 50% threshold of $50k with an active program. The bounty program is listed as active and is hosted on Immunefi.
17. Is there documented protocol monitoring (%)?
No protocol monitoring documented.
18. Is there documented protocol front-end monitoring (%)?
After a thorough examination of the provided documentation, none of the terms related to front end monitoring - "DDOS Protection", "DNS Steps to protect the Domain", "Intrusion detection protection on the front end", or "Unwanted front-end modification detection" - were found. Therefore, it appears that there is no documented website front-end monitoring in place for this protocol.
Admin Controls
87%
This section covers the documentation of special access controls for a DeFi protocol. The admin access controls are the contracts that allow updating contracts or coefficients in the protocol. Since these contracts can allow the protocol admins to "change the rules", complete disclosure of capabilities is vital for user's transparency. It is explained in this document.
19. Is the protocol code immutable or upgradeable? (%)
0% Updateable code via governance code. There is no timelock on the results of governance votes. This gives a score of 70%
20. Is the protocol's code upgradeability clearly explained in non technical terms? (%)
The protocol's code upgradability is explained in non-technical terms. The documentation states that after a Protocol Improvement Proposal has been reviewed and posted on the forum for at least 14 days, it will be moved to an on-chain vote. If approved, the Engineering team will deploy the new code and deprecate the old one through a migration process. Although the document doesn't specifically mention the term "upgrade," the process described aligns with the concept of code upgradability. This gives a score of 100%.
21. Are the admin addresses, roles and capabilities clearly explained? (%)
As the code is updated directly via the DAO vote (without human intervention) there are no admin addresses or roles (except for the ability to pause). For the pause capability there is a multisig whcih has a list of names. This gives a score of 100%.
22. Are the signers of the admin addresses clearly listed and provably distinct humans? (%)
The protocol's documentation clearly lists the signers of the admin addresses and they are provably distinct individuals. The signers of the admin addresses are BraveNewDeFi, Rei, Sem, Kayleigh, and Hugh. It is mentioned in the documentation that all signers are required to use a hardware wallet-secured address for their signing address which provides evidence that they are separate, distinct individuals.
23. Is there a robust documented transaction signing policy? Please refer to the Example doc for reference.(%)
As contract changes are controlled by DAO vote, there is no need of a transaction signing policy. The only exception is the pause capability where voters are required to used hardware wallets. That would give a 70%, but since all updates are through DAO vote we will give a combined 90% score.