Quantum Audit Logo
Launch App

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

Is Cap Safe?

CAPBNB 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/10Governance2/10Upgrades3/10Checks passed2 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The L2TokenUpgradeable contract implements an ERC-20 token with LayerZero Omnichain Fungible Token (OFT) capabilities and UUPS upgradeability.

Read the full analysis
What raised the score
  • Ownership not renounced — Timelock 24h delay
  • Proxy contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — Timelock 24h delay
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (98.2% total → 43.9% effective; 7.7% in EOAs, 90.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($20,882 across 4 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 1 High 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
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
90.5%Contracts7.7%
90.5%Contracts7.7%
ContractsWalletsEveryone elseBubble area = share of supply
98.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking90.5%
  • Walletsanonymous holders, free to sell7.7%
  • Everyone elsethe rest of the supply1.8%
Effective concentrationwhat the score reads43.9%
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.9K 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$20.1KShare of depth96.4%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x100e…d7820xa5f3…4cf20x6f58…32a20x98c5…6e29

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control by Owner

The owner address, set during initialization, holds significant administrative control over the contract. This includes the ability to authorize upgrades (_authorizeUpgrade), set LayerZero peers (setPeer), and set the LayerZero delegate (setDelegate). While the owner is identified as a Timelock, which mitigates immediate malicious actions by introducing a delay, this still represents a single point of administrative decision-making and control. A compromise of the Timelock's governance mechanism could lead to unauthorized upgrades or manipulation of cross-chain functionality.H-01

Issue

The owner address, set during initialization, holds significant administrative control over the contract. This includes the ability to authorize upgrades (_authorizeUpgrade), set LayerZero peers (setPeer), and set the LayerZero delegate (setDelegate). While the owner is identified as a Timelock, which mitigates immediate malicious actions by introducing a delay, this still represents a single point of administrative decision-making and control. A compromise of the Timelock's governance mechanism could lead to unauthorized upgrades or manipulation of cross-chain functionality.

Fix

Ensure the Timelock governance mechanism is robust, well-tested, and follows best practices for decentralized decision-making. Implement strict access controls and multi-signature requirements for any actions that can modify the Timelock's configuration or execute proposals. Regularly audit the Timelock contract itself for vulnerabilities.

Status

Unresolved

Medium

Dependency on LayerZero Protocol Security

The contract's core functionality, particularly its cross-chain transfer capabilities as an Omnichain Fungible Token (OFT), is entirely dependent on the security, liveness, and correct operation of the LayerZero protocol and its endpoint. Any vulnerabilities, compromises, or operational failures within the LayerZero network or its endpoint contracts could directly impact the integrity, availability, and security of the L2TokenUpgradeable's cross-chain operations, potentially leading to loss of funds or service disruption.M-01

Issue

The contract's core functionality, particularly its cross-chain transfer capabilities as an Omnichain Fungible Token (OFT), is entirely dependent on the security, liveness, and correct operation of the LayerZero protocol and its endpoint. Any vulnerabilities, compromises, or operational failures within the LayerZero network or its endpoint contracts could directly impact the integrity, availability, and security of the L2TokenUpgradeable's cross-chain operations, potentially leading to loss of funds or service disruption.

Fix

Acknowledge and monitor the inherent risks associated with external protocol dependencies. Implement robust monitoring for LayerZero endpoint health, message delivery, and any security announcements from the LayerZero team. Consider contingency plans for extreme scenarios involving LayerZero disruptions, if feasible.

Status

Unresolved

Low

Hardcoded LayerZero Storage Slot

The OAppCoreUpgradeable contract uses a hardcoded storage slot (OAPP_CORE_STORAGE_LOCATION) for its peers mapping. While this is a common and often necessary pattern in upgradeable contracts to ensure consistent storage layout across upgrades and complex inheritance hierarchies, incorrect calculation or accidental collision with other storage variables (especially in contracts with multiple inheritance paths) could lead to critical state corruption or unexpected behavior. Assuming LayerZero's calculation is robust, the risk is low.L-01

Issue

The OAppCoreUpgradeable contract uses a hardcoded storage slot (OAPP_CORE_STORAGE_LOCATION) for its peers mapping. While this is a common and often necessary pattern in upgradeable contracts to ensure consistent storage layout across upgrades and complex inheritance hierarchies, incorrect calculation or accidental collision with other storage variables (especially in contracts with multiple inheritance paths) could lead to critical state corruption or unexpected behavior. Assuming LayerZero's calculation is robust, the risk is low.

Fix

Verify that the hardcoded storage slot calculation is unique and does not conflict with any other storage variables in the inheritance chain of L2TokenUpgradeable. While this is typically handled by library developers, a thorough understanding of the storage layout is crucial for upgradeable contracts.

Status

Unresolved

Info

Missing Event for setDelegate Function

The setDelegate function in OAppCoreUpgradeable allows the owner to change the delegate address on the LayerZero endpoint. However, this function does not emit an event upon successful execution. The absence of an event makes it challenging for off-chain systems, such as block explorers, monitoring tools, or user interfaces, to track changes to the delegate address, potentially hindering transparency and auditability.I-01

Issue

The setDelegate function in OAppCoreUpgradeable allows the owner to change the delegate address on the LayerZero endpoint. However, this function does not emit an event upon successful execution. The absence of an event makes it challenging for off-chain systems, such as block explorers, monitoring tools, or user interfaces, to track changes to the delegate address, potentially hindering transparency and auditability.

Fix

Consider adding an event, such as DelegateSet(address indexed oldDelegate, address indexed newDelegate), to the setDelegate function. Emitting events for critical state changes enhances transparency, allows for easier off-chain monitoring, and improves the overall auditability of the contract's administrative actions.

Status

Unresolved

Analysis

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

The L2TokenUpgradeable contract implements an ERC-20 token with LayerZero Omnichain Fungible Token (OFT) capabilities and UUPS upgradeability. It leverages standard OpenZeppelin and LayerZero upgradeable patterns. The owner, a Timelock, holds significant administrative power, including upgrades and LayerZero configurations. The audit identified a high-level concern regarding centralized control, a medium-level concern regarding external dependencies, and minor informational findings.

Technical8/10Low risk

The contract utilizes well-audited OpenZeppelin and LayerZero upgradeable libraries, providing a robust foundation for ERC-20, permit, and cross-chain functionalities (7.1 Architecture, 7.2 Code Security). The use of explicit storage slots for LayerZero components is a common pattern for upgradeable contracts, aiming to prevent storage collisions. However, the contract's core cross-chain functionality is entirely dependent on the LayerZero protocol's security and operational integrity (7.6 External), introducing a significant external dependency risk.

Governance2/10High risk

The contract employs an Ownable access control pattern where a single address, identified as a Timelock, holds all administrative privileges (7.3 Access Control). This owner can manage LayerZero peer configurations and delegate settings, centralizing control over critical cross-chain parameters. While this centralization is a risk, the use of a Timelock for the owner mitigates immediate malicious actions and provides a delay for critical operations (7.5 Governance).

Upgrades3/10High risk

The contract implements the UUPS upgradeability pattern, allowing for future logic updates (7.7 Upgrades). The _authorizeUpgrade function is correctly restricted to the onlyOwner modifier, ensuring that only the designated Timelock can initiate upgrades. This standard approach, combined with the Timelock, provides a secure and controlled upgrade path, reducing the risk of unauthorized or rushed upgrades.

Final RecommendationWhat to do about this score

It is recommended to maintain robust operational security practices around the Timelock owner address, including secure key management and multi-signature requirements.

Continuous monitoring of LayerZero endpoint configurations and cross-chain message flows is advisable to detect any anomalies. For future enhancements, consider implementing events for all critical state changes, such as setDelegate, to improve transparency and off-chain monitoring capabilities.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkBNB Chain
Token age26d
Contract0x9999…9999
Deployer0xc1ab…6b52
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Badge for your website
Cap 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. Sep 4, 202657Medium
  2. Jul 23, 202655Medium
  3. Jul 23, 202670High
  4. Jul 23, 202659Medium

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

Related Audits

6 more on the recordAll audits
UnibaseUB · BNB Chain57MediumVELOBNB Chain57MediumGriotBNB Chain57MediumAEGIS XAGX · BNB Chain57MediumDarkexBNB Chain57MediumSTABLEBNB Chain56Medium

Would You Like a More Detailed Audit of Cap?

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