HashEx was commissioned by the EchelonDAO team to perform an audit of ECHO token smart contracts. The audit was conducted between April 13 and April 16, 2021.
The audited contract is deployed to Binance Smart Chain (BSC) at the address 0x6aaa14929D74b8533343C1A5b6e42443f59b6F6F. The whitepaper is located on the team website.
The purpose of this audit was to achieve the following:
● Identify potential security issues with smart contracts.
● Formally check the logic behind given smart contracts.
Information in this report should be used to understand the risk exposure of smart contracts, and as a guide to improving the security posture of smart contracts by remediating the issues that were identified.
Implements 4 safe math operations without error messages.
Basic ERC20 interface contract.
Interface contract for
Access contract with ownership transfer via acceptance.
Implementation of ERC20 token with burn functionality.
#01 Approval is not decreasing on
burnFrom() function at lines 236–243 has checks of approved amount but doesn’t decrease it after burning. It allows the owner to completely burn the balance of any user with non-zero allowance to the owner. Moreover, transfer of the ownership may extend the coverage of this issue as users must take care of any unspent allowances.
This issue may be fixed by transferring ownership to a contract without the possibility of subsequent transfers.
#02 BEP20 token standard not fully supported: Medium
ECHO token is ERC20 deployed to BSC. It lacks the
getOwner() function required by BEP20 standard.
ransferAnyERC20Token doesn’t support USDT: Medium
transferAnyERC20Token() function is designed to send any accidental ERC20 tokens on the balance of the audited contract. However, it uses a transfer method that relies on correct ERC20 implementation. SomepopulartokenslikeUSDTdonotfullysupporttheERC20tokenstandard (not returning bool from transfer function) and calling this function on these tokens will revert. We recommend using SafeERC20 helper contract from OpenZeppelin for token transfers which will handle such cases.
#04 Multiple burn realisations: Medium
Code from whitepaper contains a public burn function. Deployed contract has a
burn() function with
onlyOwner modifier alongside with
burnFrom(). At the same time
transferFrom() has no checks for zero address for the transfer. 4 different realisations of the burn function make it tricky to introspect the initial idea.
#05 Increase/decrease approval: Medium
decreaseApproval() functions. These functions mitigate frontrun attacks on the approve function if user wants to alter previously approved amount in one transaction.
#06 Minimum supply: Medium
Whitepaper [p.12] declares the minimum supply of 21000 ECHO. No signs of its implementation were found in the audited code.
#07 Whitepaper code: Medium
Whitepaper [ p.18–23] contains APPENDIX-Smart-contracts. This code differs from deployed code.
#08 Low severity issues and recommendations: Low
totalSupply()function doesn’t work as intended. There’s no
burnfunction that transfers tokens to zero address.
- Line 121 contains a hardcoded address. This may lead to a contract malfunction in case of control of this address.
- Line 212 contains an obsolete fallback function with revert.
- Compiler version is not fixed. All the require statements don’t emit error messages.
- Both burn functions should emit events.
- No visibility is specified on mapping balances and allowed. We recommend to explicitly specify visibility for all state variables and functions.
- Inconsistent comments in lines 10–13. ‘Deployed to’ address differs from actual contract. ‘Total supply: 2100000’ is not a constant for the burnable token.
Reviewed contract is deployed at 0x6aaa14929D74b8533343C1A5b6e42443f59b6F6F in BSC. The audited contract is an outdated version of ERC20 token.
One high severity issue was found regarding approvals on the owner’s address. If a user approves an arbitrary amount of his tokens to the owner’s address, the owner can burn all of the user’s tokens. Moreover, if the user approves tokens to an arbitrary address and later this address becomes the token owner, the new owner can burn all user’s tokens.
Audit includes recommendations on the code improving and preventing potential attacks.