Quantum Audit Logo

Is Voice of the Gods by Virtuals Safe?

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

Voice of the Gods by Virtuals ADM
0x55ff…2f16
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The AgentToken contract is an upgradeable ERC20-like token designed with custom tax mechanisms, Uniswap V2 integration for liquidity, and a bot protection feature. The contract utilizes OpenZeppelin's upgradeable patterns and access control. While the architecture is generally sound, the audit identified several areas for improvement, particularly concerning the broad control granted to the factory contract, the incomplete implementation of bot protection, and potential vulnerabilities in the assumed auto-swap mechanism. These issues contribute to a Medium overall risk level.

1 High2 Medium1 Low1 Informational
Volume 24h
$33.8K
Liquidity
$216.1K
Price
$0.001203
Token Age
1y
Top 10 Holders
34.7%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control by Factory Contract

H-01The `onlyOwnerOrFactory` modifier grants significant control to the `_factory` address, allowing it to perform critical operations such as adding/removing liquidity pools, managing valid callers, and setting project tax parameters. If the factory contract is compromised or has vulnerabilities, it could lead to a complete compromise of the `AgentToken` instances it deploys, including potential manipulation of token economics or liquidity.
IssueThe `onlyOwnerOrFactory` modifier grants significant control to the `_factory` address, allowing it to perform critical operations such as adding/removing liquidity pools, managing valid callers, and setting project tax parameters. If the factory contract is compromised or has vulnerabilities, it could lead to a complete compromise of the `AgentToken` instances it deploys, including potential manipulation of token economics or liquidity.
FixImplement robust security measures for the factory contract, such as multi-signature ownership, time-locks for sensitive operations, or a more decentralized governance model. Re-evaluate if all `onlyOwnerOrFactory` functions truly require factory access post-deployment, or if some could be restricted to only the `owner` after initialization.
StatusUnresolved
Medium

Incomplete Bot Protection Implementation

M-01The `botProtectionDurationInSeconds` variable is set during initialization, indicating an intent to implement a bot protection mechanism. However, the provided code snippet does not include the actual logic (e.g., within the `_transfer` function) that utilizes this duration to restrict transfers or other actions during the protected period. Without this implementation, the bot protection feature is ineffective.
IssueThe `botProtectionDurationInSeconds` variable is set during initialization, indicating an intent to implement a bot protection mechanism. However, the provided code snippet does not include the actual logic (e.g., within the `_transfer` function) that utilizes this duration to restrict transfers or other actions during the protected period. Without this implementation, the bot protection feature is ineffective.
FixEnsure the `_transfer` function or relevant transfer logic correctly implements the bot protection. This should involve checking `block.timestamp` against `fundedDate + botProtectionDurationInSeconds` and restricting transfers for non-whitelisted addresses (e.g., liquidity pools, owner) during this period.
StatusUnresolved
Medium

Potential for Sandwich Attacks on Auto-Swap (Assumed)

M-02While the `_autoSwapInProgress` flag is a good reentrancy guard, the actual auto-swap function (which is not fully provided but implied by the tax mechanisms) might be vulnerable to sandwich attacks. If the swap logic does not specify a minimum output amount, malicious actors could front-run the auto-swap transaction by artificially increasing the price, then back-run it to profit from the price decrease caused by the large swap, extracting value from the protocol.
IssueWhile the `_autoSwapInProgress` flag is a good reentrancy guard, the actual auto-swap function (which is not fully provided but implied by the tax mechanisms) might be vulnerable to sandwich attacks. If the swap logic does not specify a minimum output amount, malicious actors could front-run the auto-swap transaction by artificially increasing the price, then back-run it to profit from the price decrease caused by the large swap, extracting value from the protocol.
FixImplement a minimum output amount check for the auto-swap function to mitigate sandwich attacks. This minimum amount should be calculated based on the current price and a reasonable slippage tolerance to ensure the protocol receives a fair value for its swapped tokens.
StatusUnresolved
Low

Hardcoded Gas Limit for External Calls

