Quantum Audit Logo

Is Virtual Protocol Safe?

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

Virtual Protocol VIRTUAL
0x0b3e…7e1b
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The OptimismMintableERC20 contract serves as a cross-chain token, combining Optimism's mintable token standard with LayerZero's Omnichain Fungible Token (OFT) functionality. The audit identified a high-severity access control issue related to the centralized management of LayerZero configurations, alongside medium and low-severity findings concerning operational rigidity and ownership best practices.

1 High1 Medium1 Low1 Informational
Volume 24h
$322.3K
Liquidity
$4.33M
Price
$0.6993
Token Age
2y
Top 10 Holders
46.7%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control over LayerZero Configuration (Owner and Delegate)

H-01The deployer of the `OptimismMintableERC20` contract becomes the owner of the inherited `OAppCore` component and is also set as the delegate for the LayerZero endpoint. This grants significant control over the contract's cross-chain functionality, including the ability to call `setPeer` (to configure trusted remote OApp instances) and potentially other LayerZero endpoint configurations via the delegate role. A compromise of this single owner/delegate key could lead to misrouting of cross-chain token transfers, denial of service, or other manipulations of the OFT functionality (7.3 Access Control, 7.6 External).
IssueThe deployer of the `OptimismMintableERC20` contract becomes the owner of the inherited `OAppCore` component and is also set as the delegate for the LayerZero endpoint. This grants significant control over the contract's cross-chain functionality, including the ability to call `setPeer` (to configure trusted remote OApp instances) and potentially other LayerZero endpoint configurations via the delegate role. A compromise of this single owner/delegate key could lead to misrouting of cross-chain token transfers, denial of service, or other manipulations of the OFT functionality (7.3 Access Control, 7.6 External).
FixTransfer the ownership of the `OAppCore` component and the LayerZero delegate role to a robust multi-signature wallet or a DAO. This decentralizes control and significantly reduces the risk associated with a single point of failure.
StatusUnresolved
Medium

Immutability of Critical Bridge Address

M-01The `BRIDGE` address, which is critical for the `mint` and `burn` functions, is declared as `immutable` and set only during construction. While this prevents unauthorized modification post-deployment, it introduces operational rigidity. If the underlying bridge contract needs to be upgraded, replaced, or if a vulnerability is discovered in the designated bridge, this `OptimismMintableERC20` contract would need to be redeployed, potentially requiring a costly and complex token migration process (7.1 Architecture, 7.8 Operations).
IssueThe `BRIDGE` address, which is critical for the `mint` and `burn` functions, is declared as `immutable` and set only during construction. While this prevents unauthorized modification post-deployment, it introduces operational rigidity. If the underlying bridge contract needs to be upgraded, replaced, or if a vulnerability is discovered in the designated bridge, this `OptimismMintableERC20` contract would need to be redeployed, potentially requiring a costly and complex token migration process (7.1 Architecture, 7.8 Operations).
FixAcknowledge the implications of the immutable `BRIDGE` address. For future deployments, consider if a mutable bridge address (managed by a robust governance mechanism) is preferable, or ensure a clear migration strategy is in place for potential bridge upgrades. For the current deployment, ensure the `BRIDGE` address is thoroughly vetted and secure.
StatusUnresolved
Low

Lack of Robust Ownership Management for LayerZero Configuration

L-01The `OAppCore` component, which manages LayerZero configurations, is `Ownable`. The current setup assigns ownership to the contract deployer and does not include a mechanism or explicit recommendation to transfer this ownership to a more secure entity (e.g., a multi-signature wallet or DAO) or to renounce it if no further configuration changes are anticipated. While the deployer's address is initially the owner, relying on a single externally owned account (EOA) for such critical configuration control introduces a single point of failure risk (7.3 Access Control, 7.5 Governance).
IssueThe `OAppCore` component, which manages LayerZero configurations, is `Ownable`. The current setup assigns ownership to the contract deployer and does not include a mechanism or explicit recommendation to transfer this ownership to a more secure entity (e.g., a multi-signature wallet or DAO) or to renounce it if no further configuration changes are anticipated. While the deployer's address is initially the owner, relying on a single externally owned account (EOA) for such critical configuration control introduces a single point of failure risk (7.3 Access Control, 7.5 Governance).
FixImplement a robust ownership management strategy. Transfer ownership of the `OAppCore` component to a multi-signature wallet or a DAO immediately after deployment. If no further `setPeer` or delegate changes are expected, consider renouncing ownership to the zero address, though this would prevent any future configuration adjustments.
StatusUnresolved
Info

