Quantum Audit Logo
Launch App

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

Is Billion Zone Xchange Safe?

ZBXBNB Chain
Not 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 →
Last checked Sep 4, 2026 · 1 audit on record
SummaryAI Copilot

This audit covers the provided Solidity source code for the BillionZoneXchange token.

Read the full analysis
What raised the score
  • Top-10 concentration > 70%
  • Liquidity < $50k
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 70% (80.2% total → 72.4% effective; 67.2% in EOAs, 13.1% in contracts — extreme)
  • Liquidity < $50k ($18,223 across 1 pairs — thin market)
  • 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 Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
13.1%Contracts67.2%Wallets19.8%Everyone else
13.1%Contracts67.2%Wallets19.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
80.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking13.1%
  • Walletsanonymous holders, free to sell67.2%
  • Everyone elsethe rest of the supply19.8%
Effective concentrationwhat the score reads72.4%
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$18.2K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$18.2KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0x02ad…b9d0

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

Security Findings

1 High1 Medium1 Low1 Info
High

Truncated Source Code Prevents Comprehensive Audit

The provided source code for the ZBX.sol contract is truncated, specifically after the import statement. This prevents a complete and thorough security audit of any custom logic, state variables, function overrides, or specific tokenomics implemented within the BillionZoneXchange token. Without the full code, it is impossible to identify potential vulnerabilities such as reentrancy, logic errors, access control flaws in custom functions, or economic exploits unique to this contract's design.H-01

Issue

The provided source code for the ZBX.sol contract is truncated, specifically after the import statement. This prevents a complete and thorough security audit of any custom logic, state variables, function overrides, or specific tokenomics implemented within the BillionZoneXchange token. Without the full code, it is impossible to identify potential vulnerabilities such as reentrancy, logic errors, access control flaws in custom functions, or economic exploits unique to this contract's design.

Fix

Provide the complete and untruncated source code for the ZBX.sol contract to enable a comprehensive security audit. This is crucial for identifying and mitigating any vulnerabilities specific to the custom implementation.

Status

Unresolved

Medium

Implications of Renounced Ownership

The Ownable contract's ownership has been renounced, meaning the owner address is now address(0). While this decentralizes control and prevents a single entity from executing owner-only malicious actions (e.g., unauthorized minting if such functions were exposed), it also renders any administrative functions that rely on onlyOwner modifier permanently inaccessible. If the contract was designed with any critical owner-controlled features (e.g., pausing, fee adjustments, or emergency upgrades), these are now disabled, potentially limiting the protocol's ability to respond to unforeseen circumstances or future needs.M-01

Issue

The Ownable contract's ownership has been renounced, meaning the owner address is now address(0). While this decentralizes control and prevents a single entity from executing owner-only malicious actions (e.g., unauthorized minting if such functions were exposed), it also renders any administrative functions that rely on onlyOwner modifier permanently inaccessible. If the contract was designed with any critical owner-controlled features (e.g., pausing, fee adjustments, or emergency upgrades), these are now disabled, potentially limiting the protocol's ability to respond to unforeseen circumstances or future needs.

Fix

Ensure that all necessary administrative functions were either removed, made public, or designed to be self-sufficient before ownership renouncement. For future projects, if administrative control is desired, consider using a multi-signature wallet or a time-locked governance mechanism instead of renouncing ownership, or clearly document the implications of renouncement for all stakeholders.

Status

Unresolved

Low

Lack of Emergency Pausability

The standard ERC20 contract, as implemented, does not include a mechanism to pause token transfers or other critical operations. In the event of a major vulnerability in an integrated DeFi protocol, a market manipulation attack, or other unforeseen emergencies, the inability to pause could lead to cascading losses or further exploitation. Given that ownership is renounced, adding such a mechanism post-deployment is not possible.L-01

Issue

The standard ERC20 contract, as implemented, does not include a mechanism to pause token transfers or other critical operations. In the event of a major vulnerability in an integrated DeFi protocol, a market manipulation attack, or other unforeseen emergencies, the inability to pause could lead to cascading losses or further exploitation. Given that ownership is renounced, adding such a mechanism post-deployment is not possible.

