Quantum Audit Logo
Launch App

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

Is Valtherix AI Safe?

VLTXBase
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
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades4/10Checks passed3 of 5Findings2 Critical · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The Valtherix AI Token contract, written in Vyper, implements basic ERC-20 functionality.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 70%
  • 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%
  • Token age < 30 days
  • 2 Critical finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 70% (78.4% total → 75.4% effective; 73.4% in EOAs, 5.0% in contracts — extreme)
  • 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 30 days (still settling)
  • 2 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 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
5.0%Contracts73.4%Wallets21.6%Everyone else
5.0%73.4%Wallets21.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
78.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking5.0%
  • Walletsanonymous holders, free to sell73.4%
  • Everyone elsethe rest of the supply21.6%
Effective concentrationwhat the score reads75.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$424.6K

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$424.6KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x08f9…6bbd

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

Security Findings

2 Critical1 Medium1 Low1 Info
Critical

Immediate Ownership Renunciation

The __init__ function calls `self.transferOwnership(0x0000…0000)`, which immediately transfers ownership to the zero address. This effectively renounces ownership of the contract, meaning no entity will have administrative control over the token contract after deployment. This prevents any future upgrades, parameter changes, or bug fixes, making the contract immutable and unmanageable.C-01

Issue

The __init__ function calls `self.transferOwnership()`, which immediately transfers ownership to the zero address. This effectively renounces ownership of the contract, meaning no entity will have administrative control over the token contract after deployment. This prevents any future upgrades, parameter changes, or bug fixes, making the contract immutable and unmanageable.

Fix

If administrative control is desired, remove the transferOwnership(0x0) call from the __init__ function and instead transfer ownership to a designated multisig wallet or governance contract. If immutability is the explicit design choice, ensure all functionalities are thoroughly audited and tested, and clearly document this design decision.

Status

Unresolved

Critical

Unintended Native Token Draining Mechanism

The transfer and transferFrom functions contain the line self.feeWallet.send(value = self.balance). This attempts to send the *entire native token balance* (e.g., ETH on Ethereum, MATIC on Polygon) held by the token contract to the feeWallet address on every token transfer. Token contracts are generally not intended to hold native tokens, and if native tokens are accidentally sent to this contract, they will be drained to the feeWallet with every subsequent token transfer, leading to a critical loss of funds.C-02

Issue

The transfer and transferFrom functions contain the line self.feeWallet.send(value = self.balance). This attempts to send the *entire native token balance* (e.g., ETH on Ethereum, MATIC on Polygon) held by the token contract to the feeWallet address on every token transfer. Token contracts are generally not intended to hold native tokens, and if native tokens are accidentally sent to this contract, they will be drained to the feeWallet with every subsequent token transfer, leading to a critical loss of funds.

Fix

