Quantum Audit Logo

Is Velvet Safe?

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

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

Velvet VELVET
0x8b19…1488
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The VelvetToken contract implements a BEP20 token with additional features for controlled token transfers and a whitelist. The contract exhibits a high degree of centralization, with the owner possessing significant control over token supply through minting and the ability to manipulate transfer restrictions and whitelist addresses. While the core BEP20 implementation is robust, the custom access control logic introduces notable economic and operational risks.

1 Critical2 High1 Medium
Volume 24h
$10.6K
Liquidity
$642.4K
Price
$0.09223
Token Age
1y
Top 10 Holders
87.8%

Security Findings

1 Crit2 High1 Med
Critical

Centralized Minting Capability

C-01The `owner` address has the ability to mint an arbitrary amount of tokens up to the predefined `_cap` (1 billion tokens) via the `mintTo` and `mint` functions. This centralized control over the token supply poses a significant economic risk, as it can lead to inflation, dilution of existing token holders, and potential market manipulation if abused. (7.4 Economic, 7.3 Access Control)
IssueThe `owner` address has the ability to mint an arbitrary amount of tokens up to the predefined `_cap` (1 billion tokens) via the `mintTo` and `mint` functions. This centralized control over the token supply poses a significant economic risk, as it can lead to inflation, dilution of existing token holders, and potential market manipulation if abused. (7.4 Economic, 7.3 Access Control)
FixImplement a mechanism to restrict or remove the owner's minting capability after an initial distribution phase, or introduce a time-locked schedule for minting. If minting is necessary, consider a multi-signature wallet for its execution or a community governance vote.
StatusUnresolved
High

Owner Can Indefinitely Delay Token Transfers

H-01The `setTransferAllowedTimestamp` function contains logic that allows the owner to indefinitely postpone the `transferAllowedTimestamp`. Specifically, if `transferAllowedTimestamp` is in the future and `ETA` is 0, the owner can set `transferAllowedTimestamp` to any new future timestamp. This enables the owner to prevent token transfers for an arbitrary duration, impacting liquidity, user access, and potentially causing significant market uncertainty. (7.4 Economic, 7.3 Access Control)
IssueThe `setTransferAllowedTimestamp` function contains logic that allows the owner to indefinitely postpone the `transferAllowedTimestamp`. Specifically, if `transferAllowedTimestamp` is in the future and `ETA` is 0, the owner can set `transferAllowedTimestamp` to any new future timestamp. This enables the owner to prevent token transfers for an arbitrary duration, impacting liquidity, user access, and potentially causing significant market uncertainty. (7.4 Economic, 7.3 Access Control)
FixRevise the `setTransferAllowedTimestamp` logic to prevent indefinite delays. Consider a fixed maximum delay, a one-time setting, or a mechanism that requires community consensus for changes to critical timelines. Ensure that any changes to this timestamp are clearly communicated to token holders.
StatusUnresolved
High

Whitelist Bypasses Transfer Restrictions

H-02The owner can add any address to the `whitelist` mapping using `addToWhitelist`. Whitelisted addresses are exempt from the `transferAllowedTimestamp` restriction, allowing them to transfer tokens even before the general transfer period begins. This creates a mechanism for preferential treatment, potential insider trading, or selective access, undermining the fairness and transparency of the token launch and transfer restrictions. (7.4 Economic, 7.3 Access Control)
IssueThe owner can add any address to the `whitelist` mapping using `addToWhitelist`. Whitelisted addresses are exempt from the `transferAllowedTimestamp` restriction, allowing them to transfer tokens even before the general transfer period begins. This creates a mechanism for preferential treatment, potential insider trading, or selective access, undermining the fairness and transparency of the token launch and transfer restrictions. (7.4 Economic, 7.3 Access Control)
FixEvaluate the necessity of the whitelist mechanism. If required, implement stricter controls, such as a time-bound whitelist, a public disclosure of whitelisted addresses, or a multi-signature approval process for adding/removing addresses. Clearly define the purpose and scope of the whitelist.
StatusUnresolved
Medium

Single Point of Failure (Owner Key)

M-01The contract relies heavily on a single `owner` address for critical operations, including minting, managing the whitelist, and setting transfer timestamps. If this owner's private key is compromised, an attacker would gain full control over these sensitive functions, leading to potential financial loss, denial of service, or manipulation of the token's economy. (7.8 Operations, 7.3 Access Control)
IssueThe contract relies heavily on a single `owner` address for critical operations, including minting, managing the whitelist, and setting transfer timestamps. If this owner's private key is compromised, an attacker would gain full control over these sensitive functions, leading to potential financial loss, denial of service, or manipulation of the token's economy. (7.8 Operations, 7.3 Access Control)
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `owner` address to distribute control and reduce the risk associated with a single point of failure. Alternatively, consider a timelock mechanism for sensitive operations to provide a window for intervention in case of a compromise.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract leverages standard OpenZeppelin libraries for its BEP20 implementation, contributing to a solid foundation (7.2 Code Security). The custom `_beforeTokenTransfer` hook is correctly overridden to enforce transfer restrictions. However, the logic within `setTransferAllowedTimestamp` is complex, potentially leading to unexpected behavior or misinterpretation (7.2 Code Security). No reentrancy vectors or integer overflow/underflow issues were identified due to Solidity 0.8.30's checked arithmetic.

GovernanceMedium5/10

The contract grants the owner extensive centralized control, posing significant economic risks (7.4 Economic). The owner can mint up to 1 billion tokens, leading to potential inflation and dilution (7.3 Access Control). Furthermore, the owner can indefinitely delay token transfers and bypass restrictions via a whitelist, creating opportunities for market manipulation or preferential treatment (7.4 Economic). There is no decentralized governance mechanism (7.5 Governance).

UpgradesLow7/10

The VelvetToken contract is not designed with upgradeability features (7.7 Upgrades). It is deployed as a standard, non-proxy contract, meaning its logic cannot be modified post-deployment. This eliminates risks associated with upgrade mechanisms but also prevents future bug fixes or feature enhancements without a full redeployment and migration.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

87.8% in top 10
14.1% in wallets73.7% in contracts
Effective Concentration43.6%

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

$670.9K across 7 pairs
Pancakeswap v3WBNBanalysed$642.4K95.8%UniswapUSDT$24.3K3.6%UniswapUSDT$3.9K0.6%Pancakeswap v3WBNB$2490.0%Pancakeswap v3USDT$220.0%Pancakeswap v2Subject 3$100.0%
Show 1 more pairShow less
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.8%
Top-3 Unlocked67.5%

Key Addresses

11 addresses
Deployer
0x579d…116a
Unlocked LP Held By
0x575e…fe980x6260…ee4a0x7f99…b1fe0xb16e…39f20x0295…dbbb0x0528…d2610x5fbe…94c40x7a9a…46d60x69bb…0ed10xe8f7…838d

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

What Raised This Score

6 factors
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30% (87.8% total → 43.6% effective; 14.1% in EOAs, 73.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Critical finding(s) from audit
  • 2 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

Related Audits

6 more on the record
CookieHigh RiskCrossHigh RiskBicatHigh Riskb-moneyHigh RiskTrust Wallet (TWT)High RiskChainOpera AI (COAI)High Risk

Would You Like a More Detailed Audit of Velvet?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit