Is Unibase (UB) Safe? Smart Contract Security Analysis

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2270Jul 2357

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

Audit Summary

This audit reviews the provided Solidity interface definitions for LayerZero V2. As only interfaces were provided, the scope is limited to design patterns, potential integration risks, and general security considerations for systems implementing these cross-chain communication primitives. The provided contract address likely refers to a concrete implementation of these interfaces. No executable contract logic was available for direct vulnerability analysis.

Final Recommendation: Implementers of these LayerZero V2 interfaces must prioritize robust access control for all administrative functions, ideally utilizing multi-signature wallets or a well-defined governance process. Thoroughly audit all custom logic built upon these interfaces, especially message handling (`lzReceive`, `verify`) and economic parameter management (`quote`, `send`). Comprehensive testing, including cross-chain simulations, is critical to ensure the integrity and security of the overall system.

Category Ratings

TechnicalLow

8/10

The LayerZero V2 interfaces define a robust and modular framework for cross-chain communication, leveraging distinct components for message management, composition, and channel handling (7.1 Architecture). The design promotes flexibility through configurable message libraries and explicit lifecycle

GovernanceHigh

3/10

The interfaces expose numerous critical administrative functions, such as `setLzToken`, `setDefaultSendLibrary`, `setReceiveLibrary`, and `setConfig`, which directly impact the system's operational parameters and security (7.3 Access Control, 7.5 Governance). The economic model involves quoting

UpgradesLow

7/10

As interfaces, these contracts are not directly upgradeable. However, any concrete contract implementing these LayerZero V2 interfaces would require a well-designed upgrade mechanism (7.7 Upgrades), such as a proxy pattern (e.g., UUPS), to allow for future enhancements or bug fixes. The modular natu

LP Distribution

Top-1 Unlocked Holder99.3%

Top-3 Unlocked100.0%

What Raised This Score

8 factors

Ownership NOT renounced — strong Multisig (3-of-5)
Top-10 concentration > 30% (70.9% total → 35.0% effective; 11.0% in EOAs, 59.9% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.3% (independent LP — depth risk, pool = 96% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
1 High finding(s) from audit
3 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

6 total

1 High 3 Medium 1 Low 1 Info

H-01HighUnresolved

Critical Access Control for Administrative Functions

The LayerZero V2 interfaces define numerous functions that can alter the behavior or economic parameters of the LayerZero endpoint (e.g., `setLzToken`, `setDelegate`, `registerLibrary`, `setDefaultSendLibrary`, `setDefaultReceiveLibrary`, `setConfig`). Without proper access control implemented in the concrete contract, these functions could be exploited by unauthorized entities, leading to misconfiguration, denial of service, or theft of funds. The interfaces themselves do not enforce any access control.

Recommendation: All administrative functions in the implementing contract must be protected by robust access control mechanisms, such as `onlyOwner`, `onlyRole`, or multi-signature wallet control. Access should be granted on a least-privilege basis.

M-01MediumUnresolved

Complexity and Implementation Risk

The LayerZero V2 interfaces expose a highly modular and configurable system for cross-chain communication. While flexible, this complexity increases the likelihood of implementation errors in concrete OApp contracts. Misunderstanding the message lifecycle (`send`, `verify`, `lzReceive`, `clear`, `skip`, `nilify`, `burn`) or configuration parameters could lead to vulnerabilities like message loss, replay attacks, or unintended state changes.

Recommendation: Implementers should thoroughly understand the LayerZero V2 documentation and best practices. Extensive unit, integration, and cross-chain testing is crucial. Consider formal verification for critical message handling logic to ensure correctness.

M-02MediumUnresolved

Economic Parameter Manipulation Risk

Functions like `quote` and `send` involve `MessagingFee` (native and LZ token fees). The `setLzToken` function allows changing the LZ token. If the logic for calculating or accepting fees in the implementing contract is flawed, or if `setLzToken` is compromised, it could lead to economic exploits, such as users paying incorrect fees or attackers manipulating the system for profit.

Recommendation: Ensure fee calculation logic in the implementing contract is robust and resistant to manipulation. Implement strict validation for `_params.options` and `_refundAddress`. Access to `setLzToken` must be highly restricted and subject to strong governance.

M-03MediumUnresolved

External Dependency Risk

The security of any system built on LayerZero V2 inherently depends on the security and liveness of the underlying LayerZero network, including its relayer infrastructure and oracle mechanisms. While the interfaces define the interaction points, they do not mitigate risks stemming from potential compromises or failures within the LayerZero protocol itself (7.6 External).

Recommendation: OApp developers should be aware of the trust assumptions and potential failure modes of the LayerZero protocol. Implement robust monitoring for LayerZero network status and consider emergency shutdown or pause mechanisms if critical external dependencies fail or exhibit malicious behavior.

L-01LowUnresolved

Delegate Pattern Implications

The `setDelegate` function allows an address to delegate its authority. While useful for operational flexibility, if not managed carefully, a compromised delegate address could perform unauthorized actions on behalf of the delegator, potentially leading to unintended consequences.

Recommendation: Implementers should ensure that the delegate pattern is used judiciously and that delegated addresses are highly trusted and secured. Consider time-bound delegations or granular permissions for delegates to limit potential impact.

I-01InformationalUnresolved

Grace Periods and Timeouts Management

Functions like `setDefaultReceiveLibraryTimeout` and `setReceiveLibraryTimeout` introduce time-based controls for library transitions. While beneficial for graceful upgrades and mitigating immediate risks, incorrect management of these timeouts (e.g., setting excessively long or short periods) could either delay critical security updates or create windows of vulnerability.

Recommendation: Implementers should carefully consider the appropriate grace periods and timeouts based on their operational needs and risk tolerance. Ensure that the process for managing these timeouts is well-defined, transparent, and secure.

Is Unibase Safe? UB