Quantum Audit Logo
Launch App

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

Is 孙小圣 a Scam?

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 6, 2026 · 1 audit on recordNew Launch · 1d old
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance5/10Upgrades8/10Checks passed6 of 7Findings1 Critical · 1 High · 1 Medium · 2 Low · 1 Info6
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and a state-based lifecycle.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity < $50k
  • Token age < 7 days
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (53.6% total → 39.2% effective; 29.6% in EOAs, 24.0% in contracts — moderate)
  • Liquidity < $50k ($47,928 across 2 pairs — thin market)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 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 (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 66 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax3% / 3%

Holders

as of audit · Sep 6, 2026
24.0%Contracts29.6%Wallets46.4%Everyone else
24.0%Contracts29.6%Wallets46.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
53.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking24.0%
  • Walletsanonymous holders, free to sell29.6%
  • Everyone elsethe rest of the supply46.4%
Effective concentrationwhat the score reads39.2%
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 6, 2026

Liquidity

as of audit · Sep 6$47.9K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$47.8KShare of depth99.7%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 Critical1 High1 Medium2 Low1 Info
Critical

Incomplete Code Provided for Audit

The provided source code for the _liquidateTax function is truncated, specifically the condition taxAmount >= currentPoolState.liqu.... This function is critical as it handles state transitions, tax processing, and potentially external calls (e.g., to taxProcessor or dividendContract). Without the complete code, it is impossible to fully assess the security and economic implications of the tax liquidation mechanism, including potential reentrancy, denial-of-service, or incorrect handling of accumulated funds. (7.2 Code Security, 7.4 Economic)C-01

Issue

The provided source code for the _liquidateTax function is truncated, specifically the condition taxAmount >= currentPoolState.liqu.... This function is critical as it handles state transitions, tax processing, and potentially external calls (e.g., to taxProcessor or dividendContract). Without the complete code, it is impossible to fully assess the security and economic implications of the tax liquidation mechanism, including potential reentrancy, denial-of-service, or incorrect handling of accumulated funds. (7.2 Code Security, 7.4 Economic)

Fix

Provide the complete and verified source code for the _liquidateTax function and any other truncated sections to allow for a comprehensive security review.

Status

Unresolved

High

Centralized Control by Owner

The contract relies heavily on OwnableUpgradeable for critical operations. The owner has exclusive control over initiating and finalizing migration states (startMigration, finalizeMigration), which directly impacts the token's tax mechanisms and transfer rules. The owner also minted the entire maxSupply during initialization. This high degree of centralization introduces a single point of failure and trust, as a compromised owner key could lead to significant economic manipulation or a rug pull scenario. (7.3 Access Control, 7.5 Governance)H-01

Issue

The contract relies heavily on OwnableUpgradeable for critical operations. The owner has exclusive control over initiating and finalizing migration states (startMigration, finalizeMigration), which directly impacts the token's tax mechanisms and transfer rules. The owner also minted the entire maxSupply during initialization. This high degree of centralization introduces a single point of failure and trust, as a compromised owner key could lead to significant economic manipulation or a rug pull scenario. (7.3 Access Control, 7.5 Governance)

Fix

Consider implementing a multi-signature wallet for ownership or transitioning to a decentralized governance model (e.g., DAO) for critical functions to reduce the risk associated with a single point of control.

Status

Unresolved

Medium

Unused or Truncated External Dependencies and Variables

Several imported interfaces (ITaxProcessor, IDividend) and state variables (liqExpectedOutputAmount, initialLiquidationThreshold, metaURI, dividendContract, taxProcessor) are initialized but not used within the provided code snippet. While some usage might be in the truncated _liquidateTax function, their absence in the visible logic suggests either dead code, incomplete implementation, or critical functionality being hidden. This makes it difficult to understand the full system's behavior and potential external interaction risks. (7.1 Architecture, 7.6 External)M-01

Issue

Several imported interfaces (ITaxProcessor, IDividend) and state variables (liqExpectedOutputAmount, initialLiquidationThreshold, metaURI, dividendContract, taxProcessor) are initialized but not used within the provided code snippet. While some usage might be in the truncated _liquidateTax function, their absence in the visible logic suggests either dead code, incomplete implementation, or critical functionality being hidden. This makes it difficult to understand the full system's behavior and potential external interaction risks. (7.1 Architecture, 7.6 External)

Fix

Ensure all declared variables and imported interfaces are actively used and their interactions are fully implemented and visible. If they are intended for future use, document their purpose clearly. If they are dead code, remove them to improve clarity and reduce attack surface.

Status

Unresolved

Low

Potential Truncation Risk for antiFarmerExpirationTime

The antiFarmerExpirationTime variable is declared as uint48. While uint48 provides a large enough range for typical block.timestamp values and antiFarmerDuration (up to approximately 2.78 million years), there is a theoretical risk of truncation if block.timestamp + antiFarmerDuration were to exceed 2^48 - 1. Although highly improbable in practical scenarios, using a larger type like uint64 for time-related variables is generally safer and more robust against extreme or long-term values. (7.2 Code Security)L-01

Issue

The antiFarmerExpirationTime variable is declared as uint48. While uint48 provides a large enough range for typical block.timestamp values and antiFarmerDuration (up to approximately 2.78 million years), there is a theoretical risk of truncation if block.timestamp + antiFarmerDuration were to exceed 2^48 - 1. Although highly improbable in practical scenarios, using a larger type like uint64 for time-related variables is generally safer and more robust against extreme or long-term values. (7.2 Code Security)

Fix

Consider using uint64 for antiFarmerExpirationTime to align with taxExpirationTime and eliminate any theoretical truncation risk, even if practically negligible.

Status

Unresolved

Low

Ambiguity in Pool Tax Application Logic

The _getTaxWithPoolState function applies tax logic differently based on the PoolState. In PoolState.TaxEnforcedAntiFarmer, it checks pools[from] or pools[to], applying tax if either address is a configured pool. In PoolState.TaxEnforced, it specifically checks from == mainPool or to == mainPool. This distinction, while potentially intentional, could lead to confusion or unintended tax application if the mainPool is not the only address intended to be taxed in the TaxEnforced state, or if the pools mapping is not managed carefully. (7.1 Architecture, 7.4 Economic)L-02

Issue

The _getTaxWithPoolState function applies tax logic differently based on the PoolState. In PoolState.TaxEnforcedAntiFarmer, it checks pools[from] or pools[to], applying tax if either address is a configured pool. In PoolState.TaxEnforced, it specifically checks from == mainPool or to == mainPool. This distinction, while potentially intentional, could lead to confusion or unintended tax application if the mainPool is not the only address intended to be taxed in the TaxEnforced state, or if the pools mapping is not managed carefully. (7.1 Architecture, 7.4 Economic)

Fix

Clearly document the intended behavior and rationale behind the differing tax application logic for PoolState.TaxEnforcedAntiFarmer and PoolState.TaxEnforced. Ensure that the pools mapping and mainPool variable are managed consistently with these rules.

Status

Unresolved

Info

Packed Storage for PackedPoolState

The PackedPoolState struct uses packed storage (uint8, uint16, uint16, bool, uint96, uint64, uint48) to optimize gas costs by fitting multiple variables into a single storage slot. While efficient, this design requires careful consideration for future upgrades. Any change in the order or size of these variables in a subsequent implementation could lead to storage collisions and data corruption if not handled meticulously, potentially breaking the contract's state. (7.7 Upgrades)I-01

Issue

The PackedPoolState struct uses packed storage (uint8, uint16, uint16, bool, uint96, uint64, uint48) to optimize gas costs by fitting multiple variables into a single storage slot. While efficient, this design requires careful consideration for future upgrades. Any change in the order or size of these variables in a subsequent implementation could lead to storage collisions and data corruption if not handled meticulously, potentially breaking the contract's state. (7.7 Upgrades)

Fix

When upgrading the contract, ensure that the PackedPoolState struct's layout remains identical or that any changes are managed with extreme care to prevent storage collisions. Thorough testing of upgrade scenarios is crucial.

Status

Unresolved

Analysis

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

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and a state-based lifecycle. It leverages OpenZeppelin's upgradeable patterns for robust architecture. However, a critical portion of the _liquidateTax function was truncated in the provided source, preventing a full security assessment of the core tax processing and fund management. This, combined with high centralization, contributes to a Medium overall risk level.

Technical7/10Low risk

The contract implements an upgradeable ERC20 token with a complex state machine for tax enforcement and migration. It leverages OpenZeppelin's battle-tested upgradeable contracts, ensuring a solid foundation (7.1 Architecture). The tax calculation logic (_getTaxWithPoolState) is well-structured, preventing common arithmetic errors. However, a critical portion of the _liquidateTax function is truncated, preventing a full security assessment of the core tax processing and fund management (7.2 Code Security). Additionally, some initialized variables and imported interfaces appear unused in the visible code, suggesting potential incompleteness or dead code.

Governance5/10Medium risk

The economic model incorporates dynamic buy/sell taxes and an anti-farmer mechanism, managed through distinct pool states. The tax rates are applied using a standard basis point calculation, mitigating precision issues (7.4 Economic). However, the contract exhibits a high degree of centralization, with the OwnableUpgradeable role controlling critical state transitions and holding the entire token supply initially (7.5 Governance). This introduces significant trust assumptions and a single point of failure. The full economic implications of tax liquidation cannot be assessed due to truncated code.

Upgrades8/10Low risk

The contract is designed as an upgradeable proxy using OpenZeppelin's Initializable pattern, correctly disabling initializers in the constructor and using the initializer modifier (7.7 Upgrades). This allows for future enhancements and bug fixes. The PackedPoolState struct utilizes packed storage for gas efficiency, which is a positive. However, this packing requires meticulous attention during future upgrades to prevent storage collisions and data corruption if the struct's layout is altered.

Final RecommendationWhat to do about this score

Prioritize providing the complete and verified source code for all contract functions, especially _liquidateTax, to enable a comprehensive security audit.

Address the high centralization by considering a multi-signature wallet for the owner role or exploring a transition to a decentralized governance model for critical administrative functions. Ensure all declared variables and imported interfaces are actively utilized within the contract logic, or remove any unused components to enhance clarity and reduce the attack surface.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age1d
Contract0xbb87…7777
Deployer0x1afc…2b84
Badge for your website
孙小圣 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 6, 202637Medium

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

Related Audits

6 more on the recordAll audits
AlturaALU · BNB Chain37Medium4catBNB Chain37MediumBigShortSHORT · BNB Chain37MediumMame InuMAME · BNB Chain38MediumOLAXBTAIO · BNB Chain38MediumNon-Playable CoinNPC · BNB Chain36Medium

Would You Like a More Detailed Audit of 孙小圣?

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