Is VELO Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low1 Info

High

Centralized Initial Token Supply

H-01The 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.

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

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

StatusUnresolved

Medium

Unused WhitelistAdminRole in Token Logic

M-01The `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.

IssueThe `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.

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

StatusUnresolved

Medium

Single Point of Failure for WhitelistAdminRole

M-02The `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.

IssueThe `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.

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

StatusUnresolved

Low

Outdated Solidity Version

L-01The 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.

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

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

StatusUnresolved

Info

Hardcoded Initial Mint Amount

I-01The 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.

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

73.6% in top 10

72.2% in wallets1.4% in contracts

Effective Concentration72.8%

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

$874.7K across 17 pairs

Pancakeswap v3USDCanalysed$642.4K UniswapWBNB$67.1K Pancakeswap v3WBNB$66.3K 0x43eB…2D19WBNB$41.7K 0x43eB…2D19BUSD$33.6K UniswapWBNB$10.4K

Show 4 more pairsShow less

Squadswap v2WBNB$5.2K Pancakeswap v3WBNB$4.8K UniswapUSDT$2.2K UniswapETH$952

The 7 remaining pairs hold $51 between them and are not listed.

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

9 addresses

Deployer

0x40f5…1208

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.

What Raised This Score

8 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

Is VELO Safe?

Security Findings

Centralized Initial Token Supply

Unused WhitelistAdminRole in Token Logic

Single Point of Failure for WhitelistAdminRole

Outdated Solidity Version

Hardcoded Initial Mint Amount

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of VELO?