Is Neiro a Scam? Security Analysis

Security Findings

1 Crit2 High2 Med1 Low1 Info

Critical

Unlocked Liquidity Pool (Rug Pull Risk)

C-01The 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)

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

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

StatusUnresolved

High

Immutable Critical Economic Parameters

H-01Key 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)

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

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

StatusUnresolved

High

Unchangeable Tax Wallet Address

H-02The `_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)

IssueThe `_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)

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

StatusUnresolved

Medium

Complex and Potentially Manipulable Dynamic Tax Mechanism

M-01The 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)

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

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

StatusUnresolved

Medium

Permanent Exile List

M-02The `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)

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

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

StatusUnresolved

Low

Impact of Renouncing Ownership

L-01The `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)

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

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

StatusUnresolved

Info

First Block Buy Limit

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

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

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh3/10

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.

UpgradesLow8/10

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.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

73.5% in top 10

68.7% in wallets4.8% in contracts

Effective Concentration70.6%

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

$3.68M across 4 pairs

Uniswap v2WETHanalysed$3.54M Uniswap v3WETH$133.4K Uniswap v3WETH$633

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 Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

9 addresses

Deployer

0xc35d…dfcb

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.

What Raised This Score

5 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

Is Neiro a Scam?

Security Findings

Unlocked Liquidity Pool (Rug Pull Risk)

Immutable Critical Economic Parameters

Unchangeable Tax Wallet Address

Complex and Potentially Manipulable Dynamic Tax Mechanism

Permanent Exile List

Impact of Renouncing Ownership

First Block Buy Limit

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 Neiro?