Quantum Audit Logo
Launch App

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

Is OLAXBT Safe?

AIOBNB 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

The audited Token contract is a standard ERC-20 implementation inheriting from OpenZeppelin's battle-tested library.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 57.2%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (95.5% total → 49.2% effective; 18.4% in EOAs, 77.1% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 57.2% (independent LP — depth risk, pool = 62% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
77.1%Contracts18.4%Wallets4.5%
77.1%Contracts18.4%Wallets4.5%
ContractsWalletsEveryone elseBubble area = share of supply
95.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking77.1%
  • Walletsanonymous holders, free to sell18.4%
  • Everyone elsethe rest of the supply4.5%
Effective concentrationwhat the score reads49.2%
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$78.7K across 3 pairs
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$49.1KShare of depth62.4%
Top-1 Unlocked Holder57.2%
Top-3 Unlocked77.8%
Unlocked LP held by
0x3eff…ce450x575e…fe980xaf12…6f040x6fff…2d740xe43f…5e120xb16e…39f20x61d9…f2970xa37b…14730xd48d…9bd80x3262…f28a

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

Security Findings

1 High1 Medium2 Info
High

Centralized Control of Total Supply by Vesting Contract

The entire token supply (1,000,000,000 tokens with 18 decimals) is minted to a single vesting address during contract deployment. This design choice places the sole control and distribution responsibility of all tokens in the hands of the specified vesting contract. This creates a significant single point of failure; if the vesting contract is compromised or mismanaged, the entire token supply is at risk.H-01

Issue

The entire token supply (1,000,000,000 tokens with 18 decimals) is minted to a single vesting address during contract deployment. This design choice places the sole control and distribution responsibility of all tokens in the hands of the specified vesting contract. This creates a significant single point of failure; if the vesting contract is compromised or mismanaged, the entire token supply is at risk.

Fix

Ensure the vesting contract is robustly secured, thoroughly audited, and managed with the highest security standards. Consider implementing multi-signature wallets, time-locked contracts, or other decentralized control mechanisms for the vesting contract to distribute risk and enhance security.

Status

Unresolved

Medium

Absence of Emergency Admin Controls

The Token contract lacks any administrative functions such as pausing transfers, blacklisting malicious addresses, or upgrading the contract logic. While this promotes decentralization and immutability, it also means there is no mechanism for emergency response in case of critical vulnerabilities, exploits, or unforeseen market conditions affecting the token.M-01

Issue

The Token contract lacks any administrative functions such as pausing transfers, blacklisting malicious addresses, or upgrading the contract logic. While this promotes decentralization and immutability, it also means there is no mechanism for emergency response in case of critical vulnerabilities, exploits, or unforeseen market conditions affecting the token.

Fix

Evaluate the project's risk tolerance for immutability versus the need for emergency intervention. If emergency controls are deemed necessary, consider implementing a robust, multi-signature-controlled admin role with limited, well-defined capabilities (e.g., pause, unpause) in a future iteration or a separate governance contract.

Status

Unresolved

Info

Immutability and Non-Upgradeability

The Token contract is deployed as a standard, non-upgradeable ERC-20 implementation. This means its logic cannot be modified or updated after deployment. This is a common design choice for simple tokens, ensuring immutability.I-01

Issue

The Token contract is deployed as a standard, non-upgradeable ERC-20 implementation. This means its logic cannot be modified or updated after deployment. This is a common design choice for simple tokens, ensuring immutability.

Fix

This design choice ensures immutability and predictability. However, it implies that any discovered bugs or desired feature enhancements post-deployment would necessitate a new contract deployment and token migration. Ensure the current implementation is thoroughly tested and meets all long-term requirements.

Status

Unresolved

Info

Redundant Constructor Check

The constructor includes a require(totalSupply > 0, "Total supply cannot be zero"); check. Given that totalSupply is explicitly initialized to 1_000_000_000 ether, which is a large positive number, this check is always true and therefore redundant.I-02

Issue

The constructor includes a require(totalSupply > 0, "Total supply cannot be zero"); check. Given that totalSupply is explicitly initialized to 1_000_000_000 ether, which is a large positive number, this check is always true and therefore redundant.

Fix

Remove the redundant require(totalSupply > 0, ...) statement to slightly optimize gas usage and improve code clarity.

Status

Unresolved

Analysis

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

The audited Token contract is a standard ERC-20 implementation inheriting from OpenZeppelin's battle-tested library. The primary design choice involves minting the entire token supply to a single vesting address during deployment, which introduces a significant point of centralization for token distribution and control. The contract is immutable and lacks administrative functions, which can be both a feature for decentralization and a limitation for emergency response.

Technical8/10Low risk

The Token contract (7.1 Architecture) is a straightforward ERC-20 implementation, leveraging the robust and audited OpenZeppelin Contracts library, which significantly reduces the risk of common vulnerabilities (7.2 Code Security). The use of Solidity ^0.8.28 ensures modern compiler features and safety checks. A minor informational finding includes a redundant require statement in the constructor, which does not pose a security risk.

Governance2/10High risk

The economic model (7.4 Economic) dictates that the entire token supply is minted to a single vesting address upon deployment. This design choice centralizes control over all tokens, making the security and operational integrity of the vesting contract paramount (7.8 Operations). Any compromise of this address would directly impact the entire token supply. The contract lacks any governance mechanisms (7.5 Governance) or administrative controls (7.3 Access Control) for post-deployment adjustments or emergency interventions.

Upgrades6/10Medium risk

The Token contract is deployed as a standard, non-upgradeable implementation (7.7 Upgrades). This means its logic cannot be modified or updated after deployment. While this ensures immutability, it also implies that any discovered bugs or desired feature enhancements post-deployment would necessitate a new contract deployment and token migration, which can be a complex and costly process.

Final RecommendationWhat to do about this score

Prioritize a comprehensive security audit and robust operational procedures for the designated vesting contract, as it holds the entire token supply and represents a single point of failure.

Consider implementing multi-signature controls or time-locks for the vesting contract to enhance security and mitigate risks associated with centralized control. Thoroughly evaluate the project's long-term needs regarding immutability versus the potential future requirement for emergency administrative controls, as the current design offers no such recourse.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age11mo
Contract0x81a7…32b4
Deployer0xe5a2…0b5c
Badge for your website
OLAXBT 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. Aug 16, 202638Medium

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

Would You Like a More Detailed Audit of OLAXBT?

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