Quantum Audit Logo
Launch App

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

Is VELO Safe?

BNB 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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance1/10Upgrades6/10Checks passed3 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The audit focused on the Token contract, a modified ERC20 implementation.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • 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 status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 70% (73.6% total → 72.8% effective; 72.2% in EOAs, 1.4% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 73% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 73% 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 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
1.4%72.2%Wallets26.4%Everyone else
72.2%Wallets26.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
73.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking1.4%
  • Walletsanonymous holders, free to sell72.2%
  • Everyone elsethe rest of the supply26.4%
Effective concentrationwhat the score reads72.8%
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$874.7K across 17 pairs
Show 4 more pairs

The 7 remaining pairs hold $51 between them and are not listed. 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$642.4KShare of depth73.5%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xc868…17320x6458…2df50x6f3f…06ac0x860a…f4cc0x46e6…40390xd4c1…f26a0x041f…4e660xaebb…f1d2

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

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Initial Token Supply

The constructor of the Token contract mints a substantial fixed amount of 30,000,000,000,000,000,000,000,000,000 (30 billion) tokens to msg.sender (the deployer). This results in a highly centralized initial token distribution, giving the deployer immense control over the token's supply and potential market manipulation.H-01

Issue

The constructor of the Token contract mints a substantial fixed amount of 30,000,000,000,000,000,000,000,000,000 (30 billion) tokens to msg.sender (the deployer). This results in a highly centralized initial token distribution, giving the deployer immense control over the token's supply and potential market manipulation.

Fix

Consider a more distributed initial token allocation strategy. If the deployer is intended to be a treasury or a distribution mechanism, implement clear, transparent, and potentially time-locked distribution schedules. For a public token, a fair launch or a vesting schedule for initial holders is often preferred.

Status

Unresolved

Medium

Unused WhitelistAdminRole in Token Logic

The Token contract inherits WhitelistAdminRole, but its core ERC20 functionality (e.g., _transfer, _mint, _burn) does not utilize any whitelisting logic or modifiers from this role. This suggests the WhitelistAdminRole is either vestigial, intended for future unimplemented features, or its purpose is solely for external contracts to query the admin status, which is not explicitly stated.M-01

Issue

The Token contract inherits WhitelistAdminRole, but its core ERC20 functionality (e.g., _transfer, _mint, _burn) does not utilize any whitelisting logic or modifiers from this role. This suggests the WhitelistAdminRole is either vestigial, intended for future unimplemented features, or its purpose is solely for external contracts to query the admin status, which is not explicitly stated.

Fix

Clarify the intended purpose of the WhitelistAdminRole. If it's meant to control token transfers (e.g., pausing, blacklisting, whitelisting specific addresses for transfers), integrate its logic into the _beforeTokenTransfer hook or similar mechanisms. If it's for external contract interaction, ensure this is well-documented.

Status

Unresolved

Medium

Single Point of Failure for WhitelistAdminRole

The WhitelistAdminRole is initially granted solely to the contract deployer (msg.sender) in the constructor. While addWhitelistAdmin exists, it can only be called by an existing admin. This creates a single point of failure: if the deployer's private key is compromised, an attacker could gain full control over the WhitelistAdminRole, potentially adding malicious admins or revoking legitimate ones.M-02

Issue

The WhitelistAdminRole is initially granted solely to the contract deployer (msg.sender) in the constructor. While addWhitelistAdmin exists, it can only be called by an existing admin. This creates a single point of failure: if the deployer's private key is compromised, an attacker could gain full control over the WhitelistAdminRole, potentially adding malicious admins or revoking legitimate ones.

Fix

Implement a multi-signature wallet (e.g., Gnosis Safe) to manage the WhitelistAdminRole address. This would require multiple trusted parties to approve any administrative actions, significantly reducing the risk associated with a single compromised key. Consider transferring the WhitelistAdminRole to such a multi-sig immediately after deployment.

Status

Unresolved

Low

Outdated Solidity Version

The contract uses pragma solidity ^0.5.0. While this version is compatible with the OpenZeppelin 2.x libraries used, newer Solidity versions (e.g., 0.8.x) offer enhanced security features such as default overflow/underflow checks, custom errors for more efficient reverts, and improved gas optimizations. Using an older compiler version can sometimes lead to subtle issues or missed opportunities for better code.L-01

Issue

The contract uses pragma solidity ^0.5.0. While this version is compatible with the OpenZeppelin 2.x libraries used, newer Solidity versions (e.g., 0.8.x) offer enhanced security features such as default overflow/underflow checks, custom errors for more efficient reverts, and improved gas optimizations. Using an older compiler version can sometimes lead to subtle issues or missed opportunities for better code.

Fix

Consider upgrading the Solidity compiler version to 0.8.x or later. This would require updating OpenZeppelin dependencies to their 4.x or 5.x versions and carefully reviewing the code for breaking changes, especially regarding SafeMath (which becomes largely unnecessary in 0.8.x+).

Status

Unresolved

Info

Hardcoded Initial Mint Amount

The initial token mint amount in the constructor is hardcoded to 30 billion tokens. While functional, this design choice lacks flexibility for different deployment scenarios or future adjustments without redeploying the contract.I-01

Issue

The initial token mint amount in the constructor is hardcoded to 30 billion tokens. While functional, this design choice lacks flexibility for different deployment scenarios or future adjustments without redeploying the contract.

Fix

Consider making the initial mint amount a constructor parameter. This would allow for greater flexibility during deployment, enabling different initial supplies based on specific project requirements or phases.

Status

Unresolved

Analysis

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

The audit focused on the Token contract, a modified ERC20 implementation. The contract utilizes OpenZeppelin libraries for ERC20 functionality and role-based access control. Key findings include a highly centralized initial token supply and the single-point-of-failure risk associated with the WhitelistAdminRole. While the technical implementation is robust due to OpenZeppelin's use, the economic and governance design introduces notable risks.

Technical8/10Low risk

The Token contract (7.1 Architecture) is a straightforward ERC20 implementation, inheriting from OpenZeppelin's battle-tested contracts like ERC20, ERC20Detailed, and WhitelistAdminRole. This approach significantly enhances code security (7.2 Code Security) by leveraging well-audited components, mitigating common vulnerabilities like reentrancy and integer overflows. The use of SafeMath within OpenZeppelin's ERC20 (v2.x) provides robust arithmetic safety. However, the contract uses an older Solidity version (^0.5.0), which, while compatible with its dependencies, lacks some modern security features and gas optimizations.

Governance1/10High risk

The economic design (7.4 Economic) features a highly centralized initial token distribution, with all 30 billion tokens minted to the deployer, posing significant market control risks (H-01). Governance (7.5 Governance) is limited to the WhitelistAdminRole, which is initially assigned solely to the deployer, creating a single point of failure (M-02). This role is not currently utilized within the token's core transfer logic, suggesting a potential design gap or future intent (M-01). Effective management of the deployer's private key is critical for operational security (7.8 Operations).

Upgrades6/10Medium risk

The Token contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, there are no specific upgrade safety concerns for this contract. Any changes to the token's logic would require deploying a new contract and migrating users, which is a standard procedure for non-upgradeable contracts.

Final RecommendationWhat to do about this score

It is strongly recommended to decentralize the initial token supply and the WhitelistAdminRole to mitigate single points of failure and reduce centralization risks.

Consider implementing a multi-signature wallet for managing the WhitelistAdminRole to enhance security and operational resilience. For future developments, migrating to a more recent Solidity version (e.g., 0.8.x) is advisable to benefit from improved security features and gas efficiency.

Contract & Record

2 audits on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0xf486…fd46
Deployer0x40f5…1208
Badge for your website
VELO 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, 202657Medium
  2. Jul 27, 202658Medium
  3. Jul 27, 202665High

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

Frequently Asked Questions

Is VELO a scam?

Based on automated analysis, VELO scores 65/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is VELO safe to buy?

Our scanner flagged a risk score of 65/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has VELO been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
UnibaseUB · BNB Chain57MediumCapBNB Chain57MediumGriotBNB Chain57MediumAEGIS XAGX · BNB Chain57MediumDarkexBNB Chain57MediumSTABLEBNB Chain56Medium

Would You Like a More Detailed Audit of VELO?

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