Is Cap Safe? Smart Contract Security Analysis

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Audit History

3 audits on record

Jul 2359Jul 2370Jul 2355

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: 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.

Category Ratings

TechnicalLow

8/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

GovernanceHigh

2/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. W

UpgradesHigh

3/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

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

What Raised This Score

11 factors

Ownership NOT renounced — Timelock 24h delay
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 30% (91.8% total → 38.8% effective; 3.4% in EOAs, 88.4% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k ($27,563 across 5 pairs — thin market)
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 83% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 83% 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 Findings

4 total

1 High 1 Medium 1 Low 1 Info

H-01HighUnresolved

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.

Recommendation: 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.

M-01MediumUnresolved

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.

Recommendation: 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.

L-01LowUnresolved

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.

Recommendation: 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.

I-01InformationalUnresolved

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.

Recommendation: 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.

Is Cap Safe? CAP