Is PancakeSwap Token (CAKE) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Med1 Low

Critical

Uninitialized Total Supply and No Minting Mechanism

C-01The `_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.

IssueThe `_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.

FixImplement 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.

StatusUnresolved

Medium

Centralized Control by Owner

M-01The 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.

IssueThe 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.

FixConsider 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.

StatusUnresolved

Low

Front-Running Risk in `decreaseAllowance`

L-01The `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.

IssueThe `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.

FixUsers 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.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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).

GovernanceHigh1/10

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.

UpgradesHigh2/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

97.0% in top 10

96.0% in wallets0.9% in contracts

Effective Concentration96.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

$20.11M across 30 pairs

UniswapUSDTanalysed$5.05M Pancakeswap v3USDT$4.92M Pancakeswap v3WBNB$4.52M Pancakeswap v3COSA$2.02M Pancakeswap v3WBNB$1.38M Pancakeswap v2USDT$870.9K

Show 4 more pairsShow less

Pancakeswap v3ETH$264.1K Pancakeswap v3USDT$242.5K DinosaureggsWBNB$227.5K Squadswap v2WBNB$173.9K

The 20 remaining pairs hold $442.7K between them and are not listed.

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.

Key Addresses

1 addresses

Deployer

0x0f93…3373

What Raised This Score

7 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)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
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

Is PancakeSwap Token Safe?

Security Findings

Uninitialized Total Supply and No Minting Mechanism

Centralized Control by Owner

Front-Running Risk in `decreaseAllowance`

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of PancakeSwap Token?