Is PancakeSwap (CAKE) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Med

Critical

Inconsistent Token Decimals

C-01The `CakeOFT` contract's `decimals()` function explicitly overrides the inherited `ERC20.decimals()` to return `18`. However, in its constructor, it initializes the `OFTWithFee` (which inherits from `ERC20`) with `8` decimals: `OFTWithFee("PancakeSwap Token", "Cake", 8, _lzEndpoint)`. This creates a severe inconsistency where the token internally operates with 8 decimals (e.g., for LayerZero `_amountLD` calculations) but externally reports 18 decimals. This discrepancy can lead to incorrect token amounts being transferred, displayed, or accounted for in external systems, potentially resulting in significant financial loss or protocol malfunction.

IssueThe `CakeOFT` contract's `decimals()` function explicitly overrides the inherited `ERC20.decimals()` to return `18`. However, in its constructor, it initializes the `OFTWithFee` (which inherits from `ERC20`) with `8` decimals: `OFTWithFee("PancakeSwap Token", "Cake", 8, _lzEndpoint)`. This creates a severe inconsistency where the token internally operates with 8 decimals (e.g., for LayerZero `_amountLD` calculations) but externally reports 18 decimals. This discrepancy can lead to incorrect token amounts being transferred, displayed, or accounted for in external systems, potentially resulting in significant financial loss or protocol malfunction.

FixEnsure consistency in token decimals. Either initialize `OFTWithFee` with 18 decimals in the constructor and remove the `decimals()` override, or ensure all internal and external interactions correctly handle the 8-decimal representation. The most straightforward solution is to align the constructor parameter with the overridden `decimals()` function.

StatusUnresolved

High

Centralized Control and Whitelist Bypass Risk

H-01The `onlyOwner` role holds significant power, including the ability to pause/unpause the contract, set inbound/outbound transfer caps, and manage the whitelist. The whitelist allows designated addresses to bypass the daily transfer caps, which are a critical security feature designed to limit potential losses during bridge exploits. If the `onlyOwner` key (or multisig) is compromised, or if a whitelisted address is compromised, an attacker could bypass the caps and drain funds or cause significant disruption.

IssueThe `onlyOwner` role holds significant power, including the ability to pause/unpause the contract, set inbound/outbound transfer caps, and manage the whitelist. The whitelist allows designated addresses to bypass the daily transfer caps, which are a critical security feature designed to limit potential losses during bridge exploits. If the `onlyOwner` key (or multisig) is compromised, or if a whitelisted address is compromised, an attacker could bypass the caps and drain funds or cause significant disruption.

FixImplement robust security measures for the `onlyOwner` role, such as a strong multisig with a high threshold. Regularly review and audit whitelisted addresses. Consider implementing time-locks or multi-signature approvals for critical administrative actions like setting caps to zero or adding/removing addresses from the whitelist, to introduce a delay and allow for community oversight or emergency intervention.

StatusUnresolved

Medium

Lack of General Emergency Withdrawal for ERC-20 Tokens

M-01The contract is an ERC-20 token itself, but it does not include a general function to recover other ERC-20 tokens that might be accidentally sent to its address. While the contract is primarily for its native token, receiving other tokens by mistake is a common operational risk. Without a dedicated recovery mechanism, such tokens would be permanently locked in the contract.

IssueThe contract is an ERC-20 token itself, but it does not include a general function to recover other ERC-20 tokens that might be accidentally sent to its address. While the contract is primarily for its native token, receiving other tokens by mistake is a common operational risk. Without a dedicated recovery mechanism, such tokens would be permanently locked in the contract.

FixImplement a `recoverERC20(address tokenAddress, uint256 amount)` function, restricted to the `onlyOwner` role. This function would allow the owner to retrieve any ERC-20 tokens accidentally sent to the contract, preventing their permanent loss. Ensure this function cannot be used to drain the contract's native token.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages LayerZero for omnichain functionality and OpenZeppelin's Pausable for operational control (7.1 Architecture, 7.2 Code Security). It implements daily inbound and outbound transfer caps per chain ID, enhancing security against large-scale bridge exploits. However, a critical issue exists where the `decimals()` function returns 18, while the underlying `OFTWithFee` (ERC20) is initialized with 8 decimals, creating a severe inconsistency (7.2 Code Security). The whitelist mechanism allows certain addresses to bypass these caps, introducing a potential point of failure if a whitelisted address is compromised (7.3 Access Control).

GovernanceHigh1/10

The contract's economic model incorporates daily transfer caps to mitigate risks associated with cross-chain token movements (7.4 Economic). Control over these caps, as well as pausing and whitelist management, is centralized under an `onlyOwner` role (7.5 Governance). While the owner is identified as an `OZ_ProxyAdmin` (likely a multisig), this centralization, combined with the whitelist's ability to bypass caps, presents a moderate governance risk (7.3 Access Control).

UpgradesMedium6/10

The provided contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, there are no specific upgrade-related risks inherent to this contract's architecture. Any future changes would require a new deployment and migration.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

58.3% in top 10

58.3% in wallets0.0% in contracts

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

$291.8K across 11 pairs

Pancakeswap v3WETHanalysed$232.5K Pancakeswap v3USDC$50.7K Uniswap v4ZIK$3.3K Uniswap v3WETH$2.5K PancakeswapUSDT$2.3K Uniswap v3UNI$407

Show 3 more pairsShow less

Pancakeswap v3USDT$171 Pancakeswap v3WETH$25 Pancakeswap v3USDT$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

Top-1 Unlocked Holder99.1%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0x7020…2fc2

Unlocked LP Held By

0x3b80…20130xdbb2…7b8e

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 NOT renounced — owner is a contract (governance/executor, not an EOA)
Top-10 concentration > 50% (58.3% total → 58.3% effective; 58.3% in EOAs, 0.0% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.1% (independent LP — depth risk, pool = 80% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 80% of DEX liquidity)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 Medium 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 Safe?

Security Findings

Inconsistent Token Decimals

Centralized Control and Whitelist Bypass Risk

Lack of General Emergency Withdrawal for ERC-20 Tokens

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of PancakeSwap?