Quantum Audit Logo
Launch App

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

Is Cookie Safe?

COOKIEBNB 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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance3/10Upgrades7/10Checks passed3 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The OmnichainCookie contract is an Omnichain Fungible Token (OFT) built on LayerZero, inheriting from OpenZeppelin's Ownable and LayerZero's OFT.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 94.9%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Top-10 concentration > 30% (61.0% total → 45.1% effective; 34.4% in EOAs, 26.6% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 94.9% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
26.6%Contracts34.4%Wallets39.0%Everyone else
26.6%Contracts34.4%Wallets39.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
61.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking26.6%
  • Walletsanonymous holders, free to sell34.4%
  • Everyone elsethe rest of the supply39.0%
Effective concentrationwhat the score reads45.1%
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$241.5K across 4 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$236.0KShare of depth97.7%
Top-1 Unlocked Holder94.9%
Top-3 Unlocked100.0%
Unlocked LP held by
0x556b…d59e0x3d16…e5710x39c2…b1810x8e12…d6e10xd379…60d80x8e0a…76c10xcc24…a8fd0x5ad1…2cb00x5dba…a82a0x5e91…fac1

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

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Administrative Control via Delegate Address

The _delegate address provided in the constructor serves a dual role: it becomes the Ownable owner and the LayerZero OFT delegate. This grants a single entity (or multisig) comprehensive control over both the standard Ownable functions (e.g., transferOwnership) and all LayerZero-specific administrative functions (e.g., setTrustedRemote, setFeeManager, setMinDstGas). A compromise of this address would lead to full control over the token's cross-chain operations and ownership, posing a significant centralization risk (7.3 Access Control, 7.5 Governance).H-01

Issue

The _delegate address provided in the constructor serves a dual role: it becomes the Ownable owner and the LayerZero OFT delegate. This grants a single entity (or multisig) comprehensive control over both the standard Ownable functions (e.g., transferOwnership) and all LayerZero-specific administrative functions (e.g., setTrustedRemote, setFeeManager, setMinDstGas). A compromise of this address would lead to full control over the token's cross-chain operations and ownership, posing a significant centralization risk (7.3 Access Control, 7.5 Governance).

Fix

While the current owner is a multisig, consider implementing a time-lock mechanism for critical administrative functions (e.g., transferOwnership, setTrustedRemote) to provide a delay for review and potential intervention. Regularly audit and review the security posture of the multisig wallet controlling this address.

Status

Unresolved

Medium

Reliance on LayerZero Endpoint Security and Liveness

The core functionality of the OmnichainCookie token, specifically its cross-chain transfers, is entirely dependent on the LayerZero protocol and its _lzEndpoint. Any vulnerabilities, operational failures, or compromises within the LayerZero endpoint, its relayers, or oracles could directly impact the ability to transfer tokens across chains, potentially leading to frozen funds or incorrect state (7.6 External, 7.4 Economic).M-01

Issue

The core functionality of the OmnichainCookie token, specifically its cross-chain transfers, is entirely dependent on the LayerZero protocol and its _lzEndpoint. Any vulnerabilities, operational failures, or compromises within the LayerZero endpoint, its relayers, or oracles could directly impact the ability to transfer tokens across chains, potentially leading to frozen funds or incorrect state (7.6 External, 7.4 Economic).

Fix

Implement robust monitoring for the LayerZero endpoint's health, transaction finality, and any reported vulnerabilities. Establish an emergency response plan for potential LayerZero-related incidents. Consider diversifying cross-chain solutions in the future if the protocol's design allows.

Status

Unresolved

Medium

Lack of Emergency Pause Mechanism

The OmnichainCookie contract does not include a direct, contract-level mechanism to pause token transfers or cross-chain operations. In the event of a critical vulnerability, an exploit, or a major issue with the LayerZero bridge, the absence of a pause function could prevent immediate mitigation, potentially leading to significant loss of funds or protocol disruption (7.8 Operations).M-02

Issue

The OmnichainCookie contract does not include a direct, contract-level mechanism to pause token transfers or cross-chain operations. In the event of a critical vulnerability, an exploit, or a major issue with the LayerZero bridge, the absence of a pause function could prevent immediate mitigation, potentially leading to significant loss of funds or protocol disruption (7.8 Operations).

Fix

Evaluate the feasibility and necessity of integrating a pause mechanism (e.g., OpenZeppelin's Pausable module) into the contract. If implemented, ensure the pause functionality is controlled by a secure, multi-signature wallet with a clear activation policy and emergency procedures.

Status

Unresolved

Low

Constructor Delegate Parameter Importance

The _delegate address passed to the constructor is critical as it initializes both the OFT delegate and the Ownable owner. While the prefill indicates this is a multisig, any misconfiguration or error in providing this address during deployment would result in an irreversible single point of failure or an inaccessible contract (7.3 Access Control, 7.8 Operations).L-01

Issue

The _delegate address passed to the constructor is critical as it initializes both the OFT delegate and the Ownable owner. While the prefill indicates this is a multisig, any misconfiguration or error in providing this address during deployment would result in an irreversible single point of failure or an inaccessible contract (7.3 Access Control, 7.8 Operations).

Fix

Ensure rigorous pre-deployment checks and verification of the _delegate address, confirming it corresponds to a securely managed multi-signature wallet. Implement a robust deployment checklist and consider a dry-run deployment on a testnet to validate all constructor parameters.

Status

Unresolved

Info

Non-Upgradeable Contract Design

The OmnichainCookie contract is implemented directly and does not utilize a proxy pattern, meaning it is not upgradeable. This design choice ensures immutability and predictability of the contract's logic (7.7 Upgrades). However, it also implies that any future bug fixes, security patches, or desired feature enhancements would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex and resource-intensive process.I-01

Issue

The OmnichainCookie contract is implemented directly and does not utilize a proxy pattern, meaning it is not upgradeable. This design choice ensures immutability and predictability of the contract's logic (7.7 Upgrades). However, it also implies that any future bug fixes, security patches, or desired feature enhancements would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex and resource-intensive process.

Fix

Acknowledge the implications of non-upgradeability. Ensure the current contract logic is thoroughly audited and robust. Plan for potential future migrations by considering mechanisms to facilitate token transfers to a new contract if necessary, or accept the immutability as a core feature.

Status

Unresolved

Analysis

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

The OmnichainCookie contract is an Omnichain Fungible Token (OFT) built on LayerZero, inheriting from OpenZeppelin's Ownable and LayerZero's OFT. The contract's core logic is minimal, primarily relying on well-audited external libraries. Key risks identified relate to the centralized administrative control via the owner/delegate address and the inherent dependencies on the LayerZero protocol for cross-chain functionality. The contract is not upgradeable, which implies immutability but also inflexibility for future changes.

Technical8/10Low risk

The contract leverages battle-tested OpenZeppelin (Ownable, ERC20) and LayerZero (OFT) libraries, contributing to a strong technical foundation (7.1 Architecture, 7.2 Code Security). The custom logic is minimal and correctly implements the constructor for initializing both base contracts. However, the reliance on the LayerZero endpoint introduces an external dependency risk (7.6 External), and the single _delegate address controls both ownership and LayerZero-specific administrative functions (7.3 Access Control), posing a centralization risk.

Governance3/10High risk

The _delegate address, which also serves as the Ownable owner, holds significant administrative power over the token's cross-chain operations and general contract management (7.5 Governance). This includes setting LayerZero parameters like trusted remotes and fees, impacting the token's economic behavior (7.4 Economic). While the owner is a 2/3 multisig, this centralized control point remains a key consideration. The absence of a direct emergency pause mechanism could impact operational response during critical events (7.8 Operations).

Upgrades7/10Low risk

The OmnichainCookie contract is not designed as an upgradeable proxy (7.7 Upgrades). This means its logic is immutable once deployed, which can be a security strength by preventing unexpected changes. However, it also implies that any future bug fixes, feature enhancements, or necessary protocol adjustments would require a new contract deployment and a potentially complex token migration process, which could be costly and disruptive.

Final RecommendationWhat to do about this score

It is crucial to ensure the security of the _delegate address, as it holds extensive administrative control; consider implementing a time-lock for critical administrative actions.

Establish robust monitoring for LayerZero endpoint health and cross-chain transaction integrity. Evaluate the necessity of an emergency pause mechanism for the token, either directly in the contract or through LayerZero's capabilities, to mitigate risks during unforeseen events. Given the non-upgradeable nature, thorough testing and a clear long-term strategy are paramount.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age2y
Contract0xc004…265f
Deployer0x0c35…d3bc
Badge for your website
Cookie 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 12, 202653Medium

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

Related Audits

6 more on the recordAll audits
CrossBNB Chain53Medium永生果蝇BNB Chain53MediumPeppinBNB Chain53MediumChainOpera AICOAI · BNB Chain52MediumYooldo GamesESPORTS · BNB Chain52MediumAKEBNB Chain52Medium

Would You Like a More Detailed Audit of Cookie?

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