Quantum Audit Logo

Is Billions Network Token Safe?

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

Is this your token? Publish your own audit on this page →

Billions Network Token BILL
0xdf24…1fa5
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive 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. Other findings include centralized control inherent to multisig ownership and dependency on LayerZero protocol security. The contract leverages well-audited OpenZeppelin and LayerZero libraries.

1 High1 Medium1 Low1 Informational
Volume 24h
$370.8900
Liquidity
$21.9K
Price
$0.01549
Token Age
3mo
Top 10 Holders
91.9%

Security Findings

1 High1 Med1 Low1 Info
High

Non-Standard Ownership Pattern for Transparent Upgradeable Proxy

H-01The `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…
IssueThe `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…
FixReconfigure 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.
StatusUnresolved
Medium

Centralized Control by Multisig Owner

M-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Low

Reliance on External LayerZero Protocol Security

L-01The `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.
IssueThe `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.
FixWhile 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.
StatusUnresolved
Info

Redundant or Conflicting Ownable Import

I-01The `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.
IssueThe `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.
FixRemove 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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).

GovernanceHigh1/10

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).

UpgradesMedium4/10

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).

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source

Holder Composition

91.9% in top 10
67.2% in wallets24.7% in contracts
Effective Concentration77.1%

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

$21.9K across 6 pairs
UniswapUSDTanalysed$21.9K99.8%Pancakeswap v3USDT$230.1%UniswapUSDC$100.0%Pancakeswap v3USDT$90.0%Pancakeswap v3USDT$40.0%Pancakeswap v2USDT$00.0%

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 Holder44.4%
Top-3 Unlocked84.8%

Key Addresses

10 addresses
Deployer
0xae15…9d74
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.

What Raised This Score

9 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

Related Audits

6 more on the record
HemiHigh RiskQuack AI Token (Q)High RiskHoloworld AI (HOLO)High RiskPowerHigh RiskXPULSHigh RiskHana Token (HANA)High Risk

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