Quantum Audit Logo
Launch App

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

Is Virtuals Protocol Safe?

VIRTUALEthereum
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
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical5/10Governance4/10Upgrades7/10Checks passed3 of 5Findings1 Critical · 1 High · 1 Medium · 1 Low4
SummaryAI Copilot

The VirtualToken contract is an ERC-20 token implementation that heavily leverages OpenZeppelin's secure and battle-tested libraries.

Read the full analysis
What raised the score
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 95.3%
  • LP top3 unlocked holders = 97.6%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30% (90.6% total → 40.3% effective; 6.8% in EOAs, 83.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 95.3% (independent LP — depth risk, pool = 52% of DEX liquidity)
  • LP top3 unlocked holders = 97.6% (independent LP — depth risk, pool = 52% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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
OwnershipRenounced
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
83.8%Contracts6.8%9.4%Everyone else
83.8%Contracts6.8%9.4%
ContractsWalletsEveryone elseBubble area = share of supply
90.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking83.8%
  • Walletsanonymous holders, free to sell6.8%
  • Everyone elsethe rest of the supply9.4%
Effective concentrationwhat the score reads40.3%
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$560.4K across 3 pairs

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$293.6KShare of depth52.4%
Top-1 Unlocked Holder95.3%
Top-3 Unlocked97.6%
Unlocked LP held by
0xf1c4…71c80x8054…0a820x497c…eab20x5a1f…b1c40xd884…5cd00x6e67…b6390x752d…4bdf0xf2aa…b67e0xc94f…058e0x806e…b6f9

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

Security Findings

1 Critical1 High1 Medium1 Low
Critical

Extreme Centralization of Token Operations

The VirtualToken contract overrides several core ERC-20 functions (_update, _mint, _burn, _approve, _spendAllowance, _increaseAllowance, _decreaseAllowance, _permit) with the onlyOwner modifier. This design choice means that only the contract owner can initiate or facilitate any token transfer, minting, burning, or allowance management. Consequently, regular users cannot transfer their own tokens, approve spending for others, or utilize permit functionality, rendering the token non-transferable and completely controlled by a single address.C-01

Issue

The VirtualToken contract overrides several core ERC-20 functions (_update, _mint, _burn, _approve, _spendAllowance, _increaseAllowance, _decreaseAllowance, _permit) with the onlyOwner modifier. This design choice means that only the contract owner can initiate or facilitate any token transfer, minting, burning, or allowance management. Consequently, regular users cannot transfer their own tokens, approve spending for others, or utilize permit functionality, rendering the token non-transferable and completely controlled by a single address.

Fix

Unless this extreme centralization is an explicit and fully understood design requirement, remove the onlyOwner modifier from functions that are intended for general user interaction, particularly _update, _approve, and _permit. If centralization is intended, clearly document this behavior and consider implementing a robust multi-signature wallet or a time-locked contract for ownership to distribute control and enhance security.

Status

Unresolved

High

Single Point of Failure and Key Compromise Risk

Due to the extreme centralization (C-01), the contract owner's private key represents a critical single point of failure. If this key is compromised, an attacker would gain absolute control over all token operations, including the ability to arbitrarily mint new tokens, burn existing ones, and transfer any token balance, leading to a complete loss of funds and trust in the protocol.H-01

Issue

Due to the extreme centralization (C-01), the contract owner's private key represents a critical single point of failure. If this key is compromised, an attacker would gain absolute control over all token operations, including the ability to arbitrarily mint new tokens, burn existing ones, and transfer any token balance, leading to a complete loss of funds and trust in the protocol.

Fix

Implement a robust access control mechanism such as a multi-signature wallet (e.g., Gnosis Safe) for the contract owner address. This would require multiple approvals for critical operations, significantly reducing the risk associated with a single key compromise. Additionally, consider implementing a timelock for sensitive owner-only operations to provide a window for intervention.

Status

Unresolved

Medium

Misleading ERC-20 Standard Compliance

While the VirtualToken contract inherits from OpenZeppelin's ERC20 and ERC20Permit standards, its extensive use of onlyOwner modifiers on core functionalities fundamentally deviates from the expected behavior and utility of a standard ERC-20 token. Users and integrating protocols might expect free transferability and decentralized allowance management, which this token does not provide. This discrepancy can lead to confusion, integration issues, and a lack of trust.M-01

Issue

While the VirtualToken contract inherits from OpenZeppelin's ERC20 and ERC20Permit standards, its extensive use of onlyOwner modifiers on core functionalities fundamentally deviates from the expected behavior and utility of a standard ERC-20 token. Users and integrating protocols might expect free transferability and decentralized allowance management, which this token does not provide. This discrepancy can lead to confusion, integration issues, and a lack of trust.

Fix

Clearly and prominently communicate the highly centralized nature and restricted functionality of this token to all potential users, investors, and integrating platforms. If the intent is to be a standard ERC-20, the access control restrictions should be removed. If it's a specialized token, consider renaming it or adding specific documentation to avoid misrepresentation.

Status

Unresolved

Low

Irreversible Loss of Functionality via Renounce Ownership

The Ownable contract includes a renounceOwnership() function. If the current owner calls this function, the contract will be left without an owner. Given that almost all critical token operations are restricted by onlyOwner, renouncing ownership would permanently disable all token management functionalities, including transfers, minting, and burning, effectively bricking the token and making all existing tokens untransferable.L-01

Issue

The Ownable contract includes a renounceOwnership() function. If the current owner calls this function, the contract will be left without an owner. Given that almost all critical token operations are restricted by onlyOwner, renouncing ownership would permanently disable all token management functionalities, including transfers, minting, and burning, effectively bricking the token and making all existing tokens untransferable.

Fix

Consider removing the renounceOwnership function if there is no clear use case for it, or implement a mechanism that allows for a new owner to be set before ownership can be renounced, or a recovery mechanism. If renounceOwnership is kept, ensure its implications are fully understood and documented, and consider adding a time-lock or multi-signature requirement for this specific action.

Status

Unresolved

Analysis

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

The VirtualToken contract is an ERC-20 token implementation that heavily leverages OpenZeppelin's secure and battle-tested libraries. However, it introduces severe access control restrictions by applying the onlyOwner modifier to nearly all core ERC-20 functions, including transfers, minting, burning, and allowance management. This design choice results in an extremely centralized token where only the contract owner can initiate or facilitate any token movement, fundamentally deviating from the expected behavior of a standard ERC-20 token and introducing critical single points of failure.

Technical5/10Medium risk

The contract utilizes well-audited OpenZeppelin libraries for its ERC-20, Ownable, and ERC20Permit implementations, which is a significant strength (7.2 Code Security). This provides robust protection against common vulnerabilities like reentrancy and integer overflows. However, the custom overrides introduce severe access control flaws (7.3 Access Control) by restricting almost all token operations, including transfers, minting, and burning, to the contract owner. This design choice fundamentally alters the expected behavior of an ERC-20 token, making it non-transferable by regular users.

Governance4/10Medium risk

The economic model of the VirtualToken is critically centralized (7.4 Economic). The contract owner holds absolute control over all token operations, including minting, burning, and all transfers, effectively making the token non-transferable by users. This creates a single point of failure (7.5 Governance) where the compromise of the owner's private key would lead to complete loss of control over the entire token supply and its functionality. The lack of user autonomy significantly diminishes the token's utility and trust.

Upgrades7/10Low risk

The VirtualToken contract is not implemented as an upgradeable proxy (7.7 Upgrades). This design choice inherently avoids the specific risks associated with upgrade mechanisms, such as proxy initialization issues or logic errors during upgrades. However, it also means that the contract's logic cannot be modified or extended after deployment, requiring a complete redeployment for any future changes or bug fixes.

Final RecommendationWhat to do about this score

It is strongly recommended to reassess the core design of the VirtualToken contract.

If the intention is for a standard, freely transferable ERC-20 token, the onlyOwner modifiers on core functions like _update, _approve, _mint, and _burn must be removed or significantly re-evaluated to allow decentralized user interactions. If the highly centralized nature is intentional, this must be explicitly and transparently communicated to all potential users and integrators, along with a robust multi-signature or time-locked ownership mechanism to mitigate the single point of failure risk.

Contract & Record

1 audit on record
TypeVirtualToken
NetworkEthereum
Token age1y
Contract0x44ff…bf73
Deployer0x97cf…90a3
Badge for your website
Virtuals Protocol 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, 202651Medium
  2. Jul 23, 202653Medium

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

Frequently Asked Questions

What is the VIRTUAL contract address?

The Virtuals Protocol (VIRTUAL) contract on Ethereum is 0x44ff8620b8ca30902395a7bd3f2407e1a091bf73. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Virtuals Protocol a scam?

Quantum Audit's risk score for Virtuals Protocol is 51/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is VIRTUAL liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $560.4K.

Who holds VIRTUAL?

As of Sep 4, 2026, the 10 largest holders own 90.6% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
DeriveDRV · Ethereum51MediumLido DAOLDO · Ethereum51MediumFXN TokenFXN · Ethereum51MediumFuse CatFUSECAT · Ethereum51MediumCreditStrategyCREDITSTR · Ethereum51MediumEthenaENA · Ethereum50Medium

Would You Like a More Detailed Audit of Virtuals Protocol?

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