Honeypot, rug-pull and ownership checks

Is Neiro a Scam?

NEIRO

Ethereum

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

42/ 100

Medium RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical6/10 Governance3/10 Upgrades8/10 Checks passed5 of 5 Findings1 Critical · 2 High · 2 Medium · 1 Low · 1 Info7

SummaryAI Copilot

The Neiro token contract implements standard ERC-20 functionality with custom tokenomics including dynamic taxes, anti-whale mechanisms, and Uniswap integration.

Read the full analysis

What raised the score

Top-10 concentration > 70%
1 Critical finding(s) from audit
2 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Exact factors

Top-10 concentration > 70% (73.5% total → 70.6% effective; 68.7% in EOAs, 4.8% in contracts — extreme)
1 Critical finding(s) from audit
2 High finding(s) from audit
2 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

Our automated scanner reviewed Neiro (NEIRO) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 45 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

73.5%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking4.8%
Walletsanonymous holders, free to sell68.7%
Everyone elsethe rest of the supply26.5%

Effective concentrationwhat the score reads70.6%

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$3.68M across 4 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$3.54MShare of depth96.4%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Unlocked LP held by

0xb3ac…68a00x826f…1e650xe7a6…87280x3b72…d61f0x0000…8a900x1f2f…f3870xb76f…2e420x87c0…36d6

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

Security Findings

1 Critical2 High2 Medium1 Low1 Info

Critical

Unlocked Liquidity Pool (Rug Pull Risk)

The provided prefill data indicates that the liquidity pool (LP) for the Neiro token is currently unlocked. This allows the deployer or owner of the LP tokens to remove all or a significant portion of the liquidity at any time, leading to a 'rug pull' scenario where token holders are unable to sell their tokens, resulting in a complete loss of value. This is a critical trust and security issue for investors. (7.6 External, 7.4 Economic)C-01

Issue

Fix

Immediately lock the liquidity pool tokens with a reputable, audited locker service for a significant duration (e.g., 1-5 years or permanently). Provide verifiable proof of the LP lock to the community to build trust and mitigate this critical risk.

Status

Unresolved

High

Immutable Critical Economic Parameters

Key economic parameters such as _initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax, _reduceBuyTaxAt, _reduceSellTaxAt, _maxTxAmount, _maxWalletSize, _taxSwapThreshold, and _maxTaxSwap are hardcoded in the contract and lack owner-controlled setter functions. This design choice prevents any adjustment to the token's economic model, making it inflexible to market changes, necessary rebalancing, or correction of misconfigurations. (7.3 Access Control, 7.4 Economic)H-01

Issue

Fix

Implement onlyOwner functions to allow the contract owner to adjust these critical economic parameters within predefined, reasonable bounds. This provides necessary flexibility for protocol management while maintaining security. Consider a timelock for sensitive parameter changes.

Status

Unresolved

High

Unchangeable Tax Wallet Address

The _taxWallet address, which receives all collected transaction taxes, is set to the deployer's address in the constructor and cannot be changed post-deployment. If this address is compromised, lost, or needs to be updated for operational reasons (e.g., migration to a multi-signature wallet), all collected taxes will be sent to an unrecoverable or incorrect address, leading to a loss of funds. (7.3 Access Control, 7.8 Operations)H-02

Issue

Fix

Implement an onlyOwner function to allow the contract owner to update the _taxWallet address. It is highly recommended to use a multi-signature wallet or a timelock-controlled address for the tax wallet to enhance security and decentralization.

Status

Unresolved

Medium

Complex and Potentially Manipulable Dynamic Tax Mechanism

The token's tax mechanism is complex, featuring dynamic buy and sell taxes that change based on global transaction counters (_buyCount, sellCount) and predefined thresholds (_reduceBuyTaxAt, _reduceSellTaxAt). This complexity increases the risk of unexpected behavior, miscalculation, or potential manipulation by large buyers/sellers who could strategically time transactions to influence tax tiers for others. (7.4 Economic, 7.2 Code Security)M-01

Issue

Fix

Thoroughly test the dynamic tax mechanism under various simulated market conditions and transaction patterns to identify and mitigate potential exploits or unintended consequences. Consider simplifying the tax structure or making the thresholds more robust against manipulation to ensure fairness and predictability.

Status

Unresolved

Medium

Permanent Exile List

