Quantum Audit Logo

Is niulai a Scam?

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

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

niulai NIULAI
0x3604…0111
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 17h old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Critical1 High2 Medium1 Low1 Informational
! 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.
Volume 24h
$16.7K
Liquidity
$109.9K
Price
$0.001215
Token Age
17h
Top 10 Holders
90.1%

Security Findings

1 Crit1 High2 Med1 Low1 Info
Critical

Missing Critical Functionality (`_processTax`)

C-01The `_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).
IssueThe `_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).
FixImplement 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.
StatusUnresolved
High

Inconsistent Upgradeability Pattern Usage

H-01The 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…
IssueThe 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…
FixClarify 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.
StatusUnresolved
Medium

High Owner Privileges and Centralization Risk

M-01The `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).
IssueThe `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).
FixConsider 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.
StatusUnresolved
Medium

Complex `_transfer` Logic and State Machine

M-02The `_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).
IssueThe `_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).
FixRefactor 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.
StatusUnresolved
Low

Reliance on `block.timestamp` for Critical State Transitions

L-01The `_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).
IssueThe `_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).
FixFor 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.
StatusUnresolved
Info

Unused `MIN_LIQ_THRESHOLD` and `initialLiquidationThreshold`

I-01The `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).
IssueThe `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).
FixReview 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceMedium4/10

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

UpgradesMedium4/10

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.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

90.1% in top 10
55.5% in wallets34.7% in contracts
Effective Concentration69.3%

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

$109.9K

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

1 addresses
Deployer
0x722d…e66e

What Raised This Score

8 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

Related Audits

6 more on the record
Slap Cat (SLAP)High RiskUnitas (UP)High RiskRICE AI (RICE)High RiskPrometeus (PROM)High RiskDAPPOS (DOS)High RiskDeAgentAI (AIA)High Risk

Would You Like a More Detailed Audit of niulai?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit