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



byob-token-sc-f3ea4900af8413c325f51ffba014e9cecea9f41c.zip (md5:31e65b20893feb58219ea0158175269a)

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:

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

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

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.

Graph 1. The distribution of vulnerabilities after the first review.

Severity Definitions

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

No High severity issues were found.

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.

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



Hacken Disclaimer

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



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store