Quantum Audit Logo
Launch App

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

Is Stupid Kid 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 4, 2026 · 1 audit on recordNew Launch · 3d old
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance5/10Upgrades4/10Checks passed4 of 7Findings1 High · 2 Medium · 1 Low · 2 Info6
SummaryAI Copilot

The FlapTaxTokenV3 contract is an upgradeable ERC20 token designed with a dynamic tax mechanism, multiple pool states, and anti-farmer features.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Volume/Liquidity > 10×
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 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)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Volume/Liquidity > 10× (12.8× — possible wash trading)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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 (3d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax1% / 1%

Holders

as of audit · Sep 4, 2026
19.8%Contracts9.3%Wallets70.8%Everyone else
19.8%Contracts9.3%70.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
29.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking19.8%
  • Walletsanonymous holders, free to sell9.3%
  • Everyone elsethe rest of the supply70.8%
Effective concentrationwhat the score reads17.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$53.2K

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$53.2KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x14e5…be4a

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

Security Findings

1 High2 Medium1 Low2 Info
High

Excessive Centralization of Control by Owner

The contract grants extensive control to the owner over critical parameters and state transitions. Functions such as setTaxProcessor, setDividendContract, setPoolState, startMigration, finalizeMigration, and setLiquidationThreshold are all protected by the onlyOwner modifier. A compromised or malicious owner could manipulate tax rates, block transfers, change the operational state of the token, or redirect accumulated tax funds to a malicious address, leading to significant financial loss or protocol disruption. This introduces a single point of failure for the protocol (7.3 Access Control, 7.5 Governance).H-01

Issue

The contract grants extensive control to the owner over critical parameters and state transitions. Functions such as setTaxProcessor, setDividendContract, setPoolState, startMigration, finalizeMigration, and setLiquidationThreshold are all protected by the onlyOwner modifier. A compromised or malicious owner could manipulate tax rates, block transfers, change the operational state of the token, or redirect accumulated tax funds to a malicious address, leading to significant financial loss or protocol disruption. This introduces a single point of failure for the protocol (7.3 Access Control, 7.5 Governance).

Fix

Implement a multi-signature wallet for ownership or introduce a time-lock mechanism for critical administrative actions. This would require multiple approvals or a delay period before changes take effect, reducing the risk of a single point of compromise. Consider decentralizing some parameters or introducing a governance mechanism for key decisions.

Status

Unresolved

Medium

Reentrancy Risk in _liquidateTax Function

The _liquidateTax function, which is called on every _transfer, makes external calls to ITaxProcessor(taxProcessor).processTax() or IDividend(dividendContract).processDividend(). While the balanceOf(address(this)) check occurs before the external call, the poolState variable is updated *after* the external call if a state transition is triggered by block.timestamp. A malicious taxProcessor or dividendContract could potentially reenter the FlapTaxTokenV3 contract, triggering _transfer and subsequently _liquidateTax again. This could lead to processTax being called multiple times with the same taxAmount if the tokens haven't been transferred out yet, or operating o…M-01

Issue

The _liquidateTax function, which is called on every _transfer, makes external calls to ITaxProcessor(taxProcessor).processTax() or IDividend(dividendContract).processDividend(). While the balanceOf(address(this)) check occurs before the external call, the poolState variable is updated *after* the external call if a state transition is triggered by block.timestamp. A malicious taxProcessor or dividendContract could potentially reenter the FlapTaxTokenV3 contract, triggering _transfer and subsequently _liquidateTax again. This could lead to processTax being called multiple times with the same taxAmount if the tokens haven't been transferred out yet, or operating o…

Fix

Implement a reentrancy guard (e.g., OpenZeppelin's ReentrancyGuard) on the _liquidateTax function or ensure that all state changes related to the tax balance and pool state are completed *before* any external calls are made. Follow the 'Checks-Effects-Interactions' pattern strictly.

Status

Unresolved

Medium

Potential for High Gas Costs on Transfers

The _liquidateTax function is invoked on every _transfer operation. This function includes logic for checking block.timestamp for state transitions and potentially making external calls to ITaxProcessor or IDividend contracts. If these external contracts perform complex operations, or if the conditions for processing tax/dividends are frequently met, the gas cost for standard token transfers could become unexpectedly high. This might negatively impact user experience and could lead to transaction failures during periods of high network congestion (7.8 Operations).M-02

Issue

The _liquidateTax function is invoked on every _transfer operation. This function includes logic for checking block.timestamp for state transitions and potentially making external calls to ITaxProcessor or IDividend contracts. If these external contracts perform complex operations, or if the conditions for processing tax/dividends are frequently met, the gas cost for standard token transfers could become unexpectedly high. This might negatively impact user experience and could lead to transaction failures during periods of high network congestion (7.8 Operations).

Fix

Evaluate the gas consumption of _liquidateTax and its external calls under various scenarios. Consider optimizing the logic within _liquidateTax or the external contracts to minimize gas usage. Alternatively, explore alternative mechanisms for triggering tax processing (e.g., a dedicated processTax function that users or a bot can call, rather than on every transfer) to decouple it from basic token transfers.

Status

Unresolved

Low

Fixed liqExpectedOutputAmount for Tax Processing

The liqExpectedOutputAmount parameter, used in the ITaxProcessor(taxProcessor).processTax(taxAmount, liqExpectedOutputAmount) call, is set as an immutable value during initialization. This fixed value might not always be optimal or realistic for the actual output of the tax processing, especially in volatile market conditions or if the taxProcessor's logic changes over time. This could lead to slippage or inefficient tax processing if the ITaxProcessor relies heavily on this parameter for its operations (7.4 Economic).L-01

Issue

The liqExpectedOutputAmount parameter, used in the ITaxProcessor(taxProcessor).processTax(taxAmount, liqExpectedOutputAmount) call, is set as an immutable value during initialization. This fixed value might not always be optimal or realistic for the actual output of the tax processing, especially in volatile market conditions or if the taxProcessor's logic changes over time. This could lead to slippage or inefficient tax processing if the ITaxProcessor relies heavily on this parameter for its operations (7.4 Economic).

Fix

Consider making liqExpectedOutputAmount configurable by the owner (with appropriate access control and perhaps a time-lock) or allowing the ITaxProcessor to determine its own expected output based on current market conditions. This would provide greater flexibility and potentially improve the efficiency of the tax processing mechanism.

Status

Unresolved

Info

Heavy Reliance on External Contracts

The FlapTaxTokenV3 contract heavily relies on external contracts, specifically ITaxProcessor and IDividend, for critical tax and dividend processing. The security, correctness, and availability of these external contracts are paramount to the overall functionality and security of the token. Any vulnerabilities, malicious behavior, or operational failures in these external contracts could directly impact the FlapTaxTokenV3 token and its users (7.6 External).I-01

Issue

The FlapTaxTokenV3 contract heavily relies on external contracts, specifically ITaxProcessor and IDividend, for critical tax and dividend processing. The security, correctness, and availability of these external contracts are paramount to the overall functionality and security of the token. Any vulnerabilities, malicious behavior, or operational failures in these external contracts could directly impact the FlapTaxTokenV3 token and its users (7.6 External).

Fix

Ensure that the ITaxProcessor and IDividend contracts undergo rigorous security audits and are maintained to the highest security standards. Implement robust monitoring for these external contracts. Consider adding mechanisms to pause or change these external contract addresses in case of an emergency, protected by multi-signature or time-lock.

Status

Unresolved

Info

Dividend Processing in TaxFree State

In the _liquidateTax function, if the PoolState transitions to TaxFree, any accumulated taxAmount (balance of address(this)) is sent to IDividend(dividendContract).processDividend(). While this is likely intended as a cleanup mechanism for previously collected taxes, the term 'TaxFree' might be misleading to users if funds are still being processed as 'dividends' from past taxes. This could lead to a slight misunderstanding of the contract's current operational state (7.4 Economic).I-02

Issue

In the _liquidateTax function, if the PoolState transitions to TaxFree, any accumulated taxAmount (balance of address(this)) is sent to IDividend(dividendContract).processDividend(). While this is likely intended as a cleanup mechanism for previously collected taxes, the term 'TaxFree' might be misleading to users if funds are still being processed as 'dividends' from past taxes. This could lead to a slight misunderstanding of the contract's current operational state (7.4 Economic).

Fix

Clarify the documentation or comments within the code to explicitly state that 'TaxFree' refers to new transfers not incurring tax, but previously collected taxes may still be processed as dividends. This improves transparency and user understanding of the contract's behavior.

Status

Unresolved

Analysis

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

The FlapTaxTokenV3 contract is an upgradeable ERC20 token designed with a dynamic tax mechanism, multiple pool states, and anti-farmer features. It utilizes OpenZeppelin's upgradeable contracts for security and maintainability. The contract implements a system where transfers can incur taxes, which are then collected and processed by external ITaxProcessor or IDividend contracts. While the architecture is well-structured, significant centralization of control by the owner and potential reentrancy vectors in the tax liquidation mechanism introduce notable risks. Gas efficiency for transfers could also be a concern due to the _liquidateTax call on every transfer.

Technical8/10Low risk

The contract demonstrates good technical practices, leveraging OpenZeppelin's upgradeable standards for ERC20 functionality and proxy patterns (7.1 Architecture). The use of PackedPoolState for storage optimization is a positive aspect for gas efficiency. However, a potential reentrancy vulnerability exists in the _liquidateTax function due to external calls before state updates (7.2 Code Security). Additionally, the execution of _liquidateTax on every transfer could lead to increased gas costs for users (7.8 Operations).

Governance5/10Medium risk

The contract's economic model includes dynamic tax rates and pool states, managed through owner-controlled functions, which allows for flexibility in adapting to market conditions (7.4 Economic). The anti-farmer duration and migration states are well-defined. However, the contract exhibits a high degree of centralization, with the owner having extensive control over critical parameters, state transitions, and external contract addresses (7.3 Access Control, 7.5 Governance). This central authority poses a significant risk if the owner's key is compromised or acts maliciously. The fixed liqExpectedOutputAmount for tax processing might also lead to inefficiencies.

Upgrades4/10Medium risk

The contract correctly implements the upgradeable pattern using OpenZeppelin's Initializable and ERC20Upgradeable contracts (7.7 Upgrades). The constructor disables initializers, and the initialize function uses the initializer modifier, following best practices for upgradeable contracts. This setup allows for future upgrades to fix bugs or add features without deploying a new token.

Final RecommendationWhat to do about this score

It is highly recommended to implement robust multi-signature or time-locked mechanisms for critical owner-controlled functions to mitigate the risks associated with centralized control.

Thoroughly review and secure the external ITaxProcessor and IDividend contracts, as their security directly impacts the token. Consider implementing a reentrancy guard on the _liquidateTax function or re-architecting the external calls to prevent potential reentrancy attacks. Evaluate the gas costs associated with _liquidateTax under various scenarios to ensure user experience is not negatively impacted.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age3d
Contract0x4062…7777
Deployer0xbbde…2b92
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
Stupid Kid 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, 202651Medium
  2. Sep 3, 202628Low

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

Related Audits

6 more on the recordAll audits
Baby AnsemBABYANSEM · BNB Chain51MediumEVAABNB Chain51MediumBubblemapsBMT · BNB Chain51MediumPIZZABNB Chain51MediumDGrid AIDGAI · BNB Chain51MediumCycle Network TokenCYC · BNB Chain51Medium

Would You Like a More Detailed Audit of Stupid Kid?

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