We released a brand new security service
Check it out
Summary
Vidma is pleased to present this audit report outlining our assessment of code, smart contracts, and other important audit insights and suggestions for management, developers, and users.
The audited scope of work includes the MilestoneBased contract, which is a factory for creating Roadmap contracts. The main goal of the Roadmap contract is to preserve the investor's investment and distribute it among the startup. In case the startup fails to comply with the agreement or begins to deceive investors, the investors can retrieve their investments through a DAO (Voting contract). Each roadmap has its own Voting contract, which cannot be changed. Anyone can create a proposal that has at least 2 options. Each parameter describes the contracts that need to be called and encodes the function signature with the parameters that will be used for the call. Voting decides which proposal option should be executed based on the votes of the voters. Voters are granted voting rights through the RoadmapStaking contract. They need to stake the selected ERC20 token to get the voting power, which is equivalent to the amount of tokens staked (1:1 ratio). The voting logic is implemented in the VotingPowerCalculator contract, which allows changing it without affecting the voting contract, as all contracts implement the TransparentUpgradeableProxy pattern from the OpenZeppelin library.
During the audit process, the Vidma team found several issues. A detailed summary and the current state are displayed in the table below.
After evaluating the findings in this report and the final state after fixes, the Vidma auditors can state that the contracts are fully operational and secure. Under the given circumstances, we set the following risk level:
.svg)
High Confidence
To set the codebase quality mark, our auditors are evaluating the initial commit given for the scope of the audit and the last commit with the fixes. This approach helps us adequately and sequentially evaluate the quality of the code. Code style, optimization of the contracts, the number of issues, and risk level of the issues are all taken into consideration. The Vidma team has developed a transparent evaluation codebase quality system presented below.
Severity of the issue
Issue severity
Total found
Resolved
Critical
1
10
High
0.8
7
Medium
0.5
5
Low
0.2
0.5
Informational
0
0.1
Please note that the points are deducted out of 100 for each and every issue on the list of findings (according to the current status of the issue). Issues marked as “not valid” are not subject to point deduction.
Codebase quality:
99.80
Evaluating the initial commit and the last commit with the fixes, Vidma audit team set the following codebase quality mark.
Score
Based on the overall result of the audit and the state of the final reviewed commit, the Vidma audit team grants the following score:
100
In addition to manual check and static analysis, the auditing team has conducted a number of integrated autotests to ensure the given codebase has an adequate performance and security level. The test results and coverage can be found in the accompanying section of this audit report.
Please be aware that this audit does not certify the definitive reliability and security level of the contract. This document describes all vulnerabilities, typos, performance issues, and security issues found by the Vidma audit team.
If the code is still under development, we highly recommend running one more audit once the code is finalized.
.svg)
Scope of work
milestoneBased is the first company to leverage a blockchain DAO and escrow smart contract capabilities, in an automated governance and milestone achievement management platform.
Within the scope of this audit, two independent auditors thoroughly investigated the given codebase and analyzed the overall security and performance of the smart contracts.
The audit was conducted from March 15, 2023 to April 14, 2023. The outcome is disclosed in this document.
The final review of the fixes was finished on April 27, 2023.
The scope of work for the given audit consists of the following contracts:
- EntityAccessControler;
- MilestoneBased;
- Refund;
- Roadmap;
- RoadmapStaking;
- TransparentProxyAdmin;
- Voting;
- VotingPowerCalculator;
- SingSignEntityStrategy.
The source code was taken from the following source:
https://bitbucket.org/applicature/milestonebased.contracts
Initial commit submitted for the audit:
4f559c59405f8727b2a6cdc291ad411c259e5bcd
Last commit reviewed by the auditing team:
58763f6bb93b2e78078a8605b1bb8b36ec63d3a4
As a reference to the contracts logic, business concept, and the expected behavior of the codebase, the milestoneBased team has provided the following documentation:
Workflow of the auditing process
Vidma audit team uses the most sophisticated and contemporary methods and well-developed techniques to ensure contracts are free of vulnerabilities and security risks. The overall workflow consists of the following phases:
Phase 1: The research phase
Research
After the Audit kick-off, our security team conducts research on the contract’s logic and expected behavior of the audited contract.
Documentation reading
Vidma auditors do a deep dive into your tech documentation with the aim of discovering all the behavior patterns of your codebase and analyzing the potential audit and testing scenarios.
The outcome
At this point, the Vidma auditors are ready to kick off the process. We set the auditing strategies and methods and are prepared to conduct the first audit part.
Phase 2: Manual part of the audit
Manual check
During the manual phase of the audit, the Vidma team manually looks through the code in order to find any security issues, typos, or discrepancies with the logic of the contract. The initial commit as stated in the agreement is taken into consideration.
Static analysis check
Static analysis tools are used to find any other vulnerabilities in smart contracts that were missed after a manual check.
The outcome
An interim report with the list of issues.
Phase 3: Testing part of the audit
Integration tests
Within the testing part, Vidma auditors run integration tests using the Truffle or Hardhat testing framework. The test coverage and the test results are inserted in the accompanying section of this audit report.
The outcome
Second interim report with the list of new issues found during the testing part of the audit process.
Structure and organization of the findings
For simplicity in reviewing the findings in this report, Vidma auditors classify the findings in accordance with the severity level of the issues. (from most critical to least critical).
All issues are marked as “Resolved” or “Unresolved”, depending on if they have been fixed by project team or not. The issues with “Not Relevant” status are left on the list of findings but are not eligible for the score points deduction.
The latest commit with the fixes reviewed by the auditors is indicated in the “Scope of Work” section of the report.
The Vidma team always provides a detailed description of the issues and recommendations on how to fix them.
Classification of found issues is graded according to 6 levels of severity described below:
Critical
The issue affects the contract in such a way that funds may be lost or allocated incorrectly, or the issue could result in a significant loss.
Example: Underflow/overflow, precisions, locked funds.
High
The issue significantly affects the ability of the contract to compile or operate. These are potential security or operational issues.
Example: Compilation errors, pausing/unpausing of some functionality, a random value, recursion, the logic that can use all gas from block (too many iterations in the loop), no limitations for locking period, cooldown, arithmetic errors which can cause underflow, etc.
Medium
The issue slightly impacts the contract’s ability to operate by slightly hindering its intended behavior.
Example: Absence of emergency withdrawal of funds, using assert for parameter sanitization.
Low
The issue doesn’t contain operational or security risks, but are more related to optimization of the codebase.
Example: Unused variables, inappropriate function visibility (public instead of external), useless importing of SCs, misuse or disuse of constant and immutable, absent indexing of parameters in events, absent events to track important state changes, absence of getters for important variables, usage of string as a key instead of a hash, etc.
Informational
Are classified as every point that increases onboarding time and code reading, as well as the issues which have no impact on the contract’s ability to operate.
Example: Code style, NatSpec, typos, license, refactoring, naming convention (or unclear naming), layout order, functions order, lack of any type of documentation.
Manual Report
Optimization by ternary operator
.svg)
Low ML – 01 | Invalid
There are few functions that can be optimized to return the result of the ternary operator that will decrease using of if-else branching:
Roadmap.sol
could be optimized to:
Voting.sol
could be optimized to:
Recommendation:
Consider using ternary operators. It can decrease contract size (Roadmap: -0.004KiB, Voting: -0.006KiB).
Simplification of boolean value getters
Low ML – 02 | Resolved
There are a few functions that could be simplified to get boolean values directly without if-else branching:
EntityAccessControler.sol
could be optimized to:
Refund.sol
could be optimized to:
Recommendation:
Consider removing if-else branching to get similar values. It also decreases contract size (Refund: -0.039KiB, EntityAccessControler: -0.013KiB for every dependent contract: Refund, Roadmap, RoadmapStaking, Voting).
Missed NatSpec docs
.svg)
Informational MI – 01 | Resolved
There are instances that need to be covered by Natspec:
- EntityAccessControler.sol (L11): Smart Contract description;
- Voting.sol (L345): getActiveVotedProposalsByVoter() function description;
- TransparentProxyAdmin.sol (L6): Smart Contract description.
Recommendation:
Add NatSpec to contracts and their functions using Solidity documentation for NatSpec.
Typos in the codebase
Informational MI – 02 | Resolved
There are some typos in the contract's code and NatSpec that should be fixed:
- EntityAccessControler.sol (L12): EntityAccessControler -> EntityAccessController and the filename;
- EntityAccessControler.sol (L19): EnitityFactory -> EntityFactory;
- EntityAccessControler.sol (L30): Enitity -> Entity;
- EntityAccessControler.sol (L39): __EntityAccessControler_init -> __EntityAccessController_init;
- EntityAccessControler.sol (L75-76): EntityFactroy -> EntityFactory;
- IMilestoneBased.sol (L40): evoiding -> avoiding;
- IMilestoneBased.sol (L109): cotnracts -> contracts;
- MilestoneBased.sol (L161): cotnracts -> contracts;
- IRefund.sol (L21): seetings -> settings;
- IRefund.sol (L24): _fudningToken -> _fundingToken;
- IRefund.sol (L27): _mBaddres -> _mBAddress;
- IRefund.sol (L33): Trnafer -> Transfer;
- IRefund.sol (L38,41): Tranfer -> Transfer;
- IRefund.sol (L41): contrcat -> contract;
- Refund.sol (L74,80): _mBaddres -> _mBAddress;
- Refund.sol (L116,121): investmens -> investments;
- Refund.sol (L132): enitity -> entity;
- Roadmap.sol (L123): owenr -> owner;
- Roadmap.sol (L123): prrove -> approve;
- IRoadmapStaking.sol (L26): cotnract -> contract;
- IRoadmapStaking.sol (L34): emtity -> entity;
- RoadmapStaking.sol (L126): NotEnoughBalnce -> NotEnoughBalance;
- IVotingPowerSupplier.sol (L11,12): votign -> voting;
- IVoting.sol (L26): alredy -> already;
- IVoting.sol (L99,100,101,102): cancelled -> canceled;
- IVoting.sol (L103): ProposalVoteCancelled -> ProposalVoteCanceled;
- IVoting.sol (L157): exeecution -> execution;
- IVoting.sol (L204): choosed -> chosen;
- IVoting.sol (L490): ProposalVoteCancelled -> ProposalVoteCanceled.
Recommendation:
Consider fixing typos. Also don't forget to change dependencies in other contracts for imports/function calls.
Event arguments code style
Informational MI – 03 | Resolved
Event arguments do not require underscores in their names like function arguments. It is often used to avoid naming collisions in functions.
Recommendation:
Consider removing underscore for event arguments:
- IRoadmap.sol (L120,126): _ipfsHash -> ipfsHash.
Test Results
To verify the security of contracts and the performance, a number of integration tests were carried out using the Hardhat testing framework.
In this section, we provide both tests written by milestoneBased and tests written by Vidma auditors.
milestoneBased Coverage – 93.55%
Vidma Coverage – 98.69%
Industry Standard – 95%
It is important to note that Vidma auditors do not modify, edit or add tests to the existing tests provided in the milestoneBased repository. We write totally separate tests with code coverage of a minimum of 95% to meet the industry standards.
Tests written by Xend and Wicrypt
Test Coverage
Test Results
Tests written by Vidma auditors
Test Coverage
Test Results
We are delighted to have a chance to work with the milestoneBased team and contribute to your company's success by reviewing and certifying the security of your smart contracts.
The statements made in this document should be interpreted neither as investment or legal advice, nor should its authors be held accountable for decisions made based on this document.
Vidma is a security audit company helping crypto companies ensure their code and products operate safely and as intended, enabling founders to sleep soundly at night. We specialize in auditing DeFi protocols, layer one protocols, and marketplace solutions. Our team consists of experienced and internationally trained specialists. Our company is based in Ukraine, known for its strong engineering, cryptography, and cybersecurity culture.
4
.svg)
