Quantum Audit Logo

Is Cap Safe?

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

Is this your token? Publish your own audit on this page →

Cap CAP
0x9999…9999
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low1 Informational
Volume 24h
$161.8K
Liquidity
$20.1K
Price
$0.05463
Token Age
26d
Top 10 Holders
98.2%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control by Owner

H-01The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Medium

Dependency on LayerZero Protocol Security

M-01The 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.
IssueThe 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.
FixAcknowledge 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.
StatusUnresolved
Low

Hardcoded LayerZero Storage Slot

L-01The `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.
IssueThe `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.
FixVerify 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.
StatusUnresolved
Info

Missing Event for `setDelegate` Function

I-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh2/10

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

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source

Holder Composition

98.2% in top 10
7.7% in wallets90.5% in contracts
Effective Concentration43.9%

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.9K across 4 pairs
UniswapUSDTanalysed$20.1K96.4%Pancakeswap v3WBNB$6783.2%UniswapUSDT$810.4%Pancakeswap v3USDT$30.0%

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

5 addresses
Deployer
0xc1ab…6b52
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.

What Raised This Score

11 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

Related Audits

6 more on the record
Unibase (UB)High RiskVELOHigh RiskGriotHigh RiskSTABLEHigh RiskOLYHigh RiskSlap Cat (SLAP)High Risk

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