Quantum Audit Logo

Is NeuralAI Safe?

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

Is this your token? Publish your own audit on this page →

NeuralAI NEURAL
0x32b0…e6e1
Ethereum
Not verifiedThis 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 9d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The NeuralAI token contract exhibits critical technical flaws, including a severe bug in `transferFrom` and a failure to mint initial supply, rendering it non-functional. Furthermore, the liquidity pool lock has expired, posing a significant rug pull risk. The contract also features high centralization of control and high transaction fees.

1 Critical3 High1 Medium1 Low
Volume 24h
$63.6K
Liquidity
$538.3K
Price
$0.6344
Token Age
2y
Top 10 Holders
29.4%

Security Findings

1 Crit3 High1 Med1 Low
Critical

No Initial Supply Minted in Constructor

C-01The `NeuralAI` contract's constructor calls the `ERC20` constructor but does not include a call to `_createInitialSupply` or any other minting mechanism. As a result, the `_totalSupply` remains 0, and no tokens are ever created or assigned to any address. This renders the token completely non-functional from deployment.
IssueThe `NeuralAI` contract's constructor calls the `ERC20` constructor but does not include a call to `_createInitialSupply` or any other minting mechanism. As a result, the `_totalSupply` remains 0, and no tokens are ever created or assigned to any address. This renders the token completely non-functional from deployment.
FixAdd a call to `_createInitialSupply(msg.sender, totalSupply)` or a similar minting function within the `NeuralAI` constructor to initialize the token supply and assign it to the deployer or a designated address.
StatusUnresolved
High

LP Lock Expired / Rug Pull Risk

H-01The provided prefill data indicates that the liquidity pool lock status is 'lock_expired' and 'lp_unlock_days_remaining' is -540. This means the liquidity provided to the `uniswapV2Pair` is no longer locked and can be withdrawn by the liquidity provider at any time. This poses a severe rug pull risk, as the project owner or initial liquidity provider could remove all liquidity, making the token untradable and worthless.
IssueThe provided prefill data indicates that the liquidity pool lock status is 'lock_expired' and 'lp_unlock_days_remaining' is -540. This means the liquidity provided to the `uniswapV2Pair` is no longer locked and can be withdrawn by the liquidity provider at any time. This poses a severe rug pull risk, as the project owner or initial liquidity provider could remove all liquidity, making the token untradable and worthless.
FixRe-lock the liquidity for a significant period (e.g., 1-5 years) using a reputable locker service. Provide verifiable proof of the new lock to the community to restore trust and mitigate the rug pull risk.
StatusUnresolved
High

Non-Standard `transferFrom` Logic

H-02The `transferFrom` function deviates from the standard ERC20 implementation. It first calls `_transfer` (which moves tokens) and *then* checks the allowance and deducts it. While the transaction will revert if the allowance is insufficient, this order of operations is non-standard and can lead to wasted gas for users attempting `transferFrom` with insufficient allowance, as the `_transfer` operation would have already consumed gas before the revert.
IssueThe `transferFrom` function deviates from the standard ERC20 implementation. It first calls `_transfer` (which moves tokens) and *then* checks the allowance and deducts it. While the transaction will revert if the allowance is insufficient, this order of operations is non-standard and can lead to wasted gas for users attempting `transferFrom` with insufficient allowance, as the `_transfer` operation would have already consumed gas before the revert.
FixRefactor the `transferFrom` function to first check and deduct the allowance, and only then proceed with the `_transfer` of tokens. This aligns with the ERC20 standard and optimizes gas usage for failed transactions.
StatusUnresolved
High

High Centralization of Control

H-03The `Ownable` pattern grants the contract owner extensive power over critical contract parameters and functions. The owner can modify transaction fees, maximum buy/sell/wallet amounts, enable/disable trading, exclude addresses from fees/limits, and transfer any foreign tokens sent to the contract. This high degree of centralization introduces a single point of failure and significant trust assumptions on the owner.
IssueThe `Ownable` pattern grants the contract owner extensive power over critical contract parameters and functions. The owner can modify transaction fees, maximum buy/sell/wallet amounts, enable/disable trading, exclude addresses from fees/limits, and transfer any foreign tokens sent to the contract. This high degree of centralization introduces a single point of failure and significant trust assumptions on the owner.
FixConsider implementing a multi-signature wallet for ownership or transitioning to a time-locked governance mechanism for critical parameter changes. For functions like `transferForeignToken`, consider adding a delay or a community vote mechanism to enhance security and transparency.
StatusUnresolved
Medium

