Quantum Audit Logo

Is Broccoli Safe?

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

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

Broccoli BROCCOLI
0x12b4…2f3b
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive 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'. 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.

1 High1 Medium1 Low1 Informational
Volume 24h
$32.3K
Liquidity
$1.04M
Price
$0.006918
Token Age
1y
Top 10 Holders
74.1%

Security Findings

1 High1 Med1 Low1 Info
High

Irreversible Transfer Mode Change

H-01The `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.
IssueThe `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.
FixRemove 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.
StatusUnresolved
Medium

Centralized Control over Token Transfers

M-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Low

Theoretical Overflow in `unchecked` Blocks

L-01The 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.
IssueThe 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.
FixFor 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.
StatusUnresolved
Info

Initial Transfer Restriction

I-01The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalLow9/10

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.

GovernanceLow8/10

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.

UpgradesLow10/10

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.

Security Checklist

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

Holder Composition

74.1% in top 10
28.0% in wallets46.2% in contracts
Effective Concentration46.5%

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

$1.04M across 6 pairs
Pancakeswap v3WBNBanalysed$1.04M100.0%UniswapUSDC$840.0%Pancakeswap v2Subject 3$220.0%TopazWBNB$140.0%Pancakeswap v2BTCB$10.0%

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 Locked76.8% · GoPlus SafeToken Locker
Top-1 Unlocked Holder19.9%
Top-3 Unlocked21.6%

Key Addresses

10 addresses
Deployer
0x6897…f2a6
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.

What Raised This Score

4 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

Related Audits

6 more on the record
Momentum (MNTM)Low RiskBanana For Scale (BANANAS31)Low RiskWorld of Dypians (WOD)Low RiskTagger (TAG)Low RiskSmart Solve Token (SST)Low RiskCubus Store Coin (CSC)Low Risk

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