Quantum Audit Logo

Is IBS Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

IBS IBS
0x255e…a7cd
BNB Chain
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked 18d ago 2 audits on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The audit of the Token contract reveals a critical risk profile primarily due to the implications of renounced ownership. While the contract utilizes robust OpenZeppelin libraries for ERC20, access control, and ownership management, the reported renounced ownership renders all owner-controlled functions immutable. This leads to permanent rigidity in critical parameters like tax rates and treasury addresses, and makes the initial unlimited minting power unrevocable. Several high-severity issues related to permanent minting and potential misconfiguration are identified, alongside a medium-severity issue regarding an unclear tax function and an informational finding on whitelist logic. The project's security relies heavily on the correctness of its initial deployment parameters.

1 Critical2 High1 Medium1 Informational
Volume 24h
$1.32M
Liquidity
$15.14M
Price
$12.2300
Token Age
3mo
Top 10 Holders
96.4%

Security Findings

1 Crit2 High1 Med1 Info
Critical

Immutability of Critical Parameters after Ownership Renouncement

C-01The contract utilizes `Ownable2Step` and has numerous critical functions protected by the `onlyOwner` modifier (e.g., `setBuyRates`, `setTreasuryAddress`, `setLongGovernanceList`). If ownership is renounced, as indicated by the provided metadata, all these functions become permanently unusable. This means that critical parameters like tax rates (`longGovernanceRatio`, `shortGovernanceRatio`), treasury addresses (`treasury`, `taxTreasury`), and the various governance/whitelist mappings become immutable after deployment. While this prevents a malicious owner from changing parameters, it introduces a severe risk of rigidity, preventing any future adjustments, bug fixes, or adaptation to changi…
IssueThe contract utilizes `Ownable2Step` and has numerous critical functions protected by the `onlyOwner` modifier (e.g., `setBuyRates`, `setTreasuryAddress`, `setLongGovernanceList`). If ownership is renounced, as indicated by the provided metadata, all these functions become permanently unusable. This means that critical parameters like tax rates (`longGovernanceRatio`, `shortGovernanceRatio`), treasury addresses (`treasury`, `taxTreasury`), and the various governance/whitelist mappings become immutable after deployment. While this prevents a malicious owner from changing parameters, it introduces a severe risk of rigidity, preventing any future adjustments, bug fixes, or adaptation to changi…
FixIf immutability is the desired state, ensure all initial parameters are thoroughly audited, tested, and confirmed to be correct before deployment and renouncement. If flexibility is needed, ownership should not be renounced, or a more decentralized governance mechanism (e.g., a DAO with a timelock) should be implemented to manage these parameters. Clearly document the implications of renounced ownership for all stakeholders.
StatusUnresolved
High

Permanent Unlimited Minting Power

H-01The `MINTER_ROLE` is granted to two external addresses (`rbs` and `minter_`) in the constructor. The `mint` function, callable by anyone with `MINTER_ROLE`, allows for the creation of an arbitrary amount of new tokens. If ownership is renounced, the `grantTaxer` and `revokeTaxer` functions (which manage roles) become unusable. This means the initial `MINTER_ROLE` holders retain permanent, unlimited power to mint tokens, and this power cannot be revoked. This poses a significant risk of token inflation, value dilution, and potential for malicious actors to exploit this capability.
IssueThe `MINTER_ROLE` is granted to two external addresses (`rbs` and `minter_`) in the constructor. The `mint` function, callable by anyone with `MINTER_ROLE`, allows for the creation of an arbitrary amount of new tokens. If ownership is renounced, the `grantTaxer` and `revokeTaxer` functions (which manage roles) become unusable. This means the initial `MINTER_ROLE` holders retain permanent, unlimited power to mint tokens, and this power cannot be revoked. This poses a significant risk of token inflation, value dilution, and potential for malicious actors to exploit this capability.
FixImplement a mechanism to revoke or limit minting power, even after ownership renouncement, if such flexibility is desired. Consider using a multi-signature wallet for the `MINTER_ROLE` to require multiple approvals for minting operations. If minting is intended to be limited, enforce a maximum total supply or a defined minting schedule within the contract logic.
StatusUnresolved
High

Permanent Zero Treasury if Misconfigured

H-02The `treasury` address, which is the recipient of collected taxes from `_collectGovernance`, is set only during the constructor via the `treasury_` argument. If ownership is renounced, the `setTreasuryAddress` function becomes unusable. This means if `treasury_` was initialized to `address(0)` during deployment, or to an incorrect/uncontrolled address, no taxes will ever be collected by the `_collectGovernance` function, leading to a permanent loss of intended revenue or funds being sent to an inaccessible address. This represents a critical operational flaw if not configured correctly at deployment.
IssueThe `treasury` address, which is the recipient of collected taxes from `_collectGovernance`, is set only during the constructor via the `treasury_` argument. If ownership is renounced, the `setTreasuryAddress` function becomes unusable. This means if `treasury_` was initialized to `address(0)` during deployment, or to an incorrect/uncontrolled address, no taxes will ever be collected by the `_collectGovernance` function, leading to a permanent loss of intended revenue or funds being sent to an inaccessible address. This represents a critical operational flaw if not configured correctly at deployment.
FixEnsure the `treasury` address is correctly set to a secure and controlled address during deployment. If `address(0)` is intended to disable taxes, this behavior should be explicitly documented and understood by all stakeholders. Consider adding a non-zero address check in the constructor for the `treasury_` parameter if `address(0)` is never a valid target.
StatusUnresolved
Medium