High Transaction Fees

M-01The initial `buyFee` and `sellFee` are set to 30 (implying 30%). Such high transaction fees can significantly deter adoption, reduce trading volume, and make the token less attractive for users and exchanges. While the owner can change these, the initial setting is very high and could negatively impact the project's ecosystem.
IssueThe initial `buyFee` and `sellFee` are set to 30 (implying 30%). Such high transaction fees can significantly deter adoption, reduce trading volume, and make the token less attractive for users and exchanges. While the owner can change these, the initial setting is very high and could negatively impact the project's ecosystem.
FixRe-evaluate the fee structure. Consider implementing lower, more competitive fees to encourage adoption and trading. Clearly communicate the fee mechanism and any potential changes to the community.
StatusUnresolved
Low

`transferForeignToken` Function Scope

L-01The `transferForeignToken` function allows the owner to withdraw any ERC20 token accidentally sent to the contract. While useful for recovery, it grants the owner the power to withdraw any token without specific checks or community approval, which could be misused if the owner's key is compromised or if the owner acts maliciously.
IssueThe `transferForeignToken` function allows the owner to withdraw any ERC20 token accidentally sent to the contract. While useful for recovery, it grants the owner the power to withdraw any token without specific checks or community approval, which could be misused if the owner's key is compromised or if the owner acts maliciously.
FixWhile this function is common for recovery, consider enhancing its security by adding a time-lock or requiring multi-signature approval for withdrawing significant amounts of non-native tokens. This adds a layer of protection against potential misuse.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract implements the ERC20 standard with additional features like anti-whale limits and a swap-and-liquify mechanism. It uses Solidity 0.8.12, benefiting from automatic overflow/underflow checks. However, a significant technical flaw exists where the `_createInitialSupply` function is not called in the constructor, resulting in zero total supply and rendering the token non-functional (7.2 Code Security). Additionally, the `transferFrom` function deviates from the standard ERC20 pattern by checking allowance after the internal transfer, potentially leading to wasted gas on reverted transactions (7.2 Code Security).

GovernanceHigh2/10

The contract design exhibits high centralization, with the owner possessing extensive control over critical parameters such as transaction fees, maximum buy/sell/wallet amounts, and the ability to enable/disable trading (7.3 Access Control, 7.5 Governance). This introduces significant trust assumptions. Economically, the provided prefill data indicates that the liquidity pool lock has expired, presenting a critical rug pull risk (7.4 Economic). Furthermore, the initial buy and sell fees are set at a high 30%, which could deter token adoption and trading activity (7.4 Economic).

UpgradesMedium6/10

The contract is not designed with an upgrade proxy pattern, meaning it is not upgradeable (7.7 Upgrades). This implies that any discovered vulnerabilities or desired feature enhancements post-deployment cannot be implemented without deploying a new contract and migrating all assets and users, which is a complex and risky process. The lack of upgradeability necessitates thorough pre-deployment auditing.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

29.4% in top 10
4.6% in wallets24.9% in contracts
Effective Concentration14.5%

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

$538.3K

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

LP Locked99.1% · Null Address, TeamFinance
Top-1 Unlocked Holder0.6%
Lock ExpiryExpired 540d ago

Key Addresses

7 addresses
Deployer
0x5ad3…f851
Unlocked LP Held By
0xefe9…74450xf8a9…155a0x4218…32890x71e5…eb5a0xb3ac…68a00x0000…8a90

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

What Raised This Score

5 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • 1 Critical finding(s) from audit
  • 3 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

Related Audits

6 more on the record
Helix Token (HLX)High RiskEuler (EUL)High RiskQuant (QNT)High RiskMorphoHigh RiskBeamHigh RiskSuperVerse (SUPER)High Risk

Would You Like a More Detailed Audit of NeuralAI?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit