Quantum Audit Logo

Is VEIL Token Safe?

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

VEIL Token VEIL
0x767a…7d7f
Base Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

This audit report is based on the provided OpenZeppelin `Ownable` and `ERC20` library code, as the specific `VEILToken` contract implementation was not provided. The analysis assumes `VEILToken` inherits from these standard components. The contract benefits from using well-audited OpenZeppelin libraries. A key operational characteristic is that ownership has been renounced, which removes centralized control but also administrative flexibility.

3 Informational
Volume 24h
$38.4K
Liquidity
$525.1K
Price
$0.01952
Token Age
1y
Top 10 Holders
64.6%

Security Findings

Info

Renounced Ownership Implications

I-01The `Ownable` contract's ownership has been renounced, as indicated by `ownership_renounced: true`. This means the `owner()` address is `address(0)`, and any functions protected by the `onlyOwner` modifier are permanently inaccessible. This design choice enhances decentralization by removing a single point of control.
IssueThe `Ownable` contract's ownership has been renounced, as indicated by `ownership_renounced: true`. This means the `owner()` address is `address(0)`, and any functions protected by the `onlyOwner` modifier are permanently inaccessible. This design choice enhances decentralization by removing a single point of control.
FixAcknowledge that renounced ownership means no administrative functions (e.g., `transferOwnership`, `renounceOwnership` itself, or any `onlyOwner` functions in the inheriting `VEILToken` contract like `_mint` or `_burn` if exposed) can ever be executed. This is a permanent state and should be clearly communicated to users and stakeholders.
StatusUnresolved
Info

Reliance on Standard OpenZeppelin Libraries

I-02The contract utilizes well-audited and widely adopted OpenZeppelin libraries for its `ERC20` and `Ownable` functionalities. This significantly reduces the likelihood of common vulnerabilities and contributes to high code security and reliability.
IssueThe contract utilizes well-audited and widely adopted OpenZeppelin libraries for its `ERC20` and `Ownable` functionalities. This significantly reduces the likelihood of common vulnerabilities and contributes to high code security and reliability.
FixContinue to leverage established and audited libraries. Ensure that any custom logic added in the `VEILToken` contract (not provided for audit) maintains the same high security standards and does not introduce new vulnerabilities.
StatusUnresolved
Info

Absence of Emergency Pause Mechanism

I-03The contract does not include a mechanism to pause transfers or other critical operations in case of an emergency, such as a major exploit or vulnerability discovery. While common for simple tokens, this means no immediate response is possible for certain attack vectors.
IssueThe contract does not include a mechanism to pause transfers or other critical operations in case of an emergency, such as a major exploit or vulnerability discovery. While common for simple tokens, this means no immediate response is possible for certain attack vectors.
FixConsider if an emergency pause mechanism (e.g., using OpenZeppelin's `Pausable` contract) is necessary for the project's risk profile. If implemented, ensure the pause functionality is controlled by a secure, multi-signature wallet or a robust governance process, especially given the renounced ownership of the `Ownable` component.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is robust, leveraging standard and well-audited OpenZeppelin `ERC20` and `Ownable` contracts. Code security (7.2) is high, with appropriate use of `unchecked` blocks for gas optimization where safety is guaranteed by prior checks. Access control (7.3) is managed by the `Ownable` pattern, which, given renounced ownership, means no single entity can exert administrative control. External interactions (7.6) are limited to standard ERC20 interfaces, reducing attack surface. Operations (7.8) are straightforward, though administrative functions are disabled due to renounced ownership.

GovernanceMedium6/10

The economic model (7.4) is a standard ERC20 token, with no complex mechanisms identified in the provided library code. Governance (7.5) is effectively decentralized due to the renounced ownership, meaning no single address can control token parameters or administrative functions like `_mint` or `_burn` if they were exposed by the inheriting contract and protected by `onlyOwner`. This eliminates risks associated with a malicious or compromised owner, but also removes any potential for administrative intervention or upgrades.

UpgradesLow9/10

The provided contracts are not designed for upgradeability (7.7), as indicated by the absence of proxy patterns (e.g., UUPS, Transparent) or `Initializable` contracts. This means the contract's logic is immutable once deployed, eliminating upgrade-related risks but also precluding future modifications or bug fixes to the core logic.

Security Checklist

Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

28.8% in wallets35.9% in contracts
Effective Concentration43.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

Show 2 more pairsShow less

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 Holder52.5%
Top-3 Unlocked95.0%

Key Addresses

Deployer
0x19f4…3702
Unlocked LP Held By
0x9a88…bd090x75c6…56eb0x3112…a58e0xd248…0e490x391d…0f64

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

What Raised This Score

  • Top-10 concentration > 30% (64.6% total → 43.1% effective; 28.8% in EOAs, 35.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 52.5% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 95.0% (independent LP — depth risk, pool = 97% of DEX liquidity)

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

Briun Armstrung (BRIUN)Low RiskToshiLow RiskCoinye West (COINYE)Low RiskDebtReliefBot (DRB)Low RiskRUSSELLLow Riskmfercoin ($MFER)Low Risk

Would You Like a More Detailed Audit of VEIL Token?

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

Get Detailed Audit