Reliance on External Bridge Security

I-01The core functionality of minting and burning tokens is entirely dependent on the security and correct functioning of the `BRIDGE` contract, whose address is set immutably in the constructor. Any vulnerability, exploit, or malicious action within the designated `BRIDGE` contract would directly impact the integrity and supply of this `OptimismMintableERC20` token (7.6 External).
IssueThe core functionality of minting and burning tokens is entirely dependent on the security and correct functioning of the `BRIDGE` contract, whose address is set immutably in the constructor. Any vulnerability, exploit, or malicious action within the designated `BRIDGE` contract would directly impact the integrity and supply of this `OptimismMintableERC20` token (7.6 External).
FixEnsure that the `BRIDGE` contract is thoroughly audited, regularly monitored, and maintained to the highest security standards. Users should be aware that the security of this token is intrinsically linked to the security of the external bridge.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages well-audited OpenZeppelin and LayerZero libraries, providing a robust foundation for ERC20 and cross-chain functionality. The `mint` and `burn` functions are appropriately restricted to the immutable `BRIDGE` address, enhancing core token supply security (7.3 Access Control, 7.2 Code Security). However, a significant concern arises from the centralized control over LayerZero's `setPeer` function and the delegate role, which could allow a compromised owner to manipulate cross-chain message routing (7.3 Access Control, 7.6 External).

GovernanceMedium5/10

The economic model relies on the integrity of the `BRIDGE` contract for token supply management, which is an inherent design dependency (7.4 Economic). The `BRIDGE` address is immutable, preventing unauthorized changes but introducing rigidity; any future bridge upgrades would necessitate redeployment of this token contract (7.1 Architecture). Furthermore, the deployer's control over LayerZero's `setPeer` and delegate roles presents a centralized governance risk for cross-chain operations (7.5 Governance).

UpgradesMedium6/10

The contract is not designed with an upgradeability pattern (e.g., proxy), meaning its logic cannot be modified post-deployment. While this eliminates upgrade-specific risks like proxy misconfigurations or logic bugs during upgrades (7.7 Upgrades), it also means that any future changes, bug fixes, or necessary updates to the `OptimismMintableERC20` or its `BRIDGE` dependency would require a complete redeployment and migration of token holders, incurring significant operational overhead (7.8 Operations).

Security Checklist

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

Holder Composition

46.7% in top 10
30.3% in wallets16.4% in contracts
Effective Concentration36.9%

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

$9.32M across 30 pairs
AerodromeWETHanalysed$4.33M46.4%Uniswap v2WETH$1.35M14.5%Uniswap v3USDC$797.4K8.6%AerodromeUSDC$530.1K5.7%Uniswap v3WETH$509.4K5.5%AerodromeWETH$444.4K4.8%
Show 4 more pairsShow less
AerodromeWETH$401.0K4.3%AerodromeWETH$256.1K2.7%AerodromeAERO$154.6K1.7%Uniswap v3WETH$146.5K1.6%

The 20 remaining pairs hold $401.7K 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 Holder94.9%
Top-3 Unlocked100.0%

Key Addresses

11 addresses
Deployer
0x97cf…90a3
Unlocked LP Held By
0xf1c4…71c80xfbc9…a3610x0ff1…7d770x2744…01ca0x3624…147c0xeff4…d00f0xda21…e12f0x46d8…b5b50x06c5…d2b40xceb9…3d6d

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

What Raised This Score

8 factors
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (46.7% total → 36.9% effective; 30.3% in EOAs, 16.4% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 94.9% (independent LP — depth risk, pool = 46% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 46% of DEX liquidity)
  • 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

Related Audits

6 more on the record
CookieMedium RiskStockify (STFY)Medium RiskBasepepeMedium RiskMoltbook (MOLT)Medium RiskKellyClaudeMedium RiskPlayMedium Risk

Would You Like a More Detailed Audit of Virtual Protocol?

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

Get Detailed Audit