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
0x23d3…8f2b
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The TokenV2 contract is an upgradeable ERC20 token utilizing OpenZeppelin's upgradeable libraries. It implements transfer constraints that initially prevent interaction with specified Uniswap V2 and V3 pools, which can be removed by the contract owner. While the architecture is standard and leverages well-audited components, significant centralization risks exist regarding initial token distribution and the owner's control over transfer restrictions. The contract is designed for upgradeability via a proxy pattern.

1 High1 Medium1 Low1 Informational
Volume 24h
$86.0K
Liquidity
$214.8K
Price
$0.001622
Token Age
1y
Top 10 Holders
94.9%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control Over Transfer Constraints

H-01The `owner` address has the sole authority to call `removeTransferConstraints()`, which permanently disables the restrictions on transferring tokens to and from the specified Uniswap V2 and V3 pools. This gives the owner significant, unilateral control over the token's liquidity and market dynamics, potentially allowing them to enable/disable trading on major DEXs at will. A compromised owner key or malicious owner could severely impact the token's market.
IssueThe `owner` address has the sole authority to call `removeTransferConstraints()`, which permanently disables the restrictions on transferring tokens to and from the specified Uniswap V2 and V3 pools. This gives the owner significant, unilateral control over the token's liquidity and market dynamics, potentially allowing them to enable/disable trading on major DEXs at will. A compromised owner key or malicious owner could severely impact the token's market.
FixConsider implementing a multi-signature wallet for the owner address to control critical functions like `removeTransferConstraints()`. Alternatively, introduce a time-lock mechanism for this function, allowing a grace period for users to react before changes take effect. For long-term decentralization, explore integrating a community-driven governance mechanism to manage such critical parameters.
StatusUnresolved
Medium

Initial Token Distribution Centralization

M-01During the `initialize` function, all `maxSupply` tokens are minted directly to `msg.sender`. This results in 100% of the token's total supply being held by a single address immediately after deployment. While this is a common pattern for initial supply, it creates a high centralization risk for token distribution and potential for market manipulation if the initial holder's actions are not transparent or well-managed.
IssueDuring the `initialize` function, all `maxSupply` tokens are minted directly to `msg.sender`. This results in 100% of the token's total supply being held by a single address immediately after deployment. While this is a common pattern for initial supply, it creates a high centralization risk for token distribution and potential for market manipulation if the initial holder's actions are not transparent or well-managed.
FixProvide clear documentation and transparency regarding the project's plans for distributing the initial token supply. Consider implementing a vesting schedule or a decentralized distribution mechanism (e.g., airdrops, liquidity mining programs) to gradually decentralize token ownership and reduce the risk of concentrated holdings impacting market stability.
StatusUnresolved
Low

Immutable Pool Addresses and MetaURI

L-01The `uniswapV2Pool`, `uniswapV3Pool`, and `metaURI` variables are set only during the `initialize` function and lack any setter functions. This makes these parameters immutable after deployment. While immutability can be a security feature, it means that if the specified pool addresses become outdated, incorrect, or if the `metaURI` needs to be updated (e.g., for branding or metadata changes), an upgrade of the entire contract implementation would be required.
IssueThe `uniswapV2Pool`, `uniswapV3Pool`, and `metaURI` variables are set only during the `initialize` function and lack any setter functions. This makes these parameters immutable after deployment. While immutability can be a security feature, it means that if the specified pool addresses become outdated, incorrect, or if the `metaURI` needs to be updated (e.g., for branding or metadata changes), an upgrade of the entire contract implementation would be required.
FixAssess whether these parameters truly need to be immutable. If flexibility is desired, consider adding `onlyOwner` setter functions for `metaURI` and potentially for the pool addresses, especially if the project anticipates changes in liquidity pool infrastructure or metadata requirements. Ensure any such setters are protected by appropriate access controls.
StatusUnresolved
Info

Missing `_authorizeUpgrade` in UUPS Implementation

I-01The `TokenV2` contract is an upgradeable implementation using the UUPS pattern but does not include an `_authorizeUpgrade` function. This means that the decision and authorization for upgrading the contract are solely managed by the proxy's admin/owner, without any additional checks or logic within the implementation contract itself. While this is a valid design choice, some projects implement `_authorizeUpgrade` to add specific checks (e.g., governance votes, time-locks) before an upgrade can proceed.
IssueThe `TokenV2` contract is an upgradeable implementation using the UUPS pattern but does not include an `_authorizeUpgrade` function. This means that the decision and authorization for upgrading the contract are solely managed by the proxy's admin/owner, without any additional checks or logic within the implementation contract itself. While this is a valid design choice, some projects implement `_authorizeUpgrade` to add specific checks (e.g., governance votes, time-locks) before an upgrade can proceed.
FixThis is an informational finding. If the current design aligns with the project's security and governance model, no action is strictly required. However, for enhanced security and decentralized control over upgrades, consider adding an `_authorizeUpgrade` function to the implementation contract that integrates with a governance mechanism or a time-lock, ensuring upgrades are not solely dependent on a single administrative key.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract demonstrates good technical practices by inheriting from OpenZeppelin's battle-tested upgradeable ERC20, ERC20Permit, and Ownable contracts (7.2 Code Security). It correctly uses the `initializer` pattern for upgradeable contracts and an empty constructor. A key feature is the `_beforeTokenTransfer` hook, which enforces `transferConstraints` to prevent interaction with specific AMM pools (7.1 Architecture). However, the owner's ability to unilaterally remove these constraints introduces a centralized control point (7.3 Access Control).

GovernanceMedium5/10

The economic model presents a significant centralization risk as all `maxSupply` tokens are minted to the initializer address, concentrating 100% of the supply initially (7.4 Economic). Furthermore, the `owner` has sole control over the `removeTransferConstraints()` function, which can drastically alter the token's market dynamics by enabling or disabling trading on specified Uniswap pools (7.5 Governance). This centralized control over liquidity provision could be exploited or lead to market manipulation if not managed transparently.

UpgradesLow10/10

The contract is designed for upgradeability using the UUPS proxy pattern, leveraging OpenZeppelin's upgradeable contracts and the `initializer` modifier (7.7 Upgrades). The `constructor` is correctly left empty, preventing re-initialization issues. While the implementation contract itself does not include an `_authorizeUpgrade` function, this means upgrade decisions are solely managed by the proxy's admin/owner, which is a common and acceptable design choice for UUPS proxies.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

94.9% in top 10
82.5% in wallets12.3% in contracts
Effective Concentration87.4%

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

$214.9K across 2 pairs
Pancakeswap v3WBNBanalysed$214.8K99.9%Pancakeswap v3WBNB$1590.1%

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.3% · UNCX Locker
Top-1 Unlocked Holder23.7%
Top-3 Unlocked23.7%

Key Addresses

6 addresses
Deployer
0x9c7f…ce1c
Unlocked LP Held By
0x5036…6a200xa85c…34ec0x794e…03b30x1cf8…dda70xf4ea…a601

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 > 70% (94.9% total → 87.4% effective; 82.5% in EOAs, 12.3% in contracts — extreme)
  • 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
Baby Asteroid (BABYASTEROID)Medium RiskDecentrawood (DEOD)Medium RiskLABMedium RiskMatthewCoinMedium RiskKoma Inu (KOMA)Medium RiskBillion Zone Xchange (ZBX)Medium 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