Quantum Audit Logo

Is CSI888 a Scam?

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

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

CSI888 CSI
0x2f31…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and a multi-state pool system. The contract utilizes OpenZeppelin's upgradeable standards, ensuring a robust foundation. Key features include owner-controlled state transitions and an automated tax liquidation process involving external contracts. While the contract incorporates a reentrancy guard for its liquidation logic, significant risks stem from the high degree of owner control over critical parameters and external dependencies, as well as potential front-running opportunities related to tax liquidation. These factors contribute to an overall High risk level.

1 High2 Medium1 Low3 Informational
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$149.1800
Liquidity
$7.8K
Price
$0.000005648
Token Age
2d
Top 10 Holders
88.0%

Security Findings

1 High2 Med1 Low3 Info
High

External Call Trust and Potential for Malicious Tax Processor

H-01The `_liquidateTax` function makes external calls to `taxProcessor.processTax` and `dividendContract.distributeDividends`. While a reentrancy guard (`notLiquidating` flag) is in place to prevent re-entry into the liquidation logic, these external contracts are critical dependencies. If `taxProcessor` or `dividendContract` are malicious or compromised, they could perform arbitrary actions, including draining the accumulated tax tokens held by the `FlapTaxTokenV3` contract, or manipulating other aspects of the protocol. The `taxProcessor` and `dividendContract` addresses are set by the owner during initialization and cannot be changed.
IssueThe `_liquidateTax` function makes external calls to `taxProcessor.processTax` and `dividendContract.distributeDividends`. While a reentrancy guard (`notLiquidating` flag) is in place to prevent re-entry into the liquidation logic, these external contracts are critical dependencies. If `taxProcessor` or `dividendContract` are malicious or compromised, they could perform arbitrary actions, including draining the accumulated tax tokens held by the `FlapTaxTokenV3` contract, or manipulating other aspects of the protocol. The `taxProcessor` and `dividendContract` addresses are set by the owner during initialization and cannot be changed.
FixThoroughly audit the `taxProcessor` and `dividendContract` contracts to ensure their security and trustworthiness. Consider implementing a mechanism to update these addresses (e.g., via governance or a timelock) in case of compromise, or ensure they are immutable and fully trusted and verified.
StatusUnresolved
Medium

Centralization Risk via Owner Privileges

M-01The `startMigration` and `finalizeMigration` functions, which control critical state transitions (`BondingCurve` -> `Migrating` -> `TaxEnforcedAntiFarmer`), are protected by the `onlyOwner` modifier. This grants the contract owner significant power to unilaterally change the token's operational state, impacting tax rates and transfer restrictions. While `OwnableUpgradeable` is a standard pattern, the extent of control over core token mechanics by a single entity represents a centralization risk.
IssueThe `startMigration` and `finalizeMigration` functions, which control critical state transitions (`BondingCurve` -> `Migrating` -> `TaxEnforcedAntiFarmer`), are protected by the `onlyOwner` modifier. This grants the contract owner significant power to unilaterally change the token's operational state, impacting tax rates and transfer restrictions. While `OwnableUpgradeable` is a standard pattern, the extent of control over core token mechanics by a single entity represents a centralization risk.
FixConsider implementing a timelock for critical owner-controlled operations like state transitions to provide a delay for community review. Alternatively, explore a more decentralized governance mechanism (e.g., a DAO) for such sensitive actions.
StatusUnresolved
Medium

Potential for Front-running or Sandwich Attacks on Liquidation

M-02The `_liquidateTax` function is called at the beginning of every `_transfer` operation if the recipient (`to`) is the `mainPool`. If `mainPool` is a public DEX liquidity pool, and the conditions for tax liquidation are met (e.g., `taxAmount >= currentPoolState.liquidationThreshold`), a malicious actor could front-run a legitimate transfer to `mainPool` to trigger `_liquidateTax`. This could potentially allow manipulation of the liquidation process or profit from the resulting state changes, especially if the `taxProcessor` involves swaps or price-sensitive operations.
IssueThe `_liquidateTax` function is called at the beginning of every `_transfer` operation if the recipient (`to`) is the `mainPool`. If `mainPool` is a public DEX liquidity pool, and the conditions for tax liquidation are met (e.g., `taxAmount >= currentPoolState.liquidationThreshold`), a malicious actor could front-run a legitimate transfer to `mainPool` to trigger `_liquidateTax`. This could potentially allow manipulation of the liquidation process or profit from the resulting state changes, especially if the `taxProcessor` involves swaps or price-sensitive operations.
FixRe-evaluate the trigger mechanism for `_liquidateTax`. Consider making it an `onlyOwner` function, or implementing a delay, a minimum time between liquidations, or a more robust threshold mechanism to prevent immediate exploitation via front-running. Ensure `liqExpectedOutputAmount` (if used by `taxProcessor`) is handled with slippage protection.
StatusUnresolved
Low

Lack of Emergency Pause Mechanism

