Quantum Audit Logo

Is Broker Cat a Scam?

Honeypot, rug-pull and ownership checks

Broker Cat BROKER
0xce24…8222
Base
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.
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The AdvancedLaunchToken contract implements an ERC20 token with custom launch mechanics, including a wallet cap and a reward tracker integration. The contract demonstrates good adherence to modern Solidity practices and uses OpenZeppelin standards. However, the audit identified several areas of concern, primarily related to centralized control by the 'launcher' address, inflexibility in key economic parameters, and potential risks associated with external calls. These issues contribute to a Medium overall risk level.

1 High2 Medium1 Low1 Informational
i Our automated scanner reviewed Broker Cat (BROKER) on Base. 3 of 5 security checks passed — see the full breakdown below.
Volume 24h
$86.0K
Liquidity
$75.1K
Price
$0.0003348
Age
12d
Top 10 Holders
34.8%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control of Critical Token Parameters

H-01The `launcher` address has exclusive control over several critical functions: `setExempt`, `setRewardTracker`, and `finishLaunch`. This centralization means that a single compromised private key or malicious `launcher` could manipulate token distribution rules (by exempting addresses from the wallet cap), integrate with a malicious reward tracker, or prematurely finalize the token launch. This creates a single point of failure for the token's core mechanics (7.3 Access Control, 7.8 Operations).
IssueThe `launcher` address has exclusive control over several critical functions: `setExempt`, `setRewardTracker`, and `finishLaunch`. This centralization means that a single compromised private key or malicious `launcher` could manipulate token distribution rules (by exempting addresses from the wallet cap), integrate with a malicious reward tracker, or prematurely finalize the token launch. This creates a single point of failure for the token's core mechanics (7.3 Access Control, 7.8 Operations).
FixImplement a multi-signature wallet or a time-locked governance mechanism for the `launcher` address to distribute control and reduce the risk of a single point of failure. This would require multiple approvals for critical operations, significantly increasing security.
StatusUnresolved
Medium

Inflexible Wallet Cap Configuration

M-01The `maxWalletBps` parameter, which defines the maximum percentage of total supply an address can hold, is set immutably in the constructor. This design choice prevents any future adjustments to the wallet cap based on evolving market conditions, community feedback, or unforeseen circumstances. This lack of flexibility could hinder the token's ability to adapt to future needs or address potential economic imbalances (7.4 Economic).
IssueThe `maxWalletBps` parameter, which defines the maximum percentage of total supply an address can hold, is set immutably in the constructor. This design choice prevents any future adjustments to the wallet cap based on evolving market conditions, community feedback, or unforeseen circumstances. This lack of flexibility could hinder the token's ability to adapt to future needs or address potential economic imbalances (7.4 Economic).
FixConsider making the `maxWalletBps` parameter configurable by a trusted entity (e.g., the `launcher` via a multi-sig or a governance contract) after deployment. This would allow for controlled adjustments to the wallet cap, enhancing the token's long-term adaptability while maintaining security.
StatusUnresolved
Medium

Unchecked External Call and High Gas Limit

M-02The `_update` function performs a low-level external call to the `rewardTracker` via `tracker.call{gas: 5_000_000}(...)`. The boolean return value (`ok`) of this call is not checked, meaning the transaction will proceed even if the `rewardTracker` call fails. Additionally, a high gas limit of 5 million is provided. If the `rewardTracker` is malicious or faulty, it could fail silently, leading to desynchronization in the broader ecosystem, or consume excessive gas, potentially increasing transaction fees or causing denial-of-service for other operations (7.2 Code Security, 7.6 External).
IssueThe `_update` function performs a low-level external call to the `rewardTracker` via `tracker.call{gas: 5_000_000}(...)`. The boolean return value (`ok`) of this call is not checked, meaning the transaction will proceed even if the `rewardTracker` call fails. Additionally, a high gas limit of 5 million is provided. If the `rewardTracker` is malicious or faulty, it could fail silently, leading to desynchronization in the broader ecosystem, or consume excessive gas, potentially increasing transaction fees or causing denial-of-service for other operations (7.2 Code Security, 7.6 External).
FixImplement a check for the return value of the external call to `rewardTracker` and handle potential failures appropriately (e.g., revert or emit an event). Re-evaluate the necessity of such a high gas limit; a lower, more precise gas limit can mitigate risks associated with malicious external contract behavior.
StatusUnresolved
Low

