CertiK reviewed Mashida (mashida Token) on 12 Jan 2023: 16 findings, 3 critical; 13 marked fixed, 2 acknowledged, 1 open.
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 | 3 |
| High | 0 | 2 | 0 |
| Medium | 0 | 0 | 1 |
| Low | 1 | 0 | 9 |
According to the function's meaning of `transferFrom`, `_allowances [sender] [_msgSender()]` should be reduced rather than increased.
In the code of the fixed version(https://github.com/mashidatoken/Token-Contract/commit/3a371f428810101fb6f796866b5ee4a3e5d7eb9a), the “_transferToken” function has 2 logic issues. ```solidity=190 function _transferToken(address sender, address recipient, uint256 amount) internal returns (bool) { _transfer(sender, recipient, amount); uint256 amountReceived = amount; _transfer(sender, recipient, amount); _balances[recipient] = _balances[recipient].add(amountReceived); emit Transfer(sender, recipient, amount); return true; } ``` 1. The "_transferToken" function calls the "_transfer" function twice, which will cause the `sender` to transfer the token to the `recipient` twice. 2. According to 203 lines of code, the token of the `amountReceived` amount will be added to the `recipient`, so the recipient can obtain more tokens of the `amountReceived` amount after calling this function.
The `_transfer` function is responsible for transferring tokens between addresses. The contract takes some residue in every transfer depending on the transfer amount. Some of the addresses are excluded from this, such as `owner, contract address, and DEAD` in the constructor as below: ```solidity _excludedResidue[owner()] = true; _excludedResidue[address(this)] = true; _excludedResidue[DEAD] = true; ``` The `_transfer` function checks whether the user is in an excluded address as below: ```solidity if (!_excludedResidue[sender]){ unchecked { _balances[sender] = senderBalance - amount + takeRes(amount); } } else { unchecked { _balances[sender] = senderBalance - amount; } } ``` Because none of the users are in the `_excludedResidue,` the code flow will follow the if condition. In this situation contract will call the `takeRes` function, which is like the below: ```solidity function takeRes (uint256 amount_) private returns(uint256){ uint256 res = _residue.mul(amount_).div(_leaves); _balances[address(this)] = _balances[address(this)].add(res); return amount_.sub(amount_.sub(res)); } ``` If the amount is higher than the `_leaves` values, this function will increase the contract token balance and then return a value bigger than 1. The below line will increase user balance according to the return value from the `takeRes` function. ```solidity _balances[sender] = senderBalance - amount + takeRes(amount); ```
The linked code transfers the amount of "amountRes" from the "sender" to "msg.sender". It's unclear what's the purpose of such behavior. ```sol if(!_excludedResidue[sender]) _transfer(sender, _msgSender(), amountRes); ```
There should always be events emitted in the sensitive functions that are controlled by centralization roles.
The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.
The function `takeRes` is responsible for taking residue in each transfer. The return value of this function is hard to understand because it is a simplified version of the expression ```solidity amount_ - (amount_ - res) ``` Which is equal to `res`. This mathematical expression, while correct, is not immediately apparent in terms of what it represents or what the function is doing.
```solidity=208 uint256 public _leaves = 1452345000; ``` - `_leaves` should be declared `constant`. --- ```solidity=209 address public _ownAddress; ``` - `_ownAddress` should be declared `constant`.
The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assume their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=237 IRouter public _router; ``` - The contract `Mashida` interacts with third party contract with `IRouter` interface via `_router`.
The `SafeMath` library is used unnecessarily. With Solidity compiler versions 0.8.0 or newer, arithmetic operations will automatically revert in case of integer overflow or underflow. ```solidity=175 library SafeMath { ``` - An implementation of `SafeMath` library is found. --- ```solidity=202 using SafeMath for uint256; ``` - `SafeMath` library is used for `uint256` type in `Mashida` contract. ```solidity=288 _allowances[sender][_msgSender()] = _allowances[sender][_msgSender()].sub(amount, "Insufficient allowance."); ``` - `SafeMath.sub` is called in `transferFrom` function of `Mashida` contract. *Note: Only a sample of 2 `SafeMath` library usage in this contract (out of 26) are shown above.*
One or more state variables are never used in the codebase. Variable `ZERO` in `Mashida` is never used in `MashidaNoTax`. ```solidity=218 address constant ZERO = address(0); ``` ```solidity=195 contract Mashida is ``` --- Variable `FACTORY` in `Mashida` is never used in `MashidaNoTax`. ```solidity=226 address constant FACTORY = 0xB7926C0430Afb07AA7DEfDE6DA862aE0Bde767bc; //pancakefactory testnet ``` ```solidity=195 contract Mashida is ```
The linked magic number is hardcoded in the codebase.
The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.
The report names a repository or files. Open the report to see its scope.
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