On-chain security analysis — is it a scam or legit?
EthereumThe CakeOFT contract implements an Omnichain Fungible Token (OFT) with LayerZero integration, featuring daily transfer caps and a whitelist mechanism.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x3b80…20130xdbb2…7b8eNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
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.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.
Ensure 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.
Unresolved
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.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.
Implement 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.
Unresolved
The 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.
Implement 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.
Unresolved
The CakeOFT contract implements an Omnichain Fungible Token (OFT) with LayerZero integration, featuring daily transfer caps and a whitelist mechanism. The audit identified a critical inconsistency in token decimals, which could lead to severe miscalculations or loss of funds. Additionally, centralized control and the lack of a general emergency withdrawal function for accidentally sent ERC-20 tokens were noted.
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).
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).
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.
Immediately address the critical inconsistency in token decimals to prevent potential miscalculations and loss of funds.
Review the access control strategy for the onlyOwner role, especially concerning the whitelist, and ensure robust security measures are in place for the owner's private keys or multisig setup. Consider implementing a general emergency withdrawal function for accidentally sent ERC-20 tokens to enhance operational safety.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The PancakeSwap (CAKE) contract on Ethereum is 0x152649ea73beab28c5b49b26eb48f7ead6d4c898. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for PancakeSwap is 71/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $291.8K.
As of Sep 4, 2026, the 10 largest holders own 58.3% of the supply. The Holders section on this page shows who they are by holder type.
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