Initial Token Distribution Centralization

L-01The entire initial token supply is minted to the `launcher` address during contract deployment. While this is a common pattern for initial distribution, it concentrates a significant portion of the token's power and value in a single entity at launch. This could raise concerns about decentralization, potential market manipulation, or a single point of failure if the `launcher` address is compromised (7.4 Economic).
IssueThe entire initial token supply is minted to the `launcher` address during contract deployment. While this is a common pattern for initial distribution, it concentrates a significant portion of the token's power and value in a single entity at launch. This could raise concerns about decentralization, potential market manipulation, or a single point of failure if the `launcher` address is compromised (7.4 Economic).
FixConsider distributing the initial token supply to multiple addresses or a vesting contract controlled by a multi-sig or governance, rather than a single `launcher` address. This would promote decentralization from the outset and reduce the impact of a single point of failure.
StatusUnresolved
Info

Unused `creator` Variable

I-01The `creator` address is set in the constructor and marked as `public immutable`, but it is not utilized in any subsequent logic within the contract. While not a vulnerability, it represents dead code and could be removed if its purpose is purely informational and not enforced on-chain (7.2 Code Security).
IssueThe `creator` address is set in the constructor and marked as `public immutable`, but it is not utilized in any subsequent logic within the contract. While not a vulnerability, it represents dead code and could be removed if its purpose is purely informational and not enforced on-chain (7.2 Code Security).
FixIf the `creator` variable serves no functional purpose beyond initial record-keeping, consider removing it to reduce contract size and improve code clarity. If it is intended for future use, ensure its purpose is documented.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good adherence to modern Solidity practices, utilizing OpenZeppelin's ERC20 standard and Solidity 0.8.x's built-in overflow checks. Key parameters like `creator`, `launcher`, and `maxWalletBps` are correctly declared as `immutable`, enhancing security by preventing unauthorized modification (7.1 Architecture). However, a potential technical risk lies in the `_update` function's external call to the `rewardTracker` (7.2 Code Security). This call's return value is unchecked, and a high gas limit is provided, which could lead to unexpected behavior or resource consumption if the `rewardTracker` is malicious or faulty.

GovernanceHigh2/10

The economic model includes a configurable wallet cap and an exemption mechanism, providing flexibility for token distribution. However, the `launcher` address holds significant centralized control (7.3 Access Control, 7.8 Operations), being solely responsible for setting exemptions, configuring the reward tracker, and finalizing the token launch. This creates a single point of failure, as a compromise of the `launcher` could lead to critical system manipulation. Additionally, the `maxWalletBps` parameter is immutable (7.4 Economic), preventing any future adjustments to the wallet cap percentage, which could limit long-term adaptability.

UpgradesMedium6/10

The `AdvancedLaunchToken` contract is not designed with upgradeability in mind, as it does not implement any proxy patterns (7.7 Upgrades). This means its logic is immutable once deployed, providing a high degree of certainty regarding its long-term behavior. While this eliminates upgrade-related risks, any discovered vulnerabilities or desired feature enhancements would necessitate a new contract deployment and migration process.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

34.8% in top 10
2.4% in wallets32.4% in contracts
Effective Concentration15.3%

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

$75.2K across 3 pairs
Uniswap v4EDELanalysed$75.1K99.8%Uniswap v4USDC$1280.2%Uniswap v4USDC$110.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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x0ce8…3eee
Unlocked LP Held By
0x02f4…30b5

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

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 1 High finding(s) from audit
  • 2 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
aeonHigh RiskRobo Token (ROBO)High RiskPlumbingHigh RiskELONHigh RiskNockchain (NOCK)Medium RiskViciCoin (VCNT)High Risk

Would You Like a More Detailed Audit of Broker Cat?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit