This audit focused on the provided Solidity interfaces for LayerZero V2 components, including ILayerZeroEndpointV2, ILayerZeroReceiver, and related manager interfaces. It's important to note that only interface definitions were provided, not the actual implementation logic. Therefore, the audit assesses potential risks and architectural considerations for any contract implementing these interfaces, rather than specific vulnerabilities in a deployed contract. The prefill indicated a contract named 'BasedOFT' at the given address, but the provided source code consists solely of LayerZero V2 interfaces, suggesting a mismatch in the audit scope definition. The findings highlight critical access control considerations, reentrancy risks for implementers, and the inherent complexity of cross-chain messaging.
On-chain security analysis — is it a scam or legit?
Is Based Token Safe?
BNB ChainNot 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 →This audit focused on the provided Solidity interfaces for LayerZero V2 components, including ILayerZeroEndpointV2, ILayerZeroReceiver, and related manager interfaces.
- Ownership not renounced — owner is a contract
- Mintable supply — no cap found, dilution unbounded
- 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 = 73.5%
- LP top3 unlocked holders = 100.0%
- 1 High finding(s) from audit
- 2 Medium finding(s) from audit
- 1 Low finding(s) from audit
Exact factors
- Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
- Mintable supply — no cap found, dilution unbounded
- Top-10 concentration > 30% (78.9% total → 36.0% effective; 7.4% in EOAs, 71.5% in contracts — moderate)
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- Liquidity < $50k ($15,311 across 7 pairs — thin market)
- LP top1 unlocked holder = 73.5% (independent LP — depth risk, pool = 50% of DEX liquidity)
- LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 50% of DEX liquidity)
- 1 High finding(s) from audit
- 2 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking71.5%
- Walletsanonymous holders, free to sell7.4%
- Everyone elsethe rest of the supply21.1%
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- UniswapUSDTAnalysed$7.6K50.0%
- UniswapUSDT$7.6K49.3%
- Pancakeswap v3JPF$810.5%
- Pancakeswap v3USDT$130.1%
- Pancakeswap v3USDT$60.0%
- Pancakeswap v2USDT$40.0%
Show 1 more pair
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xf6e3…1eda0xfdff…6ed7No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighCritical Access Control for Core Management Functions
The ILayerZeroEndpointV2 and IMessageLibManager interfaces expose highly sensitive functions such as setLzToken, setDelegate, registerLibrary, setDefaultSendLibrary, setReceiveLibrary, and setConfig. In an implementation, these functions control fundamental aspects of the LayerZero protocol, including token configurations, delegate permissions, and the registration/selection of message libraries. Inadequate access control (7.3 Access Control) for these functions could allow unauthorized entities to compromise the protocol, manipulate fees, or disrupt cross-chain messaging.H-01
Issue
The ILayerZeroEndpointV2 and IMessageLibManager interfaces expose highly sensitive functions such as setLzToken, setDelegate, registerLibrary, setDefaultSendLibrary, setReceiveLibrary, and setConfig. In an implementation, these functions control fundamental aspects of the LayerZero protocol, including token configurations, delegate permissions, and the registration/selection of message libraries. Inadequate access control (7.3 Access Control) for these functions could allow unauthorized entities to compromise the protocol, manipulate fees, or disrupt cross-chain messaging.
Fix
Implement robust, multi-layered access control mechanisms (e.g., Ownable2Step, multi-signature wallets, or governance contracts) for all critical management functions. Ensure that only trusted and authorized addresses can invoke these functions. Regularly review and audit the access control logic.
Status
Unresolved
MediumReentrancy Risk in lzReceive Implementations
The lzReceive function, present in both ILayerZeroEndpointV2 and ILayerZeroReceiver, is designed to handle incoming cross-chain messages. If an implementing contract performs external calls (e.g., token transfers, interactions with other contracts) based on the received message before updating its internal state, it could be vulnerable to reentrancy attacks (7.2 Code Security). An attacker could craft a malicious message to re-enter the lzReceive function or other sensitive functions, leading to unintended state changes or fund drains.M-01
lzReceive ImplementationsIssue
The lzReceive function, present in both ILayerZeroEndpointV2 and ILayerZeroReceiver, is designed to handle incoming cross-chain messages. If an implementing contract performs external calls (e.g., token transfers, interactions with other contracts) based on the received message before updating its internal state, it could be vulnerable to reentrancy attacks (7.2 Code Security). An attacker could craft a malicious message to re-enter the lzReceive function or other sensitive functions, leading to unintended state changes or fund drains.
Fix
Implement the Checks-Effects-Interactions pattern within lzReceive and any functions it calls. Ensure all state changes are completed before any external calls are made. Consider using reentrancy guards (e.g., OpenZeppelin's ReentrancyGuard) if complex interactions are unavoidable.
Status
Unresolved
MediumEconomic Attack Vectors via Fee Calculation
The quote function in ILayerZeroEndpointV2 returns MessagingFee which includes nativeFee and lzTokenFee. If the underlying implementation's fee calculation relies on external price feeds, manipulable on-chain data, or parameters that can be influenced by malicious actors, it could lead to economic exploits (7.4 Economic). Attackers might be able to artificially inflate or deflate fees, making cross-chain operations uneconomical or allowing for fund draining if fees are paid in a manipulable asset.M-02
Issue
The quote function in ILayerZeroEndpointV2 returns MessagingFee which includes nativeFee and lzTokenFee. If the underlying implementation's fee calculation relies on external price feeds, manipulable on-chain data, or parameters that can be influenced by malicious actors, it could lead to economic exploits (7.4 Economic). Attackers might be able to artificially inflate or deflate fees, making cross-chain operations uneconomical or allowing for fund draining if fees are paid in a manipulable asset.
Fix
Ensure that the fee calculation mechanism in the implementation is robust, transparent, and resistant to manipulation. If external oracles are used, integrate reputable, decentralized oracle solutions (e.g., Chainlink) with proper validation and fallback mechanisms. Regularly monitor fee parameters and their impact on the protocol's economics.
Status
Unresolved
LowLack of Emergency Mechanisms in Interfaces
The provided interfaces do not include functions for emergency pausing or circuit breakers. While interfaces define functionality, a robust implementation of a critical cross-chain protocol component (7.8 Operations) should incorporate mechanisms to halt or restrict operations in the event of a severe vulnerability, exploit, or unforeseen issue. Without such mechanisms, a critical bug could lead to irreversible damage before a fix can be deployed.L-01
Issue
The provided interfaces do not include functions for emergency pausing or circuit breakers. While interfaces define functionality, a robust implementation of a critical cross-chain protocol component (7.8 Operations) should incorporate mechanisms to halt or restrict operations in the event of a severe vulnerability, exploit, or unforeseen issue. Without such mechanisms, a critical bug could lead to irreversible damage before a fix can be deployed.
Fix
Implement emergency pause functionality (e.g., using OpenZeppelin's Pausable contract) in any concrete contract that implements these LayerZero V2 interfaces. This mechanism should be controlled by a trusted multi-signature wallet or a robust governance system.
Status
Unresolved
InfoIncomplete Audit Scope: Interfaces Only
The audit was conducted solely on Solidity interface definitions for LayerZero V2 components. No concrete implementation logic was provided or analyzed. This significantly limits the scope of the audit, as actual vulnerabilities often reside in the implementation details rather than the interface definitions themselves. The prefill also indicated a different contract name ('BasedOFT') than the provided source code (LayerZero V2 interfaces), leading to a discrepancy in the audit target.I-01
Issue
The audit was conducted solely on Solidity interface definitions for LayerZero V2 components. No concrete implementation logic was provided or analyzed. This significantly limits the scope of the audit, as actual vulnerabilities often reside in the implementation details rather than the interface definitions themselves. The prefill also indicated a different contract name ('BasedOFT') than the provided source code (LayerZero V2 interfaces), leading to a discrepancy in the audit target.
Fix
For a comprehensive security assessment, provide the full source code of the deployed or intended implementation contracts, including all dependencies. Ensure the provided source code matches the intended audit target and deployed addresses.
Status
Unresolved
InfoInherent Complexity of Cross-Chain Messaging
The LayerZero V2 protocol, as evidenced by its extensive interfaces (ILayerZeroEndpointV2, IMessageLibManager, IMessagingChannel, etc.), represents a highly complex system for secure cross-chain communication (7.1 Architecture). This inherent complexity increases the surface area for potential misconfigurations, integration errors, or subtle logical flaws in implementations. Securely building on or integrating with such a system requires deep technical understanding and meticulous attention to detail.I-02
Issue
The LayerZero V2 protocol, as evidenced by its extensive interfaces (ILayerZeroEndpointV2, IMessageLibManager, IMessagingChannel, etc.), represents a highly complex system for secure cross-chain communication (7.1 Architecture). This inherent complexity increases the surface area for potential misconfigurations, integration errors, or subtle logical flaws in implementations. Securely building on or integrating with such a system requires deep technical understanding and meticulous attention to detail.
Fix
Teams implementing or integrating with LayerZero V2 should invest in comprehensive documentation, internal code reviews, and external audits. Adopt a phased deployment strategy with extensive testing on testnets. Maintain a strong understanding of the LayerZero V2 protocol's specifications and best practices.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The LayerZero V2 interfaces define a complex cross-chain messaging architecture (7.1 Architecture) with distinct roles for endpoints, message libraries, and receivers. The design emphasizes modularity and configurability, allowing for flexible integration. However, this complexity introduces potential pitfalls for implementers, particularly regarding reentrancy in lzReceive functions (7.2 Code Security) and the secure handling of message parameters. The interfaces themselves are well-structured, but the security of the overall system heavily relies on robust and audited implementations of these interfaces.
The interfaces expose several critical functions that, in an implementation, would require strong access control and governance (7.3 Access Control, 7.5 Governance). Functions like setLzToken, setDelegate, and various library management functions (setDefaultSendLibrary, setReceiveLibrary, setConfig) directly impact the protocol's operation and economic model (7.4 Economic). Improper access control over these functions could lead to unauthorized configuration changes, fee manipulation, or denial of service. The quote function for messaging fees also presents an economic consideration, requiring a reliable and unmanipulable fee calculation mechanism.
As only interfaces were provided, direct upgradeability concerns (7.7 Upgrades) for these specific contracts are not applicable. However, the LayerZero V2 protocol itself is designed to be extensible through message libraries and configurable parameters, which implies a form of upgradeability or adaptability. Any concrete implementation of these interfaces would need to consider its own upgrade strategy, especially if it's a core component of a larger system. The modular design of message libraries could facilitate upgrades by allowing new libraries to be registered and set.
Implementers of LayerZero V2 interfaces must prioritize robust access control for all sensitive management functions, ensuring only authorized entities can make critical configuration changes.
Thorough reentrancy checks and secure coding practices are paramount for lzReceive implementations, especially when handling value transfers or external calls. Additionally, careful consideration should be given to the economic implications of fee calculations and potential oracle dependencies. Comprehensive testing, including cross-chain scenarios and edge cases, is essential before deployment. Finally, integrating emergency pause mechanisms can provide a crucial safety net for operational risks.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202678High
- Sep 4, 202675High
- Jul 23, 202677High
- Jul 22, 202667High
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the BASED contract address?
The Based Token (BASED) contract on BNB Chain is 0x1d28d989f9e3ccb8b15d0cec601734514f958e4d. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is Based Token a scam?
Quantum Audit's risk score for Based Token is 78/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Is BASED liquidity locked?
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $15.3K.
Who holds BASED?
As of Sep 4, 2026, the 10 largest holders own 78.9% of the supply. The Holders section on this page shows who they are by holder type.
Would You Like a More Detailed Audit of Based Token?
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