MechaChain ERC20 & Vesting contracts

[thibautvdu]

Audit request

Project : https://mechachain.io We would like to get our smart contracts audited. They translate our tokenomic and vesting/locking commitments regarding the advisors, founders, dev team, etc. as well as the vesting for the presale.

Mechanium.sol

standard ERC20 inheriting openzeppelin contract

ChildMechanium.sol

bridged counterpart on polygon

MechaniumGrowthVestingWallet.sol

A wallet used for the marketing and business development of the project by the MechaChain team, with a vesting as follow : 40% of initial unlock, then 15% every 180 days

Inherits MechaniumVestingWallet.sol

MechaniumDevDistribution.sol, MechaniumAdvisorsDistribution.sol

Allocation smart contracts with a vesting per allocation and a cliff period. Allows to allocate tokens several times to the same address and to have separate schedules for each allocation.

Inherits MechaniumTeamDistribution.sol

MechaniumFoundersDistribution.sol

Same as previous, but with a special withdraw function that will be deactivated once the audit confirms the smart contract is secure. This is implemented because we need to deploy this contract before the end of the audit for legal and accountability reasons, in case the contract has security flaws and need migration.

MechaniumPresaleDistribution.sol

Called at the end of our presale to allocate tokens to the participants. There is a cliff period of 6 months that can be shortened by the admin at the end of the public sale. Then 20% are released and a vesting of 20% each month starts. We will distribute the tokens every month, but for transparency and decentralisation anyone can trigger the distribution at anytime.

Inherits MechaniumVesting.sol

Source code

Code

Token contracts

https://github.com/thibautvdu/MechaChain-Smart-Contracts/blob/develop/contracts/Mechanium.sol https://github.com/thibautvdu/MechaChain-Smart-Contracts/blob/develop/contracts_v0.6.6/ChildMechanium.sol

Vesting contracts

https://github.com/thibautvdu/MechaChain-Smart-Contracts/tree/develop/contracts/MechaniumVesting https://github.com/thibautvdu/MechaChain-Smart-Contracts/tree/develop/contracts/MechaniumVestingWallet

Documentation :

https://github.com/thibautvdu/MechaChain-Smart-Contracts/tree/develop/docs

Disclosure policy

Standard disclosure policy.

Contact information (optional)

Contact information : contracts@ethernalhorizons.com

Platform

ERC20 token : Ethereum mainnet ERC20 child token and other contracts : Polygon mainnet

[yuriy77k]

@thibautvdu the audit fee is 874 USDT. You may send USDT (ERC20 or BEP20) to: 0xb9662e592f2f0412be62f0833ca463a9b1aabebb or USDT (TRC20) to: TBzUKbek9AYVBwf91ykh3KY4Ushk95SCiB

The estimated auditing time - 10 days after payment.

[yuriy77k]

MechaChain ERC20 & Vesting Security Audit Report

1. Summary

MechaChain ERC20 & Vesting smart contract security audit report performed by Callisto Security Audit Department

• Project: https://mechachain.io

2. In scope

Commit 2554bee685a7221defcdb7b0b01b615c58178886

• ChildMechanium.sol
• Mechanium.sol
• MechaniumVesting
• MechaniumVestingWallet

2.1 Excluded from audit

• Standard library contracts were excluded from audit:

1. @openzeppelin/contracts/token/ERC20/ERC20.sol
2. @openzeppelin/contracts/utils/math/SafeMath.sol
3. @openzeppelin/contracts/access/AccessControl.sol
4. @openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol
5. @openzeppelin/contracts/utils/Counters.sol
6. @maticnetwork/pos-portal/contracts/child/ChildToken/ChildERC20.sol

• Staking pool contract, that used in the MechaniumPresaleDistribution, was excluded from audit due to lack of source code.

3. Findings

In total, 1 issues were reported, including:

• 0 high severity issues.

• 0 medium severity issues.

• 1 low severity issues.

In total, 4 notes were reported, including:

• 1 notes.

• 3 owner privileges.

No critical security issues were found.

3.1. Known vulnerabilities of ERC-20 token

Severity: low

Description

Lack of transaction handling mechanism issue. WARNING! This is a very common issue, and it already caused millions of dollars in losses for lots of token users! More details here.

Recommendation

Add the following code to the transfer(_to address, ...) function:

require( _to != address(this) );

3.2. Deployer get the DEFAULT_ADMIN_ROLE

Severity: note

Description

In the ChildMechanium contract the DEFAULT_ADMIN_ROLE assign to adminWallet. But in the ChildERC20 contract the DEFAULT_ADMIN_ROLE also assign to the msg.sender. It's mean the deployer will has DEFAULT_ADMIN_ROLE as well.

Recommendation

Deploy contract from adminWallet or remove deployer address from DEFAULT_ADMIN_ROLE adding following code in the constructor:

    _revokeRole(DEFAULT_ADMIN_ROLE, _msgSender());

3.3. Owner privileges

Severity: owner privileges

Description

1. Admin wallet and deployer of ChildMechanium contract have right to setup any role to any address that alow them to mint tokens.
2. Admin of MechaniumPresaleDistribution contract has right to set/change ptePoolAddress and has right to transfer unsold tokens to that address when vesting started.
3. Admin of MechaniumPresaleDistribution contract has right to set/change staking pool address.

4. Security practices

• [x] Open-source contact.
• [ ] The contract should pass a bug bounty after the completion of the security audit.
• [ ] Public testing.
• [ ] Automated anomaly detection systems. - NOT IMPLEMENTED. A simple anomaly detection algorithm is recommended to be implemented to detect behavior that is atypical compared to normal for this contract. For instance, the contract must halt deposits in case a large amount is being withdrawn in a short period of time until the owner or the community of the contract approves further operations.
• [ ] Multisig owner account.
• [ ] Standard ERC20-related issues. - NOT IMPLEMENTED. It is known that every contract can potentially receive an unintended ERC20-token deposit without the ability to reject it even if the contract is not intended to receive or hold tokens. As a result, it is recommended to implement a function that will allow extracting any arbitrary number of tokens from the contract.
• [ ] Crosschain address collisions. ETH, ETC, CLO, etc. It is possible that a transaction can be sent to the address of your contract at another chain (as a result of a user mistake or some software fault). It is recommended that you deploy a "mock contract" that would allow you to withdraw any tokens from that address or prevent any funds deposits. Note that you can reject transactions of native token deposited, but you can not reject the deposits of ERC20 tokens. You can use this source code as a mock contract: extractor contract source code. The address of a new contract deployed using CREATE (0xf0) opcode is assigned following this scheme keccak256(rlp([sender, nonce])). Therefore you need to use the same address that was originally used at the main chain to deploy the mock contract at a transaction with the nonce that matches that on the original chain. Example: If you have deployed your main contract with address 0x010101 at your 2021th transaction then you need to increase your nonce of 0x010101 address to 2020 at the chain where your mock contract will be deployed. Then you can deploy your mock contract with your 2021th transaction, and it will receive the same address as your mainnet contract.

5. Conclusion

The audited smart contract can be deployed. Only low severity issues were found during the audit.

It is recommended to adhere to the security practices described in pt. 4 of this report to ensure the contract's operability and prevent any issues that are not directly related to the code of this smart contract.