CertiK reviewed IDRX on 7 Jul 2023: 10 findings, 0 critical; 6 marked fixed, 4 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 | 4 | 1 |
| Medium | 0 | 0 | 2 |
| Low | 0 | 0 | 3 |
The blacklist feature is designed to prevent the blacklisted users from transferring the `IDRX` to others by validating the following **require** statement in the `_beforeTokenTransfer()` of `IDRX` contract: ```solidity=106 require(!isBlackListed[msg.sender], "Blacklist: account is blacklisted"); ``` The **require** statement prohibits the blacklisted users from calling `transfer()` and `transferFrom()` to move their funds by requiring the `msg.sender` not blacklisted. However, this feature can be bypassed by using a combination of the `approve()`/`increaseAllowance()` and `transferFrom()` functions. The blacklisted user could approve another account to transfer his tokens on his behalf.
There are no upper boundaries for `_burnBridgeFee` and `_mintBridgeFee` which are used to calculate fees that would be charged in the bridge. It is possible to set the total fee rate up to any arbitrary amount. ```solidity=138 function setPlatformFeeInfo( address _platformFeeRecipient, uint64 _burnBridgeFee, uint64 _mintBridgeFee ) external onlyRole(MINTER_ROLE) { burnBridgeFee = _burnBridgeFee; mintBridgeFee = _mintBridgeFee; ... } ```
If the zero address is blacklisted, calls to internal ERC20 functions `_mint()` and `_burn()` will fail because the `beforeTokenTransfer()` or `afterTokenTransfer()` hook disallow transferring to/from the zero address.
The `_bridgeNonce` value is incremented in the `burnBridge()` function, but not in the `mintBridge()` function. The `_bridgeNonce` is supposed to represent the unique count of transactions that move funds between bridges, but this count is currently only updated in the `burnBridge()` function and not when minting through the bridge.
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=145 platformFeeRecipient = _platformFeeRecipient; ``` - `_platformFeeRecipient` is not zero-checked before being used.
The contract uses the console contract from Hardhat, which is meant to be used for testing purposes.
| Address | Chain | Source code |
|---|---|---|
| 0x20fa…bbd00x20fad183dc35f4ae0d1d125ae2f3c4c43a53bbd0 | Chain: Polygon (POS) | Source code: Verified source |
| 0x649a…42cc0x649a2da7b28e0d54c13d5eff95d3a660652742cc | Chain: Polygon (POS) | 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