As of 3 Nov 2026, Mashida has 1 audit report on Trustblock, by CertiK, dated 12 Jan 2023. That report lists no open critical findings.
Record last updated . It holds audits and findings, contracts and incidents up to Nov 2026. Trustblock does not review code.
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| mashida Token | Security firm: CertiK | Date: | Scope: Not recorded (see the report) | 3 critical findings, fixed | Open · skynet.certik.com |
Statuses are the security firm’s own, from each 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.
Open the reportIn 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.
Open the reportThe `_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); ```
Open the reportThe 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); ```
Open the reportThere should always be events emitted in the sensitive functions that are controlled by centralization roles.
Open the reportThe linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.
Open the reportThe 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.
Open the report```solidity=208 uint256 public _leaves = 1452345000; ``` - `_leaves` should be declared `constant`. --- ```solidity=209 address public _ownAddress; ``` - `_ownAddress` should be declared `constant`.
Open the reportThe 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`.
Open the reportThe `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.*
Open the reportOne 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 ```
Open the reportThe linked magic number is hardcoded in the codebase.
Open the reportThe 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.
Open the reportThe reports name a repository or files. Open a report to see its scope.
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="mashida"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
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