Quantum Audit Logo
Launch App

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

Is CSI888 a Scam?

CSIBNB 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 · 2d old
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance4/10Upgrades5/10Checks passed4 of 5Findings1 High · 2 Medium · 1 Low · 3 Info7
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and a multi-state pool system.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 30%
  • Liquidity < $10k
  • Token age < 7 days
  • 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 > 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

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.

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
82.2%Contracts5.8%Wallets12.0%Everyone else
82.2%Contracts5.8%12.0%
ContractsWalletsEveryone elseBubble area = share of supply
88.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking82.2%
  • Walletsanonymous holders, free to sell5.8%
  • Everyone elsethe rest of the supply12.0%
Effective concentrationwhat the score reads38.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$7.8K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$7.8KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 High2 Medium1 Low3 Info
High

External Call Trust and Potential for Malicious Tax Processor

The _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.H-01

Issue

The _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.

Fix

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

Status

Unresolved

Medium

Centralization Risk via Owner Privileges

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

Issue

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

Fix

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

Status

Unresolved

Medium

Potential for Front-running or Sandwich Attacks on Liquidation

The _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.M-02

Issue

The _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.

Fix

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

Status

Unresolved

Low

Lack of Emergency Pause Mechanism

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Suboptimal Storage Packing for PackedPoolState

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

Issue

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

Fix

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

Status

Unresolved

Info

liqExpectedOutputAmount Variable is Unused

The 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.I-02

Issue

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

Fix

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

Status

Unresolved

Info

Correct Use of _disableInitializers() in Constructor

The 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.I-03

Issue

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

Fix

No action required. This is a best practice and correctly implemented.

Status

Resolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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

Governance4/10Medium risk

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

Upgrades5/10Medium risk

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.

Final RecommendationWhat to do about this score

It is highly recommended to conduct a thorough audit of the external taxProcessor and dividendContract to ensure their security and trustworthiness, as they represent critical dependencies.

Consider implementing a timelock or a more decentralized governance mechanism for critical owner-controlled functions and the ability to update external contract addresses. Additionally, evaluate the trigger conditions for _liquidateTax to mitigate potential front-running risks and consider adding a pause mechanism for emergency situations.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age2d
Contract0x2f31…7777
Deployer0x14fc…de65
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
CSI888 security record badge

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
  1. Sep 4, 202646Medium
  2. Aug 12, 202618Low

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

Related Audits

6 more on the recordAll audits
RadiantRDNT · BNB Chain46MediumIce Open NetworkION · BNB Chain47MediumUnifAIUAI · BNB Chain45MediumAIW3BNB Chain45MediumPaimon Polymarket SPV TokenPPOLY · BNB Chain45MediumLibraBNB Chain45Medium

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 Is this your token? Publish your own audit on this page