Quantum Audit Logo
Launch App

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

Is Broccoli Safe?

BROCCOLIBNB Chain
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical9/10Governance8/10Upgrades10/10Checks passed5 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The audit of the Token contract revealed a significant design flaw in the transfer mode management, leading to an irreversible state where transfer restrictions cannot be re-enabled once set to 'normal'.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (74.1% total → 46.5% effective; 28.0% in EOAs, 46.2% in contracts — moderate)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
46.2%Contracts28.0%Wallets25.9%Everyone else
46.2%Contracts28.0%Wallets25.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
74.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking46.2%
  • Walletsanonymous holders, free to sell28.0%
  • Everyone elsethe rest of the supply25.9%
Effective concentrationwhat the score reads46.5%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$1.04M across 6 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$1.04MShare of depth100.0%
LP Locked76.8% · GoPlus SafeToken Locker
Top-1 Unlocked Holder19.9%
Top-3 Unlocked21.6%
Unlocked LP held by
0x5036…6a200xaded…46b60x832e…381e0x67a6…5bb90x467b…71320xded4…a78e0x26b3…c34c0xeb7c…369d0xef7c…e878

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

Security Findings

1 High1 Medium1 Low1 Info
High

Irreversible Transfer Mode Change

The setMode function contains a condition if (_mode != MODE_NORMAL) { _mode = v; }. This logic prevents the owner from changing the _mode if it is currently MODE_NORMAL. Consequently, once the token's transfer mode is set to MODE_NORMAL, the owner permanently loses the ability to re-enable transfer restrictions (e.g., MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED). This removes a critical control mechanism that could be necessary for security incidents or market stability.H-01

Issue

The setMode function contains a condition if (_mode != MODE_NORMAL) { _mode = v; }. This logic prevents the owner from changing the _mode if it is currently MODE_NORMAL. Consequently, once the token's transfer mode is set to MODE_NORMAL, the owner permanently loses the ability to re-enable transfer restrictions (e.g., MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED). This removes a critical control mechanism that could be necessary for security incidents or market stability.

Fix

Remove the conditional check if (_mode != MODE_NORMAL) from the setMode function. This will allow the owner to freely switch between all defined modes, including re-enabling restrictions after the token has been in MODE_NORMAL. Ensure that the owner's private key is secured.

Status

Unresolved

Medium

Centralized Control over Token Transfers

The Token contract grants the owner() (deployer) significant control over token transferability through the setMode function. The owner can restrict all transfers (MODE_TRANSFER_RESTRICTED) or limit them to only transfers involving the owner (MODE_TRANSFER_CONTROLLED). While this offers flexibility, it introduces a high degree of centralization, where a single entity can unilaterally halt or control token movements, posing a risk of censorship or manipulation.M-01

Issue

The Token contract grants the owner() (deployer) significant control over token transferability through the setMode function. The owner can restrict all transfers (MODE_TRANSFER_RESTRICTED) or limit them to only transfers involving the owner (MODE_TRANSFER_CONTROLLED). While this offers flexibility, it introduces a high degree of centralization, where a single entity can unilaterally halt or control token movements, posing a risk of censorship or manipulation.

Fix

Consider implementing a multi-signature wallet for the owner address to reduce the single point of failure. For long-term decentralization, explore integrating a governance mechanism (e.g., DAO) to manage the _mode parameter, or transition to a fully permissionless state where _mode is permanently MODE_NORMAL after a certain period or condition.

Status

Unresolved

Low

Theoretical Overflow in unchecked Blocks

The contract uses unchecked blocks for _balances[to] += amount in _transfer and _mint, and _totalSupply += amount in _mint. While Solidity 0.8+ defaults to checked arithmetic, unchecked explicitly allows overflow. Although uint256 is extremely large, a theoretical overflow could occur if the sum of _balances[to] and amount (or _totalSupply and amount) exceeds type(uint256).max. This is highly improbable in practical scenarios for typical token values but is a theoretical edge case.L-01