Remove the line self.feeWallet.send(value = self.balance) from both transfer and transferFrom functions. If a fee mechanism is intended, it should be carefully designed to handle token fees (not native token fees from the contract's balance) and clearly documented.

Status

Unresolved

Medium

Unused Interface and Dead Code

The UniswapRouterV2 interface is imported but never utilized within the contract. Additionally, the checkSum function takes six uint256 parameters, sums them, and returns True if the sum is zero, but this function is never called internally or externally and serves no apparent purpose. Unused code increases contract size, deployment costs, and audit complexity without providing any functional benefit.M-01

Issue

The UniswapRouterV2 interface is imported but never utilized within the contract. Additionally, the checkSum function takes six uint256 parameters, sums them, and returns True if the sum is zero, but this function is never called internally or externally and serves no apparent purpose. Unused code increases contract size, deployment costs, and audit complexity without providing any functional benefit.

Fix

Remove the interface UniswapRouterV2 declaration if it's not intended for use. Similarly, remove the checkSum function if it is dead code. Only include necessary code to reduce contract footprint and improve readability.

Status

Unresolved

Low

Redundant State Variables

The state variables lastFrom, lastTo, and sender are updated in transfer and transferFrom functions. However, they only store the details of the *last* transaction and are immediately overwritten by the next. They do not contribute to the core ERC-20 functionality, security, or any apparent operational logic of the token. Storing these variables consumes gas and storage unnecessarily.L-01

Issue

The state variables lastFrom, lastTo, and sender are updated in transfer and transferFrom functions. However, they only store the details of the *last* transaction and are immediately overwritten by the next. They do not contribute to the core ERC-20 functionality, security, or any apparent operational logic of the token. Storing these variables consumes gas and storage unnecessarily.

Fix

Remove the lastFrom, lastTo, and sender state variables and their assignments from the transfer and transferFrom functions. If tracking transaction history is required, it should be done off-chain by monitoring emitted events.

Status

Unresolved

Info

Vyper Version and EVM Version Pragmas

The contract includes # @pragma evm-version cancun and #pragma version ^0.3.10. While Vyper 0.3.10 supports Cancun, the @pragma evm-version syntax is more commonly associated with Solidity. For Vyper, specifying the evm-version in the compiler command or configuration is typical, rather than as a pragma within the source file.I-01

Issue

The contract includes # @pragma evm-version cancun and #pragma version ^0.3.10. While Vyper 0.3.10 supports Cancun, the @pragma evm-version syntax is more commonly associated with Solidity. For Vyper, specifying the evm-version in the compiler command or configuration is typical, rather than as a pragma within the source file.

Fix

Ensure consistent and standard pragma usage for Vyper. While not a vulnerability, adhering to standard practices improves clarity and tooling compatibility. Consider removing the @pragma evm-version cancun line if it's not the standard Vyper way to specify the EVM version.

Status

Unresolved

Analysis

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

The Valtherix AI Token contract, written in Vyper, implements basic ERC-20 functionality. The audit identified critical vulnerabilities related to immediate ownership renunciation and an unintended native token draining mechanism. These issues pose significant risks to the project's long-term viability and potential loss of funds if native tokens are sent to the contract. Additionally, there are minor issues concerning unused code and redundant state variables.

Technical4/10Medium risk

The contract implements standard ERC-20 functions for token transfers and approvals (7.1 Architecture). However, a critical design flaw exists where the contract immediately renounces ownership upon deployment (7.3 Access Control), making it unmanageable. A severe code security vulnerability (7.2 Code Security) is present in the transfer and transferFrom functions, which attempt to send the contract's entire native token balance to a feeWallet on every token transfer (7.6 External). This could lead to unintended loss of funds if native tokens are sent to the contract. Unused interfaces and dead code also contribute to unnecessary complexity (7.2 Code Security).

Governance1/10High risk

The economic model of the token is primarily standard ERC-20, but a critical flaw introduces an severe economic risk (7.4 Economic). The contract attempts to drain its entire native token balance to a feeWallet during every token transfer, which is highly unusual and could lead to significant loss of funds if native tokens are accidentally sent to the contract. From a governance perspective (7.5 Governance), the contract has no governance mechanism or owner, as ownership is renounced immediately upon deployment, rendering it immutable and unmanageable.

Upgrades4/10Medium risk

The contract is not designed with any upgradeability mechanism (7.7 Upgrades). Furthermore, the immediate renunciation of ownership in the constructor means that even if an upgrade pattern were intended, it would be impossible to implement or manage post-deployment. This makes the contract immutable and any discovered bugs or required feature changes cannot be addressed.

Final RecommendationWhat to do about this score

It is strongly recommended to address the critical vulnerabilities before deployment or continued use.

The immediate ownership renunciation prevents any future management or bug fixes, and the native token draining mechanism poses a direct threat to any native funds sent to the contract. A complete redesign or significant refactor is advisable to ensure the contract's security and long-term viability. Consider implementing a robust access control mechanism and removing the problematic fee wallet interaction.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age19d
Contract0x3329…5b6b
Deployer0xa967…cc68
Badge for your website
Valtherix AI 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, 202694Critical
  2. Aug 11, 2026100Critical

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

Related Audits

6 more on the recordAll audits
IntuitionTRUST · Base98CriticalMineBeanBEAN · Base89CriticalTevaeraTEVA · Base100CriticalStrike RobotSR · Base87CriticalCrynux TokenCNX · Base87CriticalFLock.ioFLOCK · Base85Critical

Would You Like a More Detailed Audit of Valtherix AI?

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