Quantum Audit Logo

Is LayerZero Safe?

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

LayerZero ZRO
0x6985…71cd
Arbitrum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The LayerZeroToken contract is an Omnichain Fungible Token (OFT) built on LayerZero v2, inheriting from OpenZeppelin's Ownable. It facilitates cross-chain token transfers. The contract's design follows standard LayerZero patterns, leveraging battle-tested libraries. The initial owner is a 3/5 multisig, which significantly enhances access control security.

1 Medium1 Low3 Informational
Volume 24h
$46.8K
Liquidity
$84.4K
Price
$1.1500
Token Age
2y
Top 10 Holders
50.4%

Security Findings

1 Med1 Low3 Info
Medium

Centralized Control by Owner

M-01The contract owner (initialized by `_delegate`) possesses significant administrative privileges, including the ability to call `setPeer` and `setDelegate`. These functions are critical for the cross-chain functionality of the OFT, allowing the owner to define which external contracts can interact with this token across chains and to change the LayerZero endpoint's delegate. While the owner is a 3/5 multisig, these privileges are still substantial.
IssueThe contract owner (initialized by `_delegate`) possesses significant administrative privileges, including the ability to call `setPeer` and `setDelegate`. These functions are critical for the cross-chain functionality of the OFT, allowing the owner to define which external contracts can interact with this token across chains and to change the LayerZero endpoint's delegate. While the owner is a 3/5 multisig, these privileges are still substantial.
FixWhile the owner is a multisig, which mitigates risk, it is crucial to ensure the multisig's security and operational procedures are robust. Consider implementing time-locks for critical administrative actions to provide a window for community review or emergency intervention, further decentralizing control over time.
StatusUnresolved
Low

Potential for Operational Misconfiguration

L-01The `setPeer` function, callable by the owner, allows configuring the `bytes32 peer` for a given `uint32 eid`. An incorrect `peer` address or `eid` could lead to cross-chain messages failing or being routed incorrectly, causing operational disruption for token transfers. This is an operational risk rather than a code vulnerability.
IssueThe `setPeer` function, callable by the owner, allows configuring the `bytes32 peer` for a given `uint32 eid`. An incorrect `peer` address or `eid` could lead to cross-chain messages failing or being routed incorrectly, causing operational disruption for token transfers. This is an operational risk rather than a code vulnerability.
FixImplement robust operational procedures and thorough testing for any changes to `peer` configurations. Consider adding a mechanism (e.g., a two-step process or a delay) for critical configuration changes to prevent immediate adverse effects from human error.
StatusUnresolved
Info

Reliance on External LayerZero Endpoint Security

I-01The `LayerZeroToken` contract is inherently dependent on the security and correct functioning of the LayerZero Endpoint V2 contract. All cross-chain messaging and fee payments are routed through this external endpoint. Any vulnerability, misconfiguration, or compromise of the LayerZero Endpoint could directly impact the functionality and security of the `LayerZeroToken`.
IssueThe `LayerZeroToken` contract is inherently dependent on the security and correct functioning of the LayerZero Endpoint V2 contract. All cross-chain messaging and fee payments are routed through this external endpoint. Any vulnerability, misconfiguration, or compromise of the LayerZero Endpoint could directly impact the functionality and security of the `LayerZeroToken`.
FixWhile this is an inherent dependency of using LayerZero, it is important for the protocol to continuously monitor the security posture and operational status of the LayerZero infrastructure and any updates or advisories they release.
StatusUnresolved
Info

Non-Upgradeability Requires Redeployment for Changes

I-02The `LayerZeroToken` contract is deployed as a standard, non-upgradeable contract. This means that any future bug fixes, feature enhancements, or protocol changes would require deploying an entirely new contract and migrating all existing token holders and liquidity. This can be a complex and costly process.
IssueThe `LayerZeroToken` contract is deployed as a standard, non-upgradeable contract. This means that any future bug fixes, feature enhancements, or protocol changes would require deploying an entirely new contract and migrating all existing token holders and liquidity. This can be a complex and costly process.
FixAcknowledge the implications of non-upgradeability. For future versions or other protocol components, consider if an upgradeable proxy pattern (e.g., UUPS) would be more suitable if flexibility and future-proofing are desired, weighing the benefits against the added complexity and potential risks of upgradeability.
StatusUnresolved
Info

LZ Token Availability Check

I-03The `_payLzToken` function explicitly checks if `endpoint.lzToken()` returns `address(0)` and reverts with `LzTokenUnavailable()` if it does. This indicates that the LayerZero endpoint might not always have an associated LZ token for fee payments, or it might be configurable.
IssueThe `_payLzToken` function explicitly checks if `endpoint.lzToken()` returns `address(0)` and reverts with `LzTokenUnavailable()` if it does. This indicates that the LayerZero endpoint might not always have an associated LZ token for fee payments, or it might be configurable.
FixEnsure clear documentation and operational understanding of when and how LZ token payments are expected or required, and the implications if the LZ token is unavailable for cross-chain transactions. This helps in managing user expectations and troubleshooting.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is sound, utilizing the LayerZero v2 OApp framework and OpenZeppelin's Ownable for access control. Code security (7.2) benefits from Solidity 0.8.x's default overflow/underflow checks and SafeERC20 for token interactions. Access control (7.3) is well-defined with onlyOwner modifiers for critical functions like setPeer and setDelegate, and robust checks in lzReceive for endpoint and peer validation. No direct reentrancy or other severe code vulnerabilities were identified in the provided snippets.

GovernanceMedium5/10

The governance and economic model (7.5, 7.4) centers around the _delegate address, which is the contract owner. This owner has administrative control over LayerZero configurations, such as setting cross-chain peers and the endpoint delegate. The use of a 3/5 multisig for the owner (7.8 Operations) is a strong security measure, distributing control and reducing the risk of a single point of failure or malicious action. However, the owner's extensive privileges still represent a centralized point of control.

UpgradesLow7/10

The LayerZeroToken contract is deployed as a standard, non-upgradeable implementation (7.7). This eliminates risks associated with proxy patterns, such as storage collisions or incorrect upgrade logic. However, any future protocol changes or bug fixes would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex and costly process.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

50.4% in top 10
48.1% in wallets2.3% in contracts
Effective Concentration49.0%

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

$155.4K across 9 pairs
UniswapWETHanalysed$84.4K54.3%UniswapWETH$21.0K13.5%Camelot v3WETH$19.5K12.6%UniswapUSD₮0$10.6K6.8%UniswapUSDC$7.8K5.0%PancakeswapWETH$6.6K4.3%
Show 3 more pairsShow less
Sushiswap v3WETH$4.9K3.2%Ramses v3WETH$4820.3%UniswapARB$980.1%

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 Holder49.6%
Top-3 Unlocked88.6%

Key Addresses

11 addresses
Deployer
0xb505…e155
Unlocked LP Held By
0xb1a3…80ed0x8a81…e9b90x933b…b0690x04a1…e5af0xa984…1f590xdd66…bc180xbb93…ef5d0xf757…a5070x5c12…ff970xff18…e823

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

What Raised This Score

6 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 30% (50.4% total → 49.0% effective; 48.1% in EOAs, 2.3% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 88.6% (independent LP — depth risk, pool = 54% of DEX liquidity)
  • 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
Arbitrum (ARB)Medium RiskPendleMedium RiskChainLink Token (LINK)Medium RiskWrapped liquid staked Ether 2.0 (WSTETH)Medium RiskAave Token (AAVE)Medium RiskRAINMedium Risk

Would You Like a More Detailed Audit of LayerZero?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit