Early-stage security check — honeypot & rug-pull analysis

Is niulai a Scam?

NIULAI

BNB Chain

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 recordNew Launch · 17h old

Chart

59/ 100

Medium RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical6/10 Governance4/10 Upgrades4/10 Checks passed4 of 5 Findings1 Critical · 1 High · 2 Medium · 1 Low · 1 Info6

SummaryAI Copilot

The CosmTaxToken contract implements an ERC-20 token with a complex tax mechanism and a multi-state machine.

Read the full analysis

What raised the score

Proxy contract
Non-standard proxy storage
Top-10 concentration > 50%
Token age < 24h
1 Critical finding(s) from audit
1 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Exact factors

Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Top-10 concentration > 50% (90.1% total → 69.3% effective; 55.5% in EOAs, 34.7% in contracts — heavy)
Token age < 24h (brand new — bot activity, unproven)
1 Critical finding(s) from audit
1 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

Early-stage analysis. This token has limited on-chain history (17h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 44 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

90.1%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking34.7%
Walletsanonymous holders, free to sell55.5%
Everyone elsethe rest of the supply9.9%

Effective concentrationwhat the score reads69.3%

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$109.9K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$109.9KShare of depth100.0%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Security Findings

1 Critical1 High2 Medium1 Low1 Info

Critical

Missing Critical Functionality (`_processTax`)

The _processTax internal function, which is crucial for handling accumulated tax tokens, is called within _liquidateTax but its implementation is entirely missing from the provided source code. This renders the core tax mechanism non-functional and prevents the protocol from processing and distributing collected taxes, leading to a complete failure of a primary contract feature (7.2 Code Security, 7.8 Operations).C-01

Issue

Fix

Implement the _processTax function with the intended logic for tax distribution, liquidity provision, or other specified uses. Ensure it handles external calls securely (e.g., reentrancy guards) and aligns with the protocol's economic model.

Status

Unresolved

High

Inconsistent Upgradeability Pattern Usage

The contract CosmTaxToken inherits from OpenZeppelin Upgradeable contracts (e.g., ERC20PermitUpgradeable, OwnableUpgradeable) and uses the initializer pattern. However, the provided metadata indicates is_proxy: false and implementation: null, suggesting it's deployed directly as a standalone contract, not as an implementation behind a proxy. This misapplication of the upgradeability pattern leads to unnecessary complexity, gas overhead, and potentially confusion regarding the contract's intended lifecycle. If direct deployment is intended, Upgradeable contracts should not be used. If upgradeability is intended, it must be deployed behind a proxy (7.1 Architecture, 7.7 Upgrad…H-01

Issue

Fix

Clarify the intended deployment strategy. If upgradeability is desired, deploy CosmTaxToken as an implementation contract behind a proxy (e.g., UUPS proxy). If upgradeability is not required, refactor the contract to use standard (non-upgradeable) OpenZeppelin contracts and remove the initializer pattern.

Status

Unresolved

Medium

High Owner Privileges and Centralization Risk

The onlyOwner role has significant control over critical contract parameters and state transitions. Functions like setDexTaxExempt, startMigration, and finalizeMigration allow the owner to unilaterally change the contract's operational state and tax exemptions. This centralization introduces a single point of failure and potential for malicious or compromised owner actions to impact all token holders (7.3 Access Control, 7.5 Governance).M-01

Issue

Fix

Consider implementing a multi-signature wallet for the owner address to reduce single-point-of-failure risk. For critical state changes, explore time-locks or governance mechanisms to introduce a delay or community oversight.

Status

Unresolved

Medium

Complex `_transfer` Logic and State Machine

The _transfer function contains a complex series of if-else if statements based on the PoolState enum, leading to multiple execution paths. This complexity increases the likelihood of subtle bugs, unexpected behavior, or edge cases being missed, especially concerning tax calculations and pool interactions. The _liquidateTax function, called at the beginning of _transfer, also modifies poolState, adding to the complexity (7.1 Architecture, 7.2 Code Security).M-02

Issue

Fix

Refactor the _transfer logic to improve readability and reduce complexity. Consider using a state-machine pattern with clearer transitions and encapsulated logic for each state. Thoroughly test all possible state transitions and their impact on transfers and tax calculations.

Status

Unresolved

Low

Reliance on `block.timestamp` for Critical State Transitions

The _liquidateTax function uses block.timestamp to determine when taxExpirationTime and antiFarmerExpirationTime have passed, triggering PoolState changes. While block.timestamp is generally reliable, miners have a limited ability to manipulate it (typically within a few seconds of actual time). This could potentially allow for minor front-running or back-running opportunities for state transitions, though the impact might be limited given the long durations involved (7.4 Economic).L-01

Issue

Fix

For time-sensitive operations, consider using a time oracle or a more robust time-keeping mechanism if the exact timing of state transitions is critical and susceptible to minor manipulation. For durations of days/years, the risk is generally acceptable.

Status

Unresolved

Info

Unused `MIN_LIQ_THRESHOLD` and `initialLiquidationThreshold`

The MIN_LIQ_THRESHOLD immutable variable is set in the constructor but does not appear to be used anywhere else in the provided code. Similarly, initialLiquidationThreshold is set in initialize but its usage is not visible. The liquidationThreshold within PackedPoolState is used, but it's initialized with START_LIQ_THRESHOLD, not initialLiquidationThreshold (7.2 Code Security).I-01

Issue

Fix

Review the contract logic to determine if MIN_LIQ_THRESHOLD and initialLiquidationThreshold are intended for future use or if they can be removed to reduce contract size and complexity. Ensure that liquidationThreshold is correctly managed and updated if initialLiquidationThreshold was meant to play a role.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The CosmTaxToken contract implements an ERC-20 token with a complex tax mechanism and a multi-state machine. A critical vulnerability was identified where the _processTax function, essential for handling accumulated tax tokens, is missing its implementation. Additionally, the contract uses upgradeable patterns but appears to be deployed directly, indicating a potential architectural mismatch. High owner privileges and complex internal logic also contribute to the overall risk profile.

Technical6/10Medium risk

The contract utilizes OpenZeppelin's upgradeable ERC20 and Ownable components, demonstrating a foundation of well-audited libraries. It employs a PackedPoolState struct for gas efficiency and includes a reentrancy guard (notLiquidating) in its tax liquidation logic (7.2 Code Security). However, a critical issue is the complete absence of the _processTax function's implementation (7.2 Code Security), rendering the core tax mechanism non-functional. The _transfer function also exhibits high complexity with multiple conditional branches based on PoolState (7.1 Architecture), increasing the risk of subtle bugs.

Governance4/10Medium risk

The contract benefits from a clearly defined onlyOwner role for critical administrative functions, such as setting tax exemptions and managing migration states. The tax mechanism includes anti-farmer durations and dynamic tax rates, aiming to manage token economics. However, the owner possesses significant centralized control over key parameters and state transitions (7.3 Access Control), posing a single point of failure risk. Furthermore, the reliance on block.timestamp for critical state changes, while common, introduces a minor risk of miner manipulation (7.4 Economic).

Upgrades4/10Medium risk

The contract is built using OpenZeppelin's upgradeable contracts and the initializer pattern, suggesting an intent for future upgradeability. This provides a robust framework for potential future enhancements or bug fixes. However, the contract appears to be deployed directly rather than as an implementation behind a proxy (7.7 Upgrades), which is a significant architectural inconsistency. This misuse means the upgradeability features are not being utilized as intended, adding unnecessary complexity and gas overhead without the benefit of actual upgradeability.

Final RecommendationWhat to do about this score

Address the critical missing _processTax implementation immediately to ensure the core tax mechanism functions as intended.

Clarify and align the contract's upgradeability strategy; either deploy it behind a proxy if upgrades are desired, or refactor to use standard OpenZeppelin contracts if not. Implement a multi-signature wallet for the owner address to mitigate centralization risks and consider time-locks for highly sensitive administrative actions. Thoroughly review and simplify the _transfer logic to enhance maintainability and reduce the potential for errors.

Contract & Record

1 audit on record

TypeCosmTaxToken

NetworkBNB Chain

Token age17h

Contract0x3604…0111

Deployer0x722d…e66e

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

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

Sep 4, 202659Medium
Aug 16, 202648Medium

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

Frequently Asked Questions

What is the NIULAI contract address?

The niulai contract on BNB Chain is 0x3604b5c377124d2180c4fb791953fc8431a90111. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.