L-01The constant `CALL_GAS_LIMIT` is hardcoded to `50000`. If this limit is used for external calls (e.g., to transfer tokens or interact with other contracts), it could potentially lead to a denial-of-service (DoS) if the called contract's function requires more gas than this limit. This would cause the transaction to revert, preventing the intended operation.
IssueThe constant `CALL_GAS_LIMIT` is hardcoded to `50000`. If this limit is used for external calls (e.g., to transfer tokens or interact with other contracts), it could potentially lead to a denial-of-service (DoS) if the called contract's function requires more gas than this limit. This would cause the transaction to revert, preventing the intended operation.
FixRe-evaluate the necessity of a hardcoded gas limit for external calls. If it is used, ensure it is sufficiently high to accommodate all legitimate operations of the called contracts. Alternatively, consider removing it if not strictly necessary, allowing the EVM to handle gas forwarding more flexibly.
StatusUnresolved
Info

Lack of Event Emission for Critical Parameter Initializations

I-01While some parameter updates emit events, several critical parameters set during the `initialize` function (e.g., `botProtectionDurationInSeconds`, `pairToken`, `vault`, `_name`, `_symbol`, `projectBuyTaxBasisPoints`, `projectSellTaxBasisPoints`) do not have corresponding events emitted. This makes it harder for off-chain systems, such as block explorers or monitoring tools, to track the initial configuration and state of the contract.
IssueWhile some parameter updates emit events, several critical parameters set during the `initialize` function (e.g., `botProtectionDurationInSeconds`, `pairToken`, `vault`, `_name`, `_symbol`, `projectBuyTaxBasisPoints`, `projectSellTaxBasisPoints`) do not have corresponding events emitted. This makes it harder for off-chain systems, such as block explorers or monitoring tools, to track the initial configuration and state of the contract.
FixEmit events for all critical parameters set during initialization. This improves transparency, auditability, and allows for easier monitoring and integration with off-chain services.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages OpenZeppelin's `Initializable` and `Ownable2StepUpgradeable` for robust architecture (7.1) and access control (7.3). The use of `SafeERC20` enhances code security (7.2) for external token interactions. However, the `botProtectionDurationInSeconds` variable is set without its corresponding logic in the provided code, leaving a critical security feature unimplemented. Additionally, a hardcoded `CALL_GAS_LIMIT` could lead to denial-of-service for certain external interactions (7.2). The `_autoSwapInProgress` flag is a good pattern for reentrancy prevention in the auto-swap logic (7.2).

GovernanceHigh2/10

The contract's economic model (7.4) includes project buy/sell taxes and a swap threshold, configurable by the owner or factory. The `botProtectionDurationInSeconds` is a key economic parameter intended to prevent sniping, but its implementation is missing. Governance (7.5) is highly centralized, with the `onlyOwnerOrFactory` modifier granting extensive control over critical parameters like tax rates, liquidity pools, and the tax recipient. This concentration of power in the factory contract (7.5) represents a significant risk. The auto-swap mechanism, while beneficial for tax collection, could be susceptible to sandwich attacks (7.4) if not properly safeguarded.

UpgradesHigh1/10

The contract is built as an upgradeable implementation using OpenZeppelin's `Initializable` pattern (7.7). The constructor correctly calls `_disableInitializers()`, and the `initialize` function is marked `external initializer`, ensuring proper setup for proxy deployments. This design allows for future upgrades to fix bugs or add features without redeploying the entire system, contributing to a low upgrade risk.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

34.7% in top 10
25.8% in wallets8.9% in contracts
Effective Concentration29.4%

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

$216.5K across 2 pairs
Uniswap v2VIRTUALanalysed$216.1K99.8%AerodromeWETH$3580.2%

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

2 addresses
Deployer
0x4849…6ca0
Unlocked LP Held By
0x16a7…f455

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

What Raised This Score

10 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 20% (34.7% total → 29.4% effective; 25.8% in EOAs, 8.9% in contracts — mild)
  • 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 = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% 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

Related Audits

6 more on the record
ResearchCoin (RSC)High RiskFren PetHigh Riskether.fi governance token (ETHFI)High RiskCluster Protocol (CP)High RiskMetronome Synth USD (MSUSD)High RiskCoW Protocol Token (COW)High Risk

Would You Like a More Detailed Audit of Voice of the Gods by Virtuals?

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

Get Detailed Audit