Unclear Purpose of `transferTax` Function

M-01The `transferTax` function, callable by `TAXER_ROLE` holders, allows an account to transfer a percentage of a specified `amount` from `_msgSender()` to `taxTreasury`, based on the `shortGovernanceRatio`. This mechanism is unusual as it is not a tax applied automatically during token transfers, but rather a separate, explicit function call initiated by a `TAXER_ROLE` holder. The intended use case, benefit, and potential for misuse of this function are not clearly defined within the code or comments, which could lead to confusion or unintended operational scenarios.
IssueThe `transferTax` function, callable by `TAXER_ROLE` holders, allows an account to transfer a percentage of a specified `amount` from `_msgSender()` to `taxTreasury`, based on the `shortGovernanceRatio`. This mechanism is unusual as it is not a tax applied automatically during token transfers, but rather a separate, explicit function call initiated by a `TAXER_ROLE` holder. The intended use case, benefit, and potential for misuse of this function are not clearly defined within the code or comments, which could lead to confusion or unintended operational scenarios.
FixClarify the intended purpose and specific use cases for the `transferTax` function. Document its behavior thoroughly, including who is expected to call it, under what circumstances, and what problem it solves. Consider if this functionality is truly necessary or if it introduces unnecessary complexity or potential for misuse.
StatusUnresolved
Info

Broad Whitelist Exemption Logic

I-01The `_collectGovernance` function's whitelist logic for tax exemption is defined as `!whitelist[from] && !whitelist[to]`. This condition means that if *either* the `from` address or the `to` address is present in the `whitelist` mapping, the transaction will be exempt from both `longGovernanceRatio` (buy tax) and `shortGovernanceRatio` (sell tax). This broad exemption might not align with all potential use cases or expectations, as a single whitelisted participant can effectively bypass taxes for a transaction involving a non-whitelisted party.
IssueThe `_collectGovernance` function's whitelist logic for tax exemption is defined as `!whitelist[from] && !whitelist[to]`. This condition means that if *either* the `from` address or the `to` address is present in the `whitelist` mapping, the transaction will be exempt from both `longGovernanceRatio` (buy tax) and `shortGovernanceRatio` (sell tax). This broad exemption might not align with all potential use cases or expectations, as a single whitelisted participant can effectively bypass taxes for a transaction involving a non-whitelisted party.
FixReview the whitelist logic to ensure it precisely matches the intended tax exemption policy. If a stricter exemption is desired (e.g., both `from` and `to` must be whitelisted for exemption, or only the `from` address determines the tax), adjust the condition accordingly. Document the exact behavior of the whitelist for clarity.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The Token contract is built upon well-audited OpenZeppelin libraries (ERC20Burnable, ERC20Permit, AccessControl, Ownable2Step), which contributes to a solid foundation (7.2 Code Security). The tax collection logic in `_collectGovernance` is clearly structured and handles buy/sell taxes based on defined lists and whitelist exemptions. However, the reported renounced ownership introduces significant technical rigidity, making critical parameters like tax rates and treasury addresses permanently immutable (7.1 Architecture). Additionally, the `MINTER_ROLE` grants permanent, unlimited minting power to initial addresses, which cannot be revoked if ownership is renounced, posing a high risk of token inflation (7.3 Access Control).

GovernanceMedium6/10

The contract's economic model relies on configurable buy and sell tax rates, directed to a treasury address (7.4 Economic). The `onlyOwner` modifier initially centralizes control over these parameters and governance lists. However, with reported renounced ownership, all these parameters become permanently fixed at deployment (7.5 Governance). This removes the risk of a malicious owner changing them post-deployment but introduces a critical risk of inflexibility and inability to correct any initial misconfigurations or adapt to future needs. The `MINTER_ROLE` holders retain permanent, unlimited minting capabilities, which is a significant economic risk (7.4 Economic).

UpgradesMedium6/10

The Token contract is not designed as an upgradeable proxy. Therefore, there are no upgrade-specific risks or considerations for this contract. Any changes to the contract's logic would require a new deployment.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionFail
Liquidity LockedPass
Not a ProxyPass

Holder Composition

96.4% in top 10
3.6% in wallets92.8% in contracts
Effective Concentration40.7%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$15.14M

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

2 addresses
Deployer
0x5e19…1e94
Unlocked LP Held By
0x3e74…18d6

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

5 factors
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (96.4% total → 40.7% effective; 3.6% in EOAs, 92.8% in contracts — moderate)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Frequently Asked Questions

Is IBS a scam?

Based on automated analysis, IBS scores 61/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is IBS safe to buy?

Our scanner flagged a risk score of 61/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has IBS been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the record
ZygoSwap (ZSWAP)Medium RiskSIRENMedium RiskCZ Terminal Token (CZT)Low RiskANDYMedium RiskDogshitMedium RiskBEMLow Risk

Would You Like a More Detailed Audit of IBS?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit