CertiK reviewed MARBLEX (MBX token-Audit) on 11 Jan 2023: 4 findings, 0 critical; none marked fixed.
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 | 3 | 0 | 0 |
| Medium | 0 | 0 | 0 |
| Low | 1 | 0 | 0 |
In the contract **SystemBToken**, the role **Admin** has authority over the following functions: - `freezeAccount()`/`unfreezeAccount()`: Freeze/Unfreeze an account from transferring tokens. - `addAdmin()`: Add an account as the admin role. The role `Minter` has the authority over the following functions: - `addMinter()`: Add an account as the minter. - `mint()`: Mint tokens to a given address. The role `owner` has the authority to remove an account from the admin role by calling `removeAdmin()`. Any compromise to the aforementioned privileged accounts may allow a hacker to take advantage of this authority and cause unexpected loss to the project.
The minter role of the `SystemBToken` contract can mint an unlimited amount of MBX tokens without the consensus of the community. The concern is the minter role can distribute the token arbitrarily, thus could cause tokenomics issues to the project as a whole.
The `SystemBToken` contract overrides `safeTransferFrom`, which is inherited from `KIP7Token` with the `notFrozen` modifier but missing the `super` keyword during the override. The current codebase will lead both `safeTransferFrom` methods unreachable. ### Proof of Concept We prepare the hardhat test by calling `safeTransferFrom` to show the scenario. Script: ```js= it("Try safe transferFrom", async function () { await token.connect(owner).mint(user1.address, 1000000000); await token.connect(user1).approve(user2.address, 1000000000); await token.connect(user2)["safeTransferFrom(address,address,uint256)"](user1.address, user3.address, 5000000); expect(await token.balanceOf(user3.address)).to.equal(5000000); }); ``` Output: ```text Error: Transaction reverted and Hardhat couldn't infer the reason. at SystemBToken.notFrozen (contracts/SystemBToken.sol:14) ... at SystemBToken.transferFrom (contracts/SystemBToken.sol:42) at processTicksAndRejections (node:internal/process/task_queues:95:5) at runNextTicks (node:internal/process/task_queues:64:3) at listOnTimeout (node:internal/timers:533:9) at processTimers (node:internal/timers:507:7) at HardhatNode._mineBlockWithPendingTxs (node_modules/hardhat/src/internal/hardhat-network/provider/node.ts:1815:23) at HardhatNode.mineBlock (node_modules/hardhat/src/internal/hardhat-network/provider/node.ts:504:16) at EthModule._sendTransactionAndReturnHash (node_modules/hardhat/src/internal/hardhat-network/provider/modules/eth.ts:1522:18) ```
The contract `SystemBToken` provide `transferFrom` and `safeTransferFrom` methods. Both methods allow the caller to transfer `sender`'s funds under the allowance. The concern is the `safeTransferFrom` require **both caller and sender** not to freeze, but `transferFrom` only requires the **sender** not to freeze. If one caller is frozen, he/she can still use `transferFrom` to move the funds.
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