Is GAME by Virtuals (GAME) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Med1 Low1 Info

Critical

Incomplete ERC20 Implementation (Missing Core Functions)

C-01The `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.

IssueThe `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.

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

StatusUnresolved

Medium

Centralization Risk with `onlyOwnerOrFactory` Modifier

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

IssueThe `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.

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

StatusUnresolved

Low

Potential for Slippage and MEV in Initial Liquidity Provision

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

IssueThe `_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.

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

StatusUnresolved

Info

Truncated Code Prevents Full Audit

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

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

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh1/10

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.

UpgradesHigh1/10

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.

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

48.7% in top 10

25.5% in wallets23.2% in contracts

Effective Concentration34.8%

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

$2.66M across 12 pairs

Uniswap v2VIRTUALanalysed$2.64M AerodromeWETH$9.2K Uniswap v3WETH$4.7K Uniswap v3VIRTUAL$4.0K AerodromeWETH$344 Uniswap v3USDC$325

Show 4 more pairsShow less

AerodromeVIRTUAL$46 Uniswap v3VIRTUAL$40 0xE82F…5eB8uBCH$16 SushiswapZORA$4

The 2 remaining pairs hold $4 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 Holder67.3%

Top-3 Unlocked92.9%

Key Addresses

9 addresses

Deployer

0xd384…b8ef

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.

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

Is GAME by Virtuals Safe?

Security Findings

Incomplete ERC20 Implementation (Missing Core Functions)

Centralization Risk with `onlyOwnerOrFactory` Modifier

Potential for Slippage and MEV in Initial Liquidity Provision

Truncated Code Prevents Full Audit

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of GAME by Virtuals?