Issue

The contract uses unchecked blocks for _balances[to] += amount in _transfer and _mint, and _totalSupply += amount in _mint. While Solidity 0.8+ defaults to checked arithmetic, unchecked explicitly allows overflow. Although uint256 is extremely large, a theoretical overflow could occur if the sum of _balances[to] and amount (or _totalSupply and amount) exceeds type(uint256).max. This is highly improbable in practical scenarios for typical token values but is a theoretical edge case.

Fix

For maximum robustness, consider adding explicit overflow checks within the unchecked blocks for additions, or ensure that the design inherently prevents such large sums. However, given the practical unlikelihood for uint256, this is a minor concern.

Status

Unresolved

Info

Initial Transfer Restriction

The Token contract's constructor initializes _mode to MODE_TRANSFER_RESTRICTED. This means that immediately after deployment, no token transfers are possible until the owner() explicitly calls setMode to change it to MODE_NORMAL or MODE_TRANSFER_CONTROLLED. This is an intended design choice but is crucial for users to understand.I-01

Issue

The Token contract's constructor initializes _mode to MODE_TRANSFER_RESTRICTED. This means that immediately after deployment, no token transfers are possible until the owner() explicitly calls setMode to change it to MODE_NORMAL or MODE_TRANSFER_CONTROLLED. This is an intended design choice but is crucial for users to understand.

Fix

Ensure that this initial state and the requirement for owner action to enable transfers are clearly documented and communicated to all prospective users and participants in the token ecosystem.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The audit of the Token contract revealed a significant design flaw in the transfer mode management, leading to an irreversible state where transfer restrictions cannot be re-enabled once set to 'normal'. This poses a high economic and operational risk. Other findings include centralized control over transfers and minor theoretical overflow concerns. The contract generally follows OpenZeppelin patterns for ERC20 and Ownable functionality.

Technical9/10Low risk

The contract implements a standard ERC20 token with custom transfer restriction logic (7.1 Architecture). Code security (7.2 Code Security) is generally robust, leveraging OpenZeppelin's unchecked blocks appropriately where underflow is prevented by prior checks. However, a critical flaw exists in the setMode function, which prevents the owner from re-enabling transfer restrictions once the mode is set to 'normal'. This represents a significant access control (7.3 Access Control) and operational (7.8 Operations) vulnerability.

Governance8/10Low risk

The token's economic model (7.4 Economic) is heavily influenced by the owner's ability to control transferability. The initial state restricts all transfers, requiring owner intervention. The primary governance mechanism (7.5 Governance) is the Ownable pattern, granting the deployer significant power. The irreversible nature of setting the transfer mode to 'normal' poses a high economic risk, as the owner loses the ability to react to adverse events by restricting transfers, potentially impacting token stability or security.

Upgrades10/10Low risk

The contract is not designed with an upgradeability pattern (7.7 Upgrades). Therefore, there are no specific upgrade-related risks to assess. Any changes to the contract's logic would require a new deployment and migration of assets.

Final RecommendationWhat to do about this score

It is strongly recommended to address the critical flaw in the setMode function to allow the owner to re-enable transfer restrictions after setting the mode to 'normal'.

This can be achieved by removing the if (_mode != MODE_NORMAL) condition. Additionally, consider implementing a timelock for sensitive owner actions to mitigate risks associated with centralized control. Ensure clear communication to users regarding the initial transfer restrictions and the owner's capabilities.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0x12b4…2f3b
Deployer0x6897…f2a6
Badge for your website
Broccoli security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 20268Low
  2. Aug 11, 202610Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
MomentumMNTM · BNB Chain8LowHachiko InuHACHIKO · BNB Chain8LowEGL1BNB Chain8LowUSDABNB Chain8LowBanana For ScaleBANANAS31 · BNB Chain7Low翻身币税助力凉兮翻身翻身币 · BNB Chain9Low

Would You Like a More Detailed Audit of Broccoli?

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

Get Detailed Audit Is this your token? Publish your own audit on this page