mashida Token

CertiKCode version: not recorded (see the report)

CertiK reviewed Mashida (mashida Token) on 12 Jan 2023: 16 findings, 3 critical; 13 marked fixed, 2 acknowledged, 1 open.

3 critical findings, fixed
Open the reportOpen Mashida’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings16

Statuses are the security firm’s own, from its report.

SeverityOpenAcknowledgedFixed
Critical003
High020
Medium001
Low109
Critical"_allowances" calculation formula errorFixed

According to the function's meaning of `transferFrom`, `_allowances [sender] [_msgSender()]` should be reduced rather than increased.

CriticalUser balance can be increased after calling of `_Fixed

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.

CriticalUser balance can be increased after use of `transFixed

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); ```

MediumConfusing LogicFixed

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); ```

LowMissing Emit EventsFixed

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

LowRedundant Code ComponentsFixed

The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

LowRedundant code in function `takeRes`Fixed

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.

LowState Variable Should Be Declared ConstantFixed

```solidity=208 uint256 public _leaves = 1452345000; ``` - `_leaves` should be declared `constant`. --- ```solidity=209 address public _ownAddress; ``` - `_ownAddress` should be declared `constant`.

LowThird Party DependencyFixed

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`.

LowUnnecessary Use of SafeMathFixed

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.*

Show 3 more
LowUnused State VariableFixed

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 ```

LowUsage of Magic NumberFixed

The linked magic number is hardcoded in the codebase.

LowVariables That Could Be Declared as ImmutableFixed

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.

Contracts in scope

No deployed address is recorded for this audit.

The report names a repository or files. Open the report to see its scope.

Part of Mashida’s security record

Mashida
Audits1 audit by 1 firmLast audit Jan 2023, by CertiK.
Critical findingsNo open critical findingsIn that report, 3 critical findings were reported. Each is marked fixed by the firm that reported it.
Open Mashida’s security record

Security firm

CertiK

1,044 projects reviewed · 1,375 reports · latest May 2025

See CertiK’s audits

Something 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