This document is a security audit report performed by RideSolo, where Jointer Token v2 has been reviewed.
- Constant.sol github commit hash 243aaced519b2b852f568b87968db39a72c8dcf3
- ERC20.sol github commit hash 243aaced519b2b852f568b87968db39a72c8dcf3.
- Ownable.sol github commit hash 243aaced519b2b852f568b87968db39a72c8dcf3.
- SafeMath.sol github commit hash 243aaced519b2b852f568b87968db39a72c8dcf3.
- StandardToken.sol github commit hash 243aaced519b2b852f568b87968db39a72c8dcf3.
- Token.sol github commit hash 75a7b807a9d7d3f4d8bb4ef66080812fd27b5e16.
- TokenUtil.sol github commit hash 75a7b807a9d7d3f4d8bb4ef66080812fd27b5e16.
- WhiteList.sol github commit hash 243aaced519b2b852f568b87968db39a72c8dcf3.
** 9 issues** were reported including:
- 1 high severity issues.
- 3 low severity issues.
- 4 owner privileges.
- 1 note.
- When force swap is used the owner can choose any amount to be sent to the user address whithout any relation with the user balance while burning all the user balance.
- No cap is set for the system when minting. If the system addresses mint more than expected, the users can risk big losses.
- Owner can change tokens hold back days without permission from the users.
- Owner can change token per eth price at any moment, please also note that the owner can change the token price but the storage variable is not further used in the contract.
The implemented approve function is not ERC20 compliant any dapp, exchange or dex that were deployed previously or in the future to handle ERC20 approval will not work with this implementation of ERC20 token.
Even the approval event is not compliant since it send 4 parameters, meaning that a dapp will not detect the approval event correclty.
Following the whitepaper definition "The token JNTR/ETN has a 10 year maturity date", however the maturity date in the contract is set to one year(a setter exist and can be used to update the date but the contract should reflect the whitepaper, in case if the owner forget to call that function after a year the transfers will stop).
When owner or system address allow or block a whitelisted address from receiving or sending tokens, they have to block or allow all the addresses that were added through addMoreWallets by a whitlisted address.
Most tokens implement the locking mechanism to block a single address in case of stolen fund, however here a single address cannot be locked.
Security check is always set to true and can be removed from checkBeforeTransfer. If the intention of the developers was to set failsafe switch in case of issues with authorisation logic, they should implement a setter function for that variable.
Lack of transaction handling mechanism issue. WARNING! This is a very common issue and it already caused millions of dollars losses for lots of token users! More details here
Multiple issues have been raised and should be fixed before deployement.