L-01The contract implements complex token transfer logic with dynamic tax rates and external interactions. In the event of an unforeseen bug, an exploit in a dependent contract, or a critical market event, there is no mechanism to pause token transfers or critical operations. This could lead to irreversible loss of funds or protocol instability before a fix can be deployed.
IssueThe contract implements complex token transfer logic with dynamic tax rates and external interactions. In the event of an unforeseen bug, an exploit in a dependent contract, or a critical market event, there is no mechanism to pause token transfers or critical operations. This could lead to irreversible loss of funds or protocol instability before a fix can be deployed.
FixImplement OpenZeppelin's `PausableUpgradeable` module to allow the owner (or a designated role) to temporarily halt critical operations in an emergency. This provides a crucial safety net for rapid response to unforeseen issues.
StatusUnresolved
Info

Suboptimal Storage Packing for `PackedPoolState`

I-01The `PackedPoolState` struct contains members of various sizes (`uint8`, `uint16`, `bool`, `uint96`, `uint64`, `uint48`). While Solidity attempts to pack variables to minimize storage slots, the current ordering may not be optimal. Reordering the members from largest to smallest (or grouping smaller types efficiently) could potentially reduce the number of storage slots used, leading to minor gas savings on read/write operations.
IssueThe `PackedPoolState` struct contains members of various sizes (`uint8`, `uint16`, `bool`, `uint96`, `uint64`, `uint48`). While Solidity attempts to pack variables to minimize storage slots, the current ordering may not be optimal. Reordering the members from largest to smallest (or grouping smaller types efficiently) could potentially reduce the number of storage slots used, leading to minor gas savings on read/write operations.
FixConsider reordering the `PackedPoolState` struct members for optimal storage packing. For example, placing `uint96`, `uint64`, `uint48` first, followed by `uint16`, `uint16`, `uint8`, `bool` could potentially reduce storage slot usage.
StatusUnresolved
Info

`liqExpectedOutputAmount` Variable is Unused

I-02The state variable `liqExpectedOutputAmount` is declared and initialized during the `initialize` function but is not referenced or used anywhere within the provided `FlapTaxTokenV3` contract code. If this variable is intended for use by an external contract (e.g., `taxProcessor`), its purpose should be clearly documented. If not, it represents unnecessary storage consumption.
IssueThe state variable `liqExpectedOutputAmount` is declared and initialized during the `initialize` function but is not referenced or used anywhere within the provided `FlapTaxTokenV3` contract code. If this variable is intended for use by an external contract (e.g., `taxProcessor`), its purpose should be clearly documented. If not, it represents unnecessary storage consumption.
FixEither integrate `liqExpectedOutputAmount` into the contract's logic or remove it to save gas and storage. If it's an external dependency, add comments explaining its intended use.
StatusUnresolved
Info

Correct Use of `_disableInitializers()` in Constructor

I-03The constructor correctly calls `_disableInitializers()`. This is a crucial security practice for upgradeable contracts, preventing the implementation contract from being initialized directly, which could lead to a 'state collision' or 'logic corruption' if the proxy later attempts to initialize it.
IssueThe constructor correctly calls `_disableInitializers()`. This is a crucial security practice for upgradeable contracts, preventing the implementation contract from being initialized directly, which could lead to a 'state collision' or 'logic corruption' if the proxy later attempts to initialize it.
FixNo action required. This is a best practice and correctly implemented.
StatusResolved

Category Ratings

TechnicalLow8/10

The contract implements a complex state machine for managing tax rates and token transfers, leveraging OpenZeppelin's ERC20 and Ownable upgradeable modules. The tax calculation and transfer logic are well-structured (7.2 Code Security). A reentrancy guard is present for the `_liquidateTax` function, which is a strength. However, the reliance on external `taxProcessor` and `dividendContract` introduces a significant trust assumption (7.6 External). Additionally, the `_liquidateTax` function, triggered by transfers to `mainPool`, could be susceptible to front-running (7.2 Code Security).

GovernanceMedium4/10

The contract's economic model revolves around dynamic buy/sell taxes and a liquidation mechanism that processes accumulated tax. The owner has significant control over critical state transitions (`startMigration`, `finalizeMigration`) and sets immutable external dependencies (`taxProcessor`, `dividendContract`) during initialization (7.5 Governance, 7.3 Access Control). This centralization introduces a medium governance risk, as a compromised owner key could manipulate the token's core economic behavior or direct funds to malicious external contracts (7.4 Economic).

UpgradesMedium5/10

The contract is designed as an upgradeable proxy using OpenZeppelin's `Initializable` pattern. The constructor correctly calls `_disableInitializers()` to prevent direct initialization of the implementation contract, which is a crucial security measure for UUPS proxies (7.7 Upgrades). The use of `__ERC20_init`, `__ERC20Permit_init`, and `__Ownable_init` ensures proper initialization of inherited upgradeable components. The overall upgradeability pattern appears sound.

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

88.0% in top 10
5.8% in wallets82.2% in contracts
Effective Concentration38.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

$7.8K

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
0x14fc…de65

What Raised This Score

8 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 30% (88.0% total → 38.6% effective; 5.8% in EOAs, 82.2% in contracts — moderate)
  • Liquidity < $10k ($7,828 across 1 pairs — easily drained)
  • Token age < 7 days (early, volatile)
  • 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
Ice Open Network (ION)High RiskUnifAI (UAI)Medium RiskAIW3Medium Risk吉祥马Medium RiskARAI Token (AA)Medium RiskBSquared Token (B2)High Risk

Would You Like a More Detailed Audit of CSI888?

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

Get Detailed Audit