Quantum Audit Logo
Launch App

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

Is GAME by Virtuals Safe?

GAMEBase
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/10Governance1/10Upgrades1/10Checks passed4 of 7Findings1 Critical · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The AgentToken contract implements a custom ERC20-like token with tax mechanisms, bot protection, and Uniswap V2 integration.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 67.3%
  • LP top3 unlocked holders = 92.9%
  • 1 Critical finding(s) from audit
  • 1 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 > 30% (48.7% total → 34.8% effective; 25.5% in EOAs, 23.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 67.3% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 92.9% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 Critical 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 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
23.2%Contracts25.5%Wallets51.3%Everyone else
23.2%Contracts25.5%Wallets51.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
48.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking23.2%
  • Walletsanonymous holders, free to sell25.5%
  • Everyone elsethe rest of the supply51.3%
Effective concentrationwhat the score reads34.8%
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$2.66M across 12 pairs
Show 4 more pairs

The 2 remaining pairs hold $4 between them and are not listed. 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$2.64MShare of depth99.3%
Top-1 Unlocked Holder67.3%
Top-3 Unlocked92.9%
Unlocked LP held by
0xb4f5…ec680xfc13…a7810xe796…f9e20x9483…63640xc472…be240xdd62…bbb50x8163…30a80xc7af…7dab

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

Security Findings

1 Critical1 Medium1 Low1 Info
Critical

Incomplete ERC20 Implementation (Missing Core Functions)

The AgentToken contract defines private state variables for _balances, _allowances, _totalSupply, _name, and _symbol, which are typical for an ERC20 token. However, the public ERC20 interface functions such as transfer, transferFrom, approve, allowance, balanceOf, and decimals are not present in the provided code snippet. While IAgentToken is imported, its interface is not shown, and the implementation of these critical functions is absent, rendering the token non-functional as a standard ERC20.C-01

Issue

The AgentToken contract defines private state variables for _balances, _allowances, _totalSupply, _name, and _symbol, which are typical for an ERC20 token. However, the public ERC20 interface functions such as transfer, transferFrom, approve, allowance, balanceOf, and decimals are not present in the provided code snippet. While IAgentToken is imported, its interface is not shown, and the implementation of these critical functions is absent, rendering the token non-functional as a standard ERC20.

Fix

Implement all standard ERC20 functions (transfer, transferFrom, approve, allowance, balanceOf, decimals, totalSupply) to ensure the token is fully functional and compliant with the ERC20 standard. Ensure these implementations correctly interact with the private state variables.

Status

Unresolved

Medium

Centralization Risk with onlyOwnerOrFactory Modifier

The onlyOwnerOrFactory modifier grants significant control to the contract owner and the _factory contract. Functions such as addLiquidityPool, removeLiquidityPool, addValidCaller, removeValidCaller, setProjectTaxRecipient, and setSwapThresholdBasisPoints can be modified by these entities. This centralizes control over key operational parameters, including liquidity management, tax recipients, and auto-swap thresholds, posing a single point of failure and potential for misuse.M-01

Issue

The onlyOwnerOrFactory modifier grants significant control to the contract owner and the _factory contract. Functions such as addLiquidityPool, removeLiquidityPool, addValidCaller, removeValidCaller, setProjectTaxRecipient, and setSwapThresholdBasisPoints can be modified by these entities. This centralizes control over key operational parameters, including liquidity management, tax recipients, and auto-swap thresholds, posing a single point of failure and potential for misuse.

Fix

Consider decentralizing control for critical functions by implementing a multi-signature wallet for the owner address or integrating a governance mechanism. For less critical functions, evaluate if the _factory contract's role can be limited or if a time-lock mechanism should be introduced for sensitive parameter changes.

Status

Unresolved

Low

Potential for Slippage and MEV in Initial Liquidity Provision

The _addInitialLiquidity function adds liquidity to Uniswap V2 using _uniswapRouter.addLiquidity. While protected by onlyOwnerOrFactory, the minAmountA and minAmountB parameters are set to 0. This allows for arbitrary slippage during the liquidity addition. If the transaction is public, a sophisticated attacker could potentially front-run or sandwich this transaction, especially if the pairToken is volatile or the initial liquidity provision is substantial, leading to unfavorable exchange rates for the liquidity provider.L-01

Issue

The _addInitialLiquidity function adds liquidity to Uniswap V2 using _uniswapRouter.addLiquidity. While protected by onlyOwnerOrFactory, the minAmountA and minAmountB parameters are set to 0. This allows for arbitrary slippage during the liquidity addition. If the transaction is public, a sophisticated attacker could potentially front-run or sandwich this transaction, especially if the pairToken is volatile or the initial liquidity provision is substantial, leading to unfavorable exchange rates for the liquidity provider.

Fix

Set reasonable minimum amounts for minAmountA and minAmountB in the addLiquidity call to protect against excessive slippage. Consider using a private transaction relay or a trusted third party for initial liquidity provision to mitigate MEV risks.

Status

Unresolved

Info

Truncated Code Prevents Full Audit

The provided contract text for AgentToken is truncated. Critical sections of the contract, including the full implementation of ERC20 transfer functions, tax calculation and auto-swap logic (_swapAndSendTax), and bot protection mechanisms, are missing. This prevents a comprehensive security analysis of the entire contract's functionality and potential interactions.I-01

Issue

The provided contract text for AgentToken is truncated. Critical sections of the contract, including the full implementation of ERC20 transfer functions, tax calculation and auto-swap logic (_swapAndSendTax), and bot protection mechanisms, are missing. This prevents a comprehensive security analysis of the entire contract's functionality and potential interactions.

Fix

Provide the complete and unabridged source code for all contracts intended for audit to enable a thorough and accurate security assessment.

Status

Unresolved

Analysis

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

The AgentToken contract implements a custom ERC20-like token with tax mechanisms, bot protection, and Uniswap V2 integration. The contract uses OpenZeppelin's upgradeable patterns and 2-step ownership. A critical issue was identified regarding the absence of core ERC20 transfer functions in the provided code, rendering it non-functional as a standard token. Additionally, significant centralization risks exist due to the onlyOwnerOrFactory modifier.

Technical6/10Medium risk

The contract leverages OpenZeppelin's upgradeable patterns and EnumerableSet for efficient management of liquidity pools and valid callers (7.1 Architecture). However, a critical functional flaw exists where core ERC20 transfer functions are missing from the provided code, rendering the token non-functional as a standard ERC20 (7.2 Code Security). Additionally, the onlyOwnerOrFactory modifier centralizes control over key operational parameters (7.3 Access Control).

Governance1/10High risk

The contract's economic model includes buy and sell taxes, and an auto-swap mechanism for tax collection, which are common in DeFi (7.4 Economic). However, the onlyOwnerOrFactory modifier grants significant power to the owner and factory, allowing them to modify tax recipients, swap thresholds, and manage liquidity pools (7.5 Governance). This high degree of centralization introduces a single point of failure and potential for misuse.

Upgrades1/10High risk

The contract correctly implements OpenZeppelin's Initializable pattern, including _disableInitializers() in the constructor and an initialize function, ensuring proper upgrade safety (7.7 Upgrades). State variables are declared with appropriate visibility (internal, private) to prevent storage slot collisions during upgrades. The use of Ownable2StepUpgradeable also enhances the security of ownership transfers in an upgradeable context.

Final RecommendationWhat to do about this score

Address the critical issue of missing ERC20 core functions to ensure the token is functional and compliant with the standard.

Review the extent of centralized control granted by the onlyOwnerOrFactory modifier and consider implementing a more decentralized governance model or multi-signature wallet for critical operations to mitigate single points of failure. Implement robust testing for all token functionalities, especially the tax and bot protection mechanisms, once the full code is available.

Contract & Record

1 audit on record
TypeAgentToken
NetworkBase
Token age1y
Contract0x1c4c…63a3
Deployer0xd384…b8ef
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
GAME 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, 202671High
  2. Aug 30, 202662Medium

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

Frequently Asked Questions

What is the GAME contract address?

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

Is GAME by Virtuals a scam?

Quantum Audit's risk score for GAME by Virtuals is 71/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 GAME liquidity locked?

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

Who holds GAME?

As of Sep 4, 2026, the 10 largest holders own 48.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
XMAQUINADEUS · Base71HighTownsBase71HighICPBase71HighMAGICBase71HighRecallBase72HighVANRYBase72High

Would You Like a More Detailed Audit of GAME 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