Quantum Audit Logo
Launch App

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

Is Billions Network Token Safe?

BILLBNB 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
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades4/10Checks passed2 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The audit of the BillOFT contract, an upgradeable LayerZero Omnichain Fungible Token (OFT) implementation, identified a high-severity architectural deviation in its ownership pattern, where a multisig directly owns the implementation instead of the ProxyAdmin.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Proxy contract
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top3 unlocked holders = 84.8%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (91.9% total → 77.1% effective; 67.2% in EOAs, 24.7% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($21,908 across 6 pairs — thin market)
  • LP top3 unlocked holders = 84.8% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
24.7%Contracts67.2%Wallets8.1%Everyone else
24.7%Contracts67.2%Wallets8.1%
ContractsWalletsEveryone elseBubble area = share of supply
91.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking24.7%
  • Walletsanonymous holders, free to sell67.2%
  • Everyone elsethe rest of the supply8.1%
Effective concentrationwhat the score reads77.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$21.9K across 6 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$21.9KShare of depth99.8%
Top-1 Unlocked Holder44.4%
Top-3 Unlocked84.8%
Unlocked LP held by
0xaa3e…fc430xa714…27000xe59a…f5240x8e0a…76c10xce13…f41c0xbefc…550e0xbf47…7a1b0x89e8…805e0xf78d…a49e

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

Non-Standard Ownership Pattern for Transparent Upgradeable Proxy

The initialize function calls __Ownable_init(_delegate), and based on the prefill data, the _delegate address (a 3/5 multisig) has been set as the direct owner of the BillOFT implementation contract. For a TransparentUpgradeableProxy, the standard and recommended pattern is for the ProxyAdmin contract to be the owner of the implementation. This allows the ProxyAdmin to manage upgrades and other owner-restricted functions on the implementation, while the ProxyAdmin itself is owned by a secure entity (like a multisig). By directly assigning ownership of the implementation to the multisig, the ProxyAdmin's role in managing the implementation's owner-restricted functions is bypa…H-01

Issue

The initialize function calls __Ownable_init(_delegate), and based on the prefill data, the _delegate address (a 3/5 multisig) has been set as the direct owner of the BillOFT implementation contract. For a TransparentUpgradeableProxy, the standard and recommended pattern is for the ProxyAdmin contract to be the owner of the implementation. This allows the ProxyAdmin to manage upgrades and other owner-restricted functions on the implementation, while the ProxyAdmin itself is owned by a secure entity (like a multisig). By directly assigning ownership of the implementation to the multisig, the ProxyAdmin's role in managing the implementation's owner-restricted functions is bypa…

Fix

Reconfigure the ownership such that the ProxyAdmin contract is the owner of the BillOFT implementation. The initialize function should call __Ownable_init() (without arguments), which would set the ProxyAdmin (as msg.sender during initialization) as the owner. The multisig should then own the ProxyAdmin contract, maintaining secure control over the upgrade process. This aligns with the intended security model of TransparentUpgradeableProxies.

Status

Unresolved

Medium

Centralized Control by Multisig Owner

The BillOFT contract's owner is a 3/5 multisig, which holds significant control over critical functions, including potential LayerZero configurations and any future owner-restricted methods. While a multisig reduces single points of failure, it still represents a centralized entity that could, if compromised or malicious, exert undue influence over the token's operations.M-01

Issue

The BillOFT contract's owner is a 3/5 multisig, which holds significant control over critical functions, including potential LayerZero configurations and any future owner-restricted methods. While a multisig reduces single points of failure, it still represents a centralized entity that could, if compromised or malicious, exert undue influence over the token's operations.

Fix

Implement time-locks for critical administrative actions to provide a delay for users to react to potentially malicious or erroneous operations. Consider further decentralizing control over time, if feasible, by integrating governance mechanisms or distributing ownership among a wider set of stakeholders.

Status

Unresolved

Low

Reliance on External LayerZero Protocol Security

The BillOFT contract is an Omnichain Fungible Token (OFT) built on LayerZero, meaning its cross-chain functionality and security are inherently dependent on the LayerZero protocol. Any vulnerabilities, exploits, or operational failures within the LayerZero endpoint, relayer network, or oracle mechanisms could directly impact the integrity and availability of cross-chain token transfers for BillOFT.L-01

Issue

The BillOFT contract is an Omnichain Fungible Token (OFT) built on LayerZero, meaning its cross-chain functionality and security are inherently dependent on the LayerZero protocol. Any vulnerabilities, exploits, or operational failures within the LayerZero endpoint, relayer network, or oracle mechanisms could directly impact the integrity and availability of cross-chain token transfers for BillOFT.

Fix

While this is an inherent risk of using a bridging solution, it is crucial to monitor LayerZero's security announcements, audits, and operational status. Users should be made aware of the underlying cross-chain dependency and its associated risks.

Status

Unresolved

Info

Redundant or Conflicting Ownable Import

The BillOFT contract explicitly imports Ownable from @openzeppelin/contracts/access/Ownable.sol. However, BillOFT inherits OFTUpgradeable, which itself inherits OwnableUpgradeable. This creates a potentially redundant or conflicting import, as OwnableUpgradeable is the correct version for upgradeable contracts. While it might not cause a direct runtime error if the compiler resolves it correctly, it can lead to confusion and potential misapplication of Ownable functions or initialization patterns.I-01

Issue

The BillOFT contract explicitly imports Ownable from @openzeppelin/contracts/access/Ownable.sol. However, BillOFT inherits OFTUpgradeable, which itself inherits OwnableUpgradeable. This creates a potentially redundant or conflicting import, as OwnableUpgradeable is the correct version for upgradeable contracts. While it might not cause a direct runtime error if the compiler resolves it correctly, it can lead to confusion and potential misapplication of Ownable functions or initialization patterns.

Fix

Remove the explicit import { Ownable } from "@openzeppelin/contracts/access/Ownable.sol"; statement. Rely on the OwnableUpgradeable inheritance provided by OFTUpgradeable to ensure consistent and correct usage of access control for an upgradeable contract.

Status

Unresolved

Analysis

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

The audit of the BillOFT contract, an upgradeable LayerZero Omnichain Fungible Token (OFT) implementation, identified a high-severity architectural deviation in its ownership pattern, where a multisig directly owns the implementation instead of the ProxyAdmin. Other findings include centralized control inherent to multisig ownership and dependency on LayerZero protocol security. The contract leverages well-audited OpenZeppelin and LayerZero libraries.

Technical6/10Medium risk

The BillOFT contract is a minimal wrapper around the OFTUpgradeable and Ownable libraries, which are generally well-audited. The core logic for token functionality and cross-chain transfers is handled by the LayerZero OFT standard. A high-severity architectural deviation was identified in the ownership pattern (7.3 Access Control), where the multisig directly owns the implementation, bypassing the standard ProxyAdmin role for owner-restricted functions. Additionally, a minor informational issue regarding redundant Ownable imports was noted (7.2 Code Security).

Governance1/10High risk

The contract exhibits centralized control (7.5 Governance) through a 3/5 multisig owner, which manages critical administrative functions and upgrades. While a multisig enhances security over a single EOA, it still represents a central point of authority. The project's economic model (7.4 Economic) is tied to the LayerZero protocol, inheriting its security and operational risks for cross-chain token transfers (7.6 External).

Upgrades4/10Medium risk

The contract utilizes a TransparentUpgradeableProxy pattern (7.7 Upgrades) with an OpenZeppelin ProxyAdmin, which is owned by a 3/5 multisig, providing a robust upgrade mechanism. The _disableInitializers() and initializer modifier are correctly used in the implementation to prevent re-initialization. However, the direct ownership of the implementation by the multisig, rather than the ProxyAdmin, deviates from the standard and recommended Transparent Proxy architecture, potentially complicating future upgrade management or access control interactions (7.1 Architecture).

Final RecommendationWhat to do about this score

It is strongly recommended to reconfigure the ownership of the BillOFT implementation contract to align with the standard TransparentUpgradeableProxy pattern, where the ProxyAdmin contract acts as the owner.

This ensures proper separation of concerns and adherence to established security best practices for upgradeable contracts. Additionally, consider implementing time-locks for critical administrative actions to enhance security and provide a buffer for user response.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBNB Chain
Token age3mo
Contract0xdf24…1fa5
Deployer0xae15…9d74
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source
Badge for your website
Billions Network Token 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, 202668High
  2. Aug 12, 202663Medium

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

Related Audits

6 more on the recordAll audits
HemiBNB Chain68HighAntFunBNB Chain68HighUniswapUNI · BNB Chain68HighReservoirDAM · BNB Chain68HighQuack AI TokenQ · BNB Chain67HighHoloworld AIHOLO · BNB Chain67High

Would You Like a More Detailed Audit of Billions Network 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