The isExile mapping, used to exempt specific addresses (owner, contract, Uniswap pair) from taxes and transaction limits, is initialized only in the constructor. There are no functions to add or remove addresses from this list post-deployment. This lack of flexibility could hinder future operational needs, such as exempting new exchange addresses or removing compromised/malicious addresses from the exemption list. (7.3 Access Control)M-02

Issue

Fix

Implement onlyOwner functions to allow the contract owner to add and remove addresses from the isExile list. This provides necessary administrative control to manage exemptions dynamically as the project evolves.

Status

Unresolved

Low

Impact of Renouncing Ownership

The renounceOwnership function is available, allowing the owner to transfer ownership to the zero address. If ownership is renounced, the contract becomes immutable in terms of administrative control. This means all onlyOwner functions, including setMarketPair and any future functions intended for parameter adjustments, would become permanently inaccessible. (7.3 Access Control, 7.5 Governance)L-01

Issue

Fix

Ensure a clear understanding of the implications before renouncing ownership. If immutability of administrative control is the desired long-term state, confirm that all necessary parameters are correctly configured and no future administrative actions will be required. Otherwise, consider not renouncing ownership or transferring it to a secure, multi-signature wallet.

Status

Unresolved

Info

First Block Buy Limit

The contract implements a specific mechanism to limit the number of buy transactions on the very first block (block.number == firstBlock) to 51 per block (perBuyCount[block.number] < 51). This is likely intended as an anti-bot or anti-whale measure during the initial launch phase. While a design choice, it could limit legitimate early participation or create a competitive environment for initial buys. (7.4 Economic)I-01

Issue

Fix

Clearly document this specific behavior for potential users and investors to manage expectations during the token launch. Ensure this mechanism aligns with the project's overall launch strategy and desired initial distribution.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The Neiro token contract implements standard ERC-20 functionality with custom tokenomics including dynamic taxes, anti-whale mechanisms, and Uniswap integration. While it utilizes SafeMath and a reentrancy guard for swaps, the audit identified a critical risk related to unlocked liquidity, alongside high risks concerning immutable economic parameters and an unchangeable tax wallet. Several medium and low-level issues also exist, primarily impacting access control and economic flexibility.

Technical6/10Medium risk

The contract demonstrates good practices by using SafeMath for arithmetic operations and implementing a reentrancy guard (lockTheSwap) for external calls to Uniswap (7.2 Code Security). However, the core _transfer function is complex due to multiple conditional tax calculations and anti-whale checks, increasing the potential for subtle bugs (7.1 Architecture). The lack of owner-controlled setters for critical economic parameters like _maxTxAmount and tax rates significantly limits the contract's adaptability and introduces high technical risk (7.3 Access Control).

Governance3/10High risk

The economic model features dynamic buy/sell taxes and anti-whale limits, which are intended to manage token distribution and price stability (7.4 Economic). However, the prefill indicates the liquidity pool is unlocked, posing a critical rug pull risk (7.6 External). Furthermore, the inability to adjust key economic parameters such as tax rates and transaction limits post-deployment, coupled with an unchangeable tax wallet, severely restricts the owner's ability to govern the token's economy or respond to market conditions (7.5 Governance). The complex tax mechanism, relying on global counters, also introduces potential for manipulation.

Upgrades8/10Low risk

The Neiro contract is not designed as an upgradeable proxy (7.7 Upgrades). This means its code is immutable once deployed, eliminating risks associated with upgrade mechanisms like proxy misconfigurations or malicious upgrades. However, it also implies that any identified vulnerabilities or desired feature changes cannot be addressed without a complete redeployment and migration.

Final RecommendationWhat to do about this score

Address the critical vulnerability of the unlocked liquidity pool immediately by locking LP tokens with a reputable service for a substantial duration.

Implement onlyOwner functions to allow for the adjustment of critical economic parameters (e.g., tax rates, transaction limits) and the _taxWallet address, ensuring operational flexibility and security. Thoroughly review and simplify the complex tax calculation logic to reduce the risk of unintended behavior or manipulation.

Contract & Record

1 audit on record

TypeRouter, Token

NetworkEthereum

Token age2y

Contract0x812b…53ee

Deployer0xc35d…dfcb

Badge for your website

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

Aug 11, 202642Medium

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

Frequently Asked Questions

What is the NEIRO contract address?

The Neiro contract on Ethereum is 0x812ba41e071c7b7fa4ebcfb62df5f45f6fa853ee. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.