Quantum Audit Logo
Launch App

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

Is PancakeSwap Token Safe?

CAKEBNB 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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 Critical · 1 Medium · 1 Low3
SummaryAI Copilot

The audit of the provided BEP20 token contract identified a critical functional flaw: the token's total supply is uninitialized and there is no mechanism to mint new tokens, rendering the contract unusable for transfers.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70%
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 1 Critical finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70% (97.0% total → 96.4% effective; 96.0% in EOAs, 0.9% in contracts — extreme)
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 1 Critical 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockUnknown
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
96.0%Wallets3.0%
96.0%Wallets3.0%
ContractsWalletsEveryone elseBubble area = share of supply
97.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking0.9%
  • Walletsanonymous holders, free to sell96.0%
  • Everyone elsethe rest of the supply3.0%
Effective concentrationwhat the score reads96.4%
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$20.11M across 30 pairs
Show 4 more pairs

The 20 remaining pairs hold $442.7K between them and are not listed. The risk score reads depth across every pair.

LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$5.05MShare of depth25.1%

Security Findings

1 Critical1 Medium1 Low
Critical

Uninitialized Total Supply and No Minting Mechanism

The _totalSupply state variable is initialized to 0 in the contract and there are no functions (e.g., _mint or an initial supply in the constructor) provided in the code to increase it. Consequently, the totalSupply() function will always return 0, and the _balances mapping will remain empty. This renders the token untransferable and completely unusable, as no tokens can ever exist or be moved.C-01

Issue

The _totalSupply state variable is initialized to 0 in the contract and there are no functions (e.g., _mint or an initial supply in the constructor) provided in the code to increase it. Consequently, the totalSupply() function will always return 0, and the _balances mapping will remain empty. This renders the token untransferable and completely unusable, as no tokens can ever exist or be moved.

Fix

Implement a mechanism to initialize and/or increase the _totalSupply. This could involve minting an initial supply in the constructor or adding an owner-controlled mint function to create new tokens and assign them to specific addresses.

Status

Unresolved

Medium

Centralized Control by Owner

The contract utilizes the Ownable pattern, granting a single owner address exclusive control over critical administrative functions such as transferOwnership and renounceOwnership. While common, this introduces a single point of failure. If the owner's private key is compromised, an attacker could gain full administrative control over the contract. The prefill indicates the owner is an 'OZ_ProxyAdmin', which suggests a more robust external governance mechanism might be in place, but from the contract's perspective, it's a single address.M-01

Issue

The contract utilizes the Ownable pattern, granting a single owner address exclusive control over critical administrative functions such as transferOwnership and renounceOwnership. While common, this introduces a single point of failure. If the owner's private key is compromised, an attacker could gain full administrative control over the contract. The prefill indicates the owner is an 'OZ_ProxyAdmin', which suggests a more robust external governance mechanism might be in place, but from the contract's perspective, it's a single address.

Fix

Consider implementing a multi-signature wallet for the owner address or integrating a time-locked governance mechanism for critical operations. This would distribute control and add a delay to sensitive actions, enhancing security and decentralization.

Status

Unresolved

Low

Front-Running Risk in decreaseAllowance

The decreaseAllowance function, while an improvement over directly setting allowance to zero, is still susceptible to front-running. If a user broadcasts a transaction to decreaseAllowance, an attacker monitoring the mempool could front-run this transaction by quickly spending the remaining allowance before the decrease takes effect. This is a known pattern in ERC-20 tokens.L-01

Issue

The decreaseAllowance function, while an improvement over directly setting allowance to zero, is still susceptible to front-running. If a user broadcasts a transaction to decreaseAllowance, an attacker monitoring the mempool could front-run this transaction by quickly spending the remaining allowance before the decrease takes effect. This is a known pattern in ERC-20 tokens.

Fix

Users should be aware of this inherent risk when interacting with allowance mechanisms. While no direct code change is typically made for this, users can mitigate risk by approving only necessary amounts or by using a transaction relay service that obscures transaction details until confirmation.

Status

Unresolved

Analysis

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

The audit of the provided BEP20 token contract identified a critical functional flaw: the token's total supply is uninitialized and there is no mechanism to mint new tokens, rendering the contract unusable for transfers. Additionally, the contract employs a standard Ownable pattern, centralizing administrative control, and exhibits a low-severity front-running risk common to ERC-20 allowance mechanisms. The contract otherwise demonstrates good code quality and utilizes established libraries for secure arithmetic and address interactions.

Technical6/10Medium risk

The contract demonstrates strong technical foundations by utilizing the SafeMath library (7.2 Code Security) to prevent integer overflows/underflows and the Address library for secure external interactions. The architecture (7.1 Architecture) follows standard ERC-20 patterns. However, a critical technical flaw exists where the token's total supply is never initialized or increased, making all transfer functions effectively non-functional (7.2 Code Security).

Governance1/10High risk

The contract implements the Ownable pattern (7.3 Access Control), centralizing administrative control to a single owner address, which is noted to be an OZ_ProxyAdmin externally. This introduces a single point of failure for critical operations like ownership transfer (7.5 Governance). Economically (7.4 Economic), the contract is critically flawed as the total supply is zero and no minting mechanism is present, preventing any token circulation or value.

Upgrades3/10High risk

The provided contract is not designed as an upgradeable proxy (7.7 Upgrades) and does not contain any upgrade-specific logic. Therefore, direct upgrade safety concerns for this specific contract are not applicable. Any upgradeability would be managed by an external proxy contract pointing to this implementation.

Final RecommendationWhat to do about this score

It is critical to address the uninitialized total supply by implementing a minting mechanism, either in the constructor for an initial supply or through an owner-controlled mint function.

Without this, the token contract is non-functional. For administrative control, consider enhancing the owner's security by using a multi-signature wallet or a time-locked governance contract, especially given the owner is an OZ_ProxyAdmin, which suggests a more robust setup might be intended.

Contract & Record

1 audit on record
TypeCakeToken
NetworkBNB Chain
Token age3y
Contract0x0e09…ce82
Deployer0x0f93…3373
Badge for your website
PancakeSwap Token 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. Aug 11, 202670High

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

Frequently Asked Questions

What is the CAKE contract address?

The PancakeSwap Token (CAKE) contract on BNB Chain is 0x0e09fabb73bd3ade0a17ecc321fd13a19e81ce82. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is PancakeSwap Token a scam?

Quantum Audit's risk score for PancakeSwap Token is 70/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Who holds CAKE?

As of Sep 4, 2026, the 10 largest holders own 97.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Infinity Ground AIAIN · BNB Chain70HighFinTech AIFNA · BNB Chain70HighSOCKBNB Chain70HighTopazBNB Chain70HighLitecoin TokenLTC · BNB Chain70HighiShares China Large-Cap ETF (Ondo Tokenized)FXION · BNB Chain70High

Would You Like a More Detailed Audit of PancakeSwap Token?

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