HACKEN SMART CONTRACT CODE REVIEW AND SECURITY ANALYSIS REPORT FOR $BYOB
Name: Smart Contract Code Review and Security Analysis Report for DataMynt-Initial Audit
Approved by: Andrew Matiukhin | CTO Hacken OU
Type: ERC20 Token with Vesting, Vesting Schedule
Platform: Ethereum / Solidity
Methods: Architecture Review, Functional Testing, Computer-Aided Verification, Manual Review
Zip archive: byob-token-sc-f3ea4900af8413c325f51ffba014e9cecea9f41c.zip (md5:31e65b20893feb58219ea0158175269a)
Timeline: 29 JUNE 2021–2 JULY 2021
Changelog: 2 JULY 2021 — INITIAL AUDIT
Introduction
Hacken OÜ (Consultant) was contracted by DataMynt (Customer) to conduct a Smart Contract Code Review and Security Analysis. This report presents the findings of the security assessment of Customer’s smart contract and its code review conducted between June 29th, 2021 — July 2nd, 2021.
Scope
The scope of the project is the smart contracts in Zip archive:
byob-token-sc-f3ea4900af8413c325f51ffba014e9cecea9f41c.zip (md5:31e65b20893feb58219ea0158175269a)
Scope:
token/BYOBToken.sol md5: 15352690935d0e826b99850f40a5229b vesting/FrequencyHelper.sol md5: 08987bf72e8e8582d27c1d5afe219e13 vesting/VestingSchedule.sol md5: 139153ef5710263e9f837dd9c7644732 vesting/VestingScheduleBase.sol md5:777cec7b919737b1d2ddc1676a5ffdcc
We have scanned these smart contracts for commonly known and more specific vulnerabilities. Here are some of the commonly known vulnerabilities that are considered:
Category
Code review
Check Item
▪ Reentrancy
▪ Ownership Takeover
▪ Timestamp Dependence
▪ Gas Limit and Loops
▪ DoS with (Unexpected) Throw
▪ DoS with Block Gas Limit
▪ Transaction-Ordering Dependence
▪ Style guide violation
▪ Costly Loop
▪ ERC20 API violation
▪ Unchecked external call
▪ Unchecked math
▪ Unsafe type inference
▪ Implicit visibility level
▪ Deployment Consistency
▪ Repository Consistency
▪ Data Consistency
Category
Functional review
Check Item
▪ Business Logics Review
▪ Functionality Checks
▪ Access Control & Authorization
▪ Escrow manipulation
▪ Token Supply manipulation
▪ Asset’s integrity
▪ User Balances manipulation
▪ Kill-Switch Mechanism
▪ Operation Trails & Event Generation
Executive Summary
According to the assessment, the Customer’s smart contracts are poor-secured.
Our team performed an analysis of code functionality, manual audit, and automated checks with Mythril and Slither. All issues found during automated analysis were manually reviewed, and important vulnerabilities are presented in the Audit overview section. All found issues can be found in the Audit overview section.
Security engineers found 2 medium, 2 low and 2 informational issues during the first review.
Severity Definitions
Risk Level and Descriptions
▪ Critical: Critical vulnerabilities are usually straightforward to exploit and can lead to assets loss or data manipulations.
▪ High: High-level vulnerabilities are difficult to exploit; however, they also have a significant impact on smart contract execution, e.g., public access to crucial functions
▪ Medium: Medium-level vulnerabilities are important to fix; however, they can’t lead to assets loss or data manipulations.
▪ Low: Low-level vulnerabilities are mostly related to outdated, unused, etc. code snippets that can’t have a significant impact on execution.
▪ Lowest / Code Style / Best Practice: Lowest-level vulnerabilities, code style violations, and info statements can’t affect smart contract execution and can be ignored
Audit overview
Critical
No Critical severity issues were found.
High
No High severity issues were found.
Medium
1. Vulnerability: Token vesting centralization
Owner has powers to vest/unvest entire token balance of any address at any time.
Recommendation: depending on your tokenomics please consider adding some conditions and explain those in the whitepaper/docs.
Lines: BYOBToken#39–56
2. Vulnerability: Vesting schedule centralization
Owner has a lot of powers to control the entire VestingSchedule contract without any community decision.
Recommendation: please consider giving ownership to the Governance or, at least, Timelock to allow users to decide and react to changes.
Low
1. Vulnerability: Incorrect modifier
If a modifier does not execute _ or revert, the execution of the function will return the default value, which can be misleading for the caller.
Recommendation: Please consider adding a revert in the else-case
Lines: VestingSchedule#229–233
2. Vulnerability: Dependence on predictable environment variable
The block.timestamp environment variable is used to determine a control flow decision. Note that the values of variables like coinbase, gaslimit, block number and timestamp are predictable and can be manipulated by a malicious miner. Also, keep in mind that attackers know hashes of earlier blocks. Don’t use any of those environment variables as sources of randomness and be aware that the use of these variables introduces a certain level of trust into miners.
Recommendation: please consider relying on the blockNumber instead of timestamp
Lines: VestingSchedule#229–233
Lowest / Code style / Best Practice
1. Vulnerability: State variables that could be declared constant.
Constant state variables should be declared constant to save gas.
Recommendation: Add the constant attributes to state variables that never change.
Lines: BYOBToken#9–10
2. Vulnerability: Boolean equality.
Boolean constants can be used directly and do not need to be compared to true or false.
Recommendation: Remove the equality to the boolean constant.
Lines: BYOBToken#30
Lines: BYOBToken#43
Lines: BYOBToken#51
Conclusion
Smart contracts within the scope were manually reviewed and analyzed with static analysis tools.
Audit report contains all found security vulnerabilities and other issues in the reviewed code.
Security engineers found 2 medium, 2 low and 2 informational issues during the first review.
Disclaimers
Hacken Disclaimer
The smart contracts given for audit have been analyzed in accordance with the best industry practices at the date of this report, in relation to cybersecurity vulnerabilities and issues in smart contract source code, the details of which are disclosed in this report (Source Code); the Source Code compilation, deployment, and functionality (performing the intended functions).
The audit makes no statements or warranties on the security of the code. It also cannot be considered as a sufficient assessment regarding the utility and safety of the code, bug-free status or any other statements of the contract. While we have done our best in conducting the analysis and producing this report, it is important to note that you should not rely on this report only - we recommend proceeding with several independent audits and a public bug bounty program to ensure the security of smart contracts.
Technical Disclaimer
Smart contracts are deployed and executed on the blockchain platform. The platform, its programming language, and other software related to the smart contract can have vulnerabilities that can lead to hacks. Thus, the audit can’t guarantee the explicit security of the audited smart contracts.
