Quantum Audit Logo

Is Stupid Kid a Scam?

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

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

Stupid Kid 傻孩子
0x4062…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High2 Medium1 Low2 Informational
! 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.
Volume 24h
$683.8K
Liquidity
$53.2K
Price
$0.0002357
Token Age
3d
Top 10 Holders
29.2%

Security Findings

1 High2 Med1 Low2 Info
High

Excessive Centralization of Control by Owner

H-01The 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).
IssueThe 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).
FixImplement 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.
StatusUnresolved
Medium

Reentrancy Risk in `_liquidateTax` Function

M-01The `_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…
IssueThe `_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…
FixImplement 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.
StatusUnresolved
Medium

Potential for High Gas Costs on Transfers

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

Fixed `liqExpectedOutputAmount` for Tax Processing

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

Heavy Reliance on External Contracts

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

Dividend Processing in `TaxFree` State

I-02In 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).
IssueIn 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).
FixClarify 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceMedium5/10

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.

UpgradesMedium4/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

29.2% in top 10
9.3% in wallets19.8% in contracts
Effective Concentration17.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

$53.2K

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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xbbde…2b92
Unlocked LP Held By
0x14e5…be4a

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

What Raised This Score

10 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

Related Audits

6 more on the record
Baby Ansem (BABYANSEM)High RiskEVAAHigh RiskBubblemaps (BMT)High RiskPIZZAHigh RiskDGrid AI (DGAI)High RiskChainOpera AI (COAI)High Risk

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