Quantum Audit Logo
Launch App

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

Is Voice of the Gods by Virtuals Safe?

ADMBase
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance2/10Upgrades1/10Checks passed4 of 7Findings1 High · 2 Medium · 1 Low · 1 Info5
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.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
8.9%Contracts25.8%Wallets65.3%Everyone else
8.9%25.8%Wallets65.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
34.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking8.9%
  • Walletsanonymous holders, free to sell25.8%
  • Everyone elsethe rest of the supply65.3%
Effective concentrationwhat the score reads29.4%
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$216.5K across 2 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$216.1KShare of depth99.8%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x16a7…f455

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

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Control by Factory Contract

The 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.H-01

Issue

The 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.

Fix

Implement 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.

Status

Unresolved

Medium

Incomplete Bot Protection Implementation

The 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.M-01

Issue

The 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.

Fix

Ensure 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.

Status

Unresolved

Medium

Potential for Sandwich Attacks on Auto-Swap (Assumed)

While 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.M-02

Issue

While 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.

Fix

Implement 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.

Status

Unresolved

Low

Hardcoded Gas Limit for External Calls

The 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.L-01

Issue

The 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.

Fix

Re-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.

Status

Unresolved

Info

Lack of Event Emission for Critical Parameter Initializations

While 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.I-01

Issue

While 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.

Fix

Emit events for all critical parameters set during initialization. This improves transparency, auditability, and allows for easier monitoring and integration with off-chain services.

Status

Unresolved

Analysis

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

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.

Technical6/10Medium risk

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).

Governance2/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

It is recommended to address the identified high and medium severity issues to enhance the contract's security posture.

Specifically, review the broad permissions granted to the factory contract and consider implementing a more robust, potentially multi-sig, governance model for critical operations. The bot protection mechanism should be fully implemented within the transfer logic to ensure its effectiveness. Additionally, the auto-swap function should incorporate minimum output amount checks to mitigate sandwich attack risks. Finally, consider emitting events for all critical parameter initializations to improve transparency and off-chain monitoring.

Contract & Record

1 audit on record
TypeAgentToken
NetworkBase
Token age1y
Contract0x55ff…2f16
Deployer0x4849…6ca0
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Voice of the Gods by Virtuals 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, 202666High
  2. Aug 31, 202657Medium

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

Frequently Asked Questions

What is the ADM contract address?

The Voice of the Gods by Virtuals (ADM) contract on Base is 0x55ff51da774b8ce0ed1abaed1cb76236bc6b2f16. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Voice of the Gods by Virtuals a scam?

Quantum Audit's risk score for Voice of the Gods by Virtuals is 66/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is ADM liquidity locked?

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

Who holds ADM?

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

Related Audits

6 more on the recordAll audits
ResearchCoinRSC · Base66HighFren PetBase66HighCoinbase Wrapped ADACBADA · Base66Highether.fi governance tokenETHFI · Base65HighCluster ProtocolCP · Base65HighWorldMobileTokenWMTX · Base65High

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 Is this your token? Publish your own audit on this page