Is Valtherix AI (VLTX) Safe? Smart Contract Security Analysis

Security Findings

2 Crit1 Med1 Low1 Info

Critical

Immediate Ownership Renunciation

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

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

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

StatusUnresolved

Critical

Unintended Native Token Draining Mechanism

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

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

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

StatusUnresolved

Medium

Unused Interface and Dead Code

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

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

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

StatusUnresolved

Low

Redundant State Variables

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

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

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

StatusUnresolved

Info

Vyper Version and EVM Version Pragmas

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

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

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

StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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.

UpgradesMedium4/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

78.4% in top 10

73.4% in wallets5.0% in contracts

Effective Concentration75.4%

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

$424.6K

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

0xa967…cc68

Unlocked LP Held By

0x08f9…6bbd

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

What Raised This Score

9 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

Is Valtherix AI Safe?

Security Findings

Immediate Ownership Renunciation

Unintended Native Token Draining Mechanism

Unused Interface and Dead Code

Redundant State Variables

Vyper Version and EVM Version Pragmas

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 Valtherix AI?