Fix

For future token designs, consider integrating a pausable mechanism (e.g., OpenZeppelin's Pausable contract) if the token is intended for use in complex DeFi ecosystems where emergency intervention might be necessary. This feature should be carefully designed with appropriate access controls (e.g., multi-signature or governance-controlled) to prevent abuse.

Status

Unresolved

Info

Standard OpenZeppelin Contract Usage

The core functionality of the token, including its ERC20 standard compliance and ownership management, is derived from well-audited and widely used OpenZeppelin contracts (ERC20.sol and Ownable.sol). These contracts have undergone extensive security reviews and battle-testing, significantly reducing the likelihood of common vulnerabilities such as reentrancy, integer overflows/underflows, or basic access control bypasses within their scope.I-01

Issue

The core functionality of the token, including its ERC20 standard compliance and ownership management, is derived from well-audited and widely used OpenZeppelin contracts (ERC20.sol and Ownable.sol). These contracts have undergone extensive security reviews and battle-testing, significantly reducing the likelihood of common vulnerabilities such as reentrancy, integer overflows/underflows, or basic access control bypasses within their scope.

Fix

Continue to leverage established and audited libraries like OpenZeppelin for foundational contract components. Regularly review for updates and security patches to these libraries.

Status

Resolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

This audit covers the provided Solidity source code for the BillionZoneXchange token. The core contract logic is based on OpenZeppelin's Ownable and ERC20 implementations, which are well-audited and robust. However, the custom ZBX.sol contract was truncated, preventing a comprehensive analysis of its specific functionalities and potential custom vulnerabilities. Key findings include the implications of renounced ownership and the absence of emergency pause mechanisms. The contract is not upgradeable.

Technical9/10Low risk

The technical architecture (7.1) is a standard ERC20 token inheriting from OpenZeppelin's Ownable and ERC20 contracts, which are highly secure and widely adopted. Code security (7.2) benefits from the robust OpenZeppelin base, including safe use of unchecked blocks for gas optimization. However, the truncated ZBX.sol source code is a significant limitation, preventing a full assessment of any custom logic, potential reentrancy, or integer overflow/underflow vulnerabilities beyond the standard ERC20 implementation. Without the complete code, a thorough review of custom functions and their interactions is impossible.

Governance4/10Medium risk

The contract's access control (7.3) is managed by OpenZeppelin's Ownable pattern. The ownership has been renounced, which decentralizes control and eliminates the risk of a single owner performing malicious actions (e.g., unauthorized minting if such functions were owner-controlled). This design choice, however, means that no administrative functions can be executed post-renouncement, which could be a concern if future governance (7.5) or operational (7.8) changes were ever intended. The economic model (7.4) appears to be a standard ERC20 token, implying simple and predictable tokenomics, though specific details are unknown due to truncated code.

Upgrades10/10Low risk

The contract is not designed as a proxy (7.7) and is therefore not upgradeable. This eliminates all risks associated with upgrade mechanisms, such as proxy implementation vulnerabilities, storage collisions, or insecure upgrade paths. The immutability provides certainty regarding the contract's code and behavior post-deployment.

Final RecommendationWhat to do about this score

To ensure the highest level of security assurance, it is strongly recommended to provide the complete and untruncated source code for the ZBX.sol contract.

This would enable a full audit of any custom logic, tokenomics, and interactions, allowing for a comprehensive assessment of potential vulnerabilities. For future projects, carefully consider the implications of renouncing ownership, especially if any administrative functions (like pausing or emergency upgrades) might be required. If such controls are deemed necessary, implement them with robust multi-signature or time-locked mechanisms before renouncing ownership.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age26d
Contract0x9672…c81c
Deployer0xefa4…b25c
Badge for your website
Billion Zone Xchange security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202628Low
  2. Aug 13, 202621Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Would You Like a More Detailed Audit of Billion Zone Xchange?

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