CertiK reviewed JoJo Token (JOJO-Audit) on 12 Jan 2024: 9 findings, 0 critical; 4 marked fixed, 5 acknowledged.
Report hosted on skynet.certik.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 1 | 1 |
| Medium | 0 | 1 | 3 |
| Low | 0 | 3 | 0 |
All of the JOJO tokens are sent to the externally-owned account (EOA) address 0x54bA2C3A4e937F0452CfFf5ce79A160bE5C3DA51 on deployment. This is a centralization risk because the owner(s) of the EOAs can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.
The contract has a `receive()` function or payable functions, making it able to receive native tokens. However, it does not have a function to withdraw the funds, which can lead to permanently locked tokens within the contract. ```solidity=1381 receive() external payable {} ```
Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=1324 uniswapV2Pair = _uniswapV2Pair; ``` - `_uniswapV2Pair` is not zero-checked before being used. --- ```solidity=1360 _market = market; ``` - `market` is not zero-checked before being used. --- ```solidity=1364 uniswapV2Pair = _uniswapV2Pair; ``` - `_uniswapV2Pair` is not zero-checked before being used.
During the token transfer, if the sender's token balance is exactly equal to the transfer token amount, part of the token will get burnt. ```solidity= amount = amount - (amount / 10 ** 8); ``` This particular line of code effectively reduces the transfer amount by a factor of `1 / 10 ** 8`, resulting in a portion of the token being burnt. It's crucial to clarify the intent behind this approach, as it leads to the sender incurring an asset loss.
A state variable in a derived contract is shadowing a similarly named component in a parent contract. This means that when the derived contract accesses the state variable by its name, it will use the one defined in the derived contract, not the one in the parent contract. This can lead to serious bugs. Variable `_balances` in `JOJO` shadows the variable `_balances` in `ERC20`. ```solidity=1285 mapping(address => uint256) private _balances; ``` ```solidity=115 mapping(address => uint256) private _balances; ``` --- Variable `_allowances` in `JOJO` shadows the variable `_allowances` in `ERC20`. ```solidity=1286 mapping(address => mapping(address => uint256)) private _allowances; ``` ```solidity=117 mapping(address => mapping(address => uint256)) private _allowances; ```
| Address | Chain | Source code |
|---|---|---|
| 0x5f8b…5b1b0x5f8bb709b4f3aa53860595e6df91be9833705b1b | Chain: BNB Chain | Source code: Verified source |
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us