Is 717ai by Virtuals (WIRE) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Incomplete Code for Critical Functionality

H-01The provided source code for the AgentToken contract is truncated, missing essential ERC-20 functions such as `transfer`, `transferFrom`, and `approve`, as well as the entire implementation of the tax calculation and auto-swap logic. This prevents a comprehensive security audit of the token's primary functionality and economic model, leaving critical attack vectors unexamined. Without these core components, it is impossible to assess potential reentrancy vulnerabilities, integer overflows in transfer amounts, or flaws in the tax collection and liquidity provision mechanisms.

IssueThe provided source code for the AgentToken contract is truncated, missing essential ERC-20 functions such as `transfer`, `transferFrom`, and `approve`, as well as the entire implementation of the tax calculation and auto-swap logic. This prevents a comprehensive security audit of the token's primary functionality and economic model, leaving critical attack vectors unexamined. Without these core components, it is impossible to assess potential reentrancy vulnerabilities, integer overflows in transfer amounts, or flaws in the tax collection and liquidity provision mechanisms.

FixProvide the complete and untruncated source code for the AgentToken contract, including all ERC-20 standard functions and the full implementation of the tax and auto-swap logic. A full audit cannot be performed without these critical components.

StatusUnresolved

Medium

Inconsistent `maxSupply` Type Check

M-01In the `_processSupplyParams` function, there is a check `erc20SupplyParameters_.maxSupply > type(uint128).max`. However, the contract's `_totalSupply` variable is declared as `uint256`. This check is either redundant if `_totalSupply` is truly intended to be `uint256` without an effective `uint128` limit, or it indicates a potential design inconsistency where the initial supply is limited to `uint128.max` but the total supply can theoretically exceed it, leading to confusion or unexpected behavior if not properly managed.

IssueIn the `_processSupplyParams` function, there is a check `erc20SupplyParameters_.maxSupply > type(uint128).max`. However, the contract's `_totalSupply` variable is declared as `uint256`. This check is either redundant if `_totalSupply` is truly intended to be `uint256` without an effective `uint128` limit, or it indicates a potential design inconsistency where the initial supply is limited to `uint128.max` but the total supply can theoretically exceed it, leading to confusion or unexpected behavior if not properly managed.

FixClarify the intended maximum supply limit. If `_totalSupply` is meant to be limited to `uint128.max`, consider changing its type to `uint128` or explicitly document why the check is present for a `uint256` variable. If no `uint128` limit is intended for `_totalSupply`, remove the misleading check.

StatusUnresolved

Low

Unclear `_autoSwapInProgress` State Management

L-01The `_autoSwapInProgress` flag is initialized to `true` in the `initialize` function and then set to `false` in `_addInitialLiquidity`. While this sequence appears intentional for initial setup, the full logic for how this flag is used, reset, or prevented from being manipulated in the missing `_transfer` or `_swapAndLiquify` functions is crucial. Improper management or lack of clear state transitions for this flag could lead to tax collection failures, unexpected swap behavior, or denial of service for the auto-swap mechanism.

IssueThe `_autoSwapInProgress` flag is initialized to `true` in the `initialize` function and then set to `false` in `_addInitialLiquidity`. While this sequence appears intentional for initial setup, the full logic for how this flag is used, reset, or prevented from being manipulated in the missing `_transfer` or `_swapAndLiquify` functions is crucial. Improper management or lack of clear state transitions for this flag could lead to tax collection failures, unexpected swap behavior, or denial of service for the auto-swap mechanism.

FixEnsure that the full implementation of the tax and auto-swap logic clearly defines and securely manages the state transitions of the `_autoSwapInProgress` flag. Implement robust checks to prevent unauthorized or unintended manipulation of this flag, and document its lifecycle thoroughly.

StatusUnresolved

Info

`validCallerCodeHashes` Mechanism Brittleness

I-01The contract includes a mechanism to add and remove `bytes32` code hashes for 'valid callers'. While this provides a form of granular access control, it can be brittle. If a valid caller contract undergoes an upgrade, its code hash will change, requiring manual updates to the `_validCallerCodeHashes` set. This also relies on the hash calculation being robust and consistent across different deployment environments and compiler versions.

IssueThe contract includes a mechanism to add and remove `bytes32` code hashes for 'valid callers'. While this provides a form of granular access control, it can be brittle. If a valid caller contract undergoes an upgrade, its code hash will change, requiring manual updates to the `_validCallerCodeHashes` set. This also relies on the hash calculation being robust and consistent across different deployment environments and compiler versions.

FixConsider the operational overhead and potential for errors when managing `validCallerCodeHashes`. If possible, explore alternative, more flexible access control mechanisms for contracts that are expected to be upgradeable. If this mechanism is critical, ensure clear documentation and operational procedures for updating hashes upon contract upgrades.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes OpenZeppelin's upgradeable patterns, `SafeERC20` for secure external token interactions, and `EnumerableSet` for managing dynamic lists, indicating a solid architectural foundation (7.1 Architecture). The `onlyOwnerOrFactory` modifier provides robust dual-admin control for sensitive functions (7.3 Access Control). However, the provided code is incomplete, missing critical ERC-20 transfer logic and the entire tax/auto-swap mechanism (7.2 Code Security). This truncation prevents a full assessment of reentrancy, integer overflows, or other vulnerabilities in the token's core operations. A minor inconsistency exists where `maxSupply` is checked against `type(uint128).max` while `_totalSupply` is `uint256` (7.2 Code Security).

GovernanceHigh2/10

The contract defines clear parameters for project buy/sell taxes, swap thresholds, and bot protection duration, indicating a structured economic model (7.4 Economic). The `onlyOwnerOrFactory` modifier ensures that critical economic parameters like `projectTaxRecipient` and `swapThresholdBasisPoints` can only be modified by authorized entities (7.5 Governance). However, a comprehensive economic analysis is severely hampered by the truncated code, as the actual tax calculation, collection, and auto-swap logic are entirely absent (7.4 Economic). This prevents evaluation of potential economic exploits, front-running opportunities, or manipulation of the tax mechanism. The interaction of `_autoSwapInProgress` with the missing tax logic is a key unknown (7.4 Economic).

UpgradesMedium6/10

The contract correctly implements the OpenZeppelin `Initializable` pattern, including `_disableInitializers()` in the constructor and the `initializer` modifier for the setup function. This standard approach minimizes common upgradeability risks like re-initialization or storage collisions with OpenZeppelin's own contracts (7.7 Upgrades). No specific upgradeability issues were identified within the provided code snippet. The custom storage variables are declared after inherited OpenZeppelin contracts, following best practices to avoid storage slot collisions (7.7 Upgrades).

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

27.2% in top 10

17.0% in wallets10.2% in contracts

Effective Concentration21.1%

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

$249.1K across 5 pairs

Uniswap v2VIRTUALanalysed$245.3K AerodromeUSDC$3.8K Uniswap v3VIRTUAL$16 Uniswap v3USDC$9 SushiswapSkiBonk+$0

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

0xeae7…5cf5

Unlocked LP Held By

0x492e…a66d

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

What Raised This Score

8 factors

Ownership NOT renounced — owner is an EOA (single private key)
Top-10 concentration > 20% (27.2% total → 21.1% effective; 17.0% in EOAs, 10.2% 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 = 98% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 98% 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

Not Signed In

Is 717ai by Virtuals Safe?

Security Findings

Incomplete Code for Critical Functionality

Inconsistent `maxSupply` Type Check

Unclear `_autoSwapInProgress` State Management

`validCallerCodeHashes` Mechanism Brittleness

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of 717ai by Virtuals?