As of 3 Nov 2026, IBS has 2 audit reports by 2 security firms on Trustblock; the latest is by CertiK, dated 30 May 2024. Those reports list no open critical findings. It also holds 2 deployed contracts on 2 chains.
Record last updated . It holds audits, findings and contracts up to Nov 2026, and incidents up to Oct 2026. Trustblock does not review code.
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| IBStoken - Audit | Security firm: CertiK | Date: | Scope: 1 address on Polygon (POS) | No open critical findings | Open · skynet.certik.com |
| IBStoken | Security firm: Cyberscope | Date: | Scope: 1 address on BNB Chain | No open critical findings | Open · IPFS |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 2 | 0 |
| Medium | 0 | 1 | 0 |
| Low | 8 | 2 | 0 |
In the contract `Pausable` the role `owner` has authority over the functions shown in the diagram below. Any compromise to the `owner` account may allow the hacker to take advantage of this authority and pause/unpause token transfers. 
Open the reportAll of the IBSTokens are sent to the contract owner which is an externally-owned account (EOA) address on deployment. This is a centralization risk because the deployer or the owner(s) of the EOAs can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.
Open the reportThe blacklist feature is designed to prevent the blacklisted users from transferring the `IBSToken` to others by validating the following **require** statement: ```solidity=145 function transferFrom(address _from, address _to, uint256 _value) public returns (bool) { require(tokenBlacklist[msg.sender] == false); ``` 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.
Open the reportThe data type of the decimals state variable should be `uint8` to adhere to the EIP-20 standard. Currently, some smart contracts interacting with this ERC-20 token will result in a failure. Reference: [Specification of the `decimals()` Method](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md#decimals)
Open the reportThe change of `_owner` by function `transferOwnership()` overrides the previously set `_owner` with the new one without guaranteeing the new `_owner` is able to actuate transactions on-chain.
Open the report| Address | Chain | Source code |
|---|---|---|
| 0x82cb…81000x82cb0ec6a31bc92e9483c08fdcbe2e6f3cc28100 | Chain: Polygon (POS) | Source code: Verified source |
| 0x57d2…f09f0x57d2a45653b329fac354b04cead92c4db71cf09f | Chain: BNB Chain | Source code: Verified source |
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="ibstoken"></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