Quantum Audit Logo
Launch App

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

Is 金蟾 a Scam?

JINBNB 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 · 16h old
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance2/10Upgrades4/10Checks passed3 of 5Findings2 High · 2 Medium · 1 Info5
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and state transitions.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • Token age < 24h
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
Exact factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 20% (51.4% total → 27.5% effective; 11.5% in EOAs, 39.9% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($17,375 across 1 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 24h (brand new — bot activity, unproven)
  • 2 High finding(s) from audit
  • 2 Medium 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 (16h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
39.9%Contracts11.5%Wallets48.6%Everyone else
39.9%Contracts11.5%48.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
51.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking39.9%
  • Walletsanonymous holders, free to sell11.5%
  • Everyone elsethe rest of the supply48.6%
Effective concentrationwhat the score reads27.5%
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$17.4K

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$17.4KShare 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

2 High2 Medium1 Info
High

External Contract Dependency Risk

The _liquidateTax function makes an external call to taxProcessor.processTax(taxAmount). The security and correctness of the ITaxProcessor contract are paramount. If taxProcessor is malicious, buggy, or itself vulnerable (e.g., to reentrancy or unauthorized access), it could lead to the loss of all accumulated tax funds held by FlapTaxTokenV3. While a reentrancy guard (notLiquidating) is present for _liquidateTax, it does not mitigate risks stemming from the taxProcessor's own logic or its interactions with other contracts. (7.6 External)H-01

Issue

The _liquidateTax function makes an external call to taxProcessor.processTax(taxAmount). The security and correctness of the ITaxProcessor contract are paramount. If taxProcessor is malicious, buggy, or itself vulnerable (e.g., to reentrancy or unauthorized access), it could lead to the loss of all accumulated tax funds held by FlapTaxTokenV3. While a reentrancy guard (notLiquidating) is present for _liquidateTax, it does not mitigate risks stemming from the taxProcessor's own logic or its interactions with other contracts. (7.6 External)

Fix

Thoroughly audit the ITaxProcessor contract and any other external contracts it interacts with. Ensure robust access controls and security measures are in place for taxProcessor. Consider implementing a timelock for changing critical external contract addresses if they were mutable (though in this case, taxProcessor is immutable after initialization).

Status

Unresolved

High

Centralized Control over Token State Transitions

The startMigration and finalizeMigration functions, which control significant transitions in the token's PoolState (e.g., from BondingCurve to Migrating to TaxEnforcedAntiFarmer), are restricted to onlyOwner. This grants the owner considerable power to alter the token's economic behavior, including tax enforcement and anti-farmer mechanisms, without community input or a timelock. Additionally, the initialize function mints the entire maxSupply to the deployer, concentrating initial token supply with the owner. (7.3 Access Control, 7.5 Governance)H-02

Issue

The startMigration and finalizeMigration functions, which control significant transitions in the token's PoolState (e.g., from BondingCurve to Migrating to TaxEnforcedAntiFarmer), are restricted to onlyOwner. This grants the owner considerable power to alter the token's economic behavior, including tax enforcement and anti-farmer mechanisms, without community input or a timelock. Additionally, the initialize function mints the entire maxSupply to the deployer, concentrating initial token supply with the owner. (7.3 Access Control, 7.5 Governance)

Fix

Consider decentralizing control over critical state transitions through a multi-signature wallet or a decentralized autonomous organization (DAO). Implement a timelock for such sensitive operations to provide users with a window to react. Document the owner's capabilities clearly to manage user expectations.

Status

Unresolved

Medium

Immutable Liquidation Threshold

The liquidationThreshold within the PackedPoolState struct is initialized to START_LIQ_THRESHOLD and remains constant throughout the contract's lifecycle. This fixed threshold dictates when accumulated tax (balanceOf(address(this))) is processed by the taxProcessor. If market conditions or the protocol's needs change, this immutable threshold might become suboptimal, leading to inefficient tax processing (e.g., processing too frequently with small amounts or accumulating excessively large amounts before processing). The initialLiquidationThreshold variable is also set but unused. (7.4 Economic)M-01

Issue

The liquidationThreshold within the PackedPoolState struct is initialized to START_LIQ_THRESHOLD and remains constant throughout the contract's lifecycle. This fixed threshold dictates when accumulated tax (balanceOf(address(this))) is processed by the taxProcessor. If market conditions or the protocol's needs change, this immutable threshold might become suboptimal, leading to inefficient tax processing (e.g., processing too frequently with small amounts or accumulating excessively large amounts before processing). The initialLiquidationThreshold variable is also set but unused. (7.4 Economic)

Fix

Consider making the liquidationThreshold configurable by a trusted entity (e.g., owner, multisig, or governance) to allow for adjustments based on evolving protocol requirements or market dynamics. If it's intended to be immutable, ensure this design choice is well-justified and documented. Remove the unused initialLiquidationThreshold variable to improve code clarity.

Status

Unresolved

Medium

Reliance on block.timestamp for Critical State Transitions

The _liquidateTax function uses block.timestamp to determine if taxExpirationTime or antiFarmerExpirationTime have passed, triggering changes in the PoolState (e.g., to TaxFree or TaxEnforced). While block.timestamp is suitable for relative time checks, miners can manipulate it within a small window (up to 900 seconds on Ethereum, though BSC might differ). This could potentially allow a miner or a sophisticated attacker to slightly influence the timing of these state transitions to their economic advantage, for example, by delaying a block to avoid a tax or accelerating it to trigger a specific state. (7.2 Code Security, 7.4 Economic)M-02

Issue

The _liquidateTax function uses block.timestamp to determine if taxExpirationTime or antiFarmerExpirationTime have passed, triggering changes in the PoolState (e.g., to TaxFree or TaxEnforced). While block.timestamp is suitable for relative time checks, miners can manipulate it within a small window (up to 900 seconds on Ethereum, though BSC might differ). This could potentially allow a miner or a sophisticated attacker to slightly influence the timing of these state transitions to their economic advantage, for example, by delaying a block to avoid a tax or accelerating it to trigger a specific state. (7.2 Code Security, 7.4 Economic)

Fix

For highly sensitive time-dependent logic where even minor manipulation could have significant economic impact, consider using an oracle-based timestamp (e.g., Chainlink Keepers or similar decentralized time services) if precise, unmanipulable timing is critical. Alternatively, ensure the economic impact of minor block.timestamp manipulation is acceptable for the protocol.

Status

Unresolved

Info

Unused State Variable initialLiquidationThreshold

The state variable initialLiquidationThreshold is set during the initialize function but is never subsequently read or used anywhere else in the contract. This indicates dead code, which can increase contract size, deployment costs, and potentially lead to confusion for future developers. (7.2 Code Security)I-01

Issue

The state variable initialLiquidationThreshold is set during the initialize function but is never subsequently read or used anywhere else in the contract. This indicates dead code, which can increase contract size, deployment costs, and potentially lead to confusion for future developers. (7.2 Code Security)

Fix

Remove the initialLiquidationThreshold variable if it serves no purpose, or integrate it into the contract's logic if it was intended to be used.

Status

Unresolved

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 state transitions. It utilizes OpenZeppelin's upgradeable contracts for security and follows a structured design with a packed state variable. Key findings include high centralization risk due to owner privileges over state transitions and initial token supply, and significant dependency on external contracts for tax processing. Medium risks relate to immutable liquidation thresholds and reliance on block.timestamp for critical state changes. Overall, the contract demonstrates good use of standard libraries but requires careful management of external dependencies and owner responsibilities.

Technical6/10Medium risk

The contract leverages OpenZeppelin's upgradeable contracts, providing a solid foundation for ERC20 functionality and upgradeability (7.1 Architecture). The use of a PackedPoolState struct is an efficient way to store multiple state variables, optimizing gas costs. However, the contract has a high dependency on external contracts like ITaxProcessor for core tax liquidation logic, introducing external risk (7.6 External). Additionally, critical state transitions rely on block.timestamp, which can be subject to minor miner manipulation (7.2 Code Security).

Governance2/10High risk

The contract includes a check ensuring taxDuration is greater than or equal to antiFarmerDuration, which is a positive economic constraint. However, the owner has significant control over critical PoolState transitions via startMigration and finalizeMigration functions, which directly impact the token's economic model (7.5 Governance). The initial minting of all maxSupply to the deployer also centralizes token distribution. Furthermore, the liquidationThreshold for tax processing is immutable, which may not adapt to future market conditions (7.4 Economic).

Upgrades4/10Medium risk

The contract is designed as an upgradeable proxy using OpenZeppelin's Initializable pattern. The _disableInitializers() call in the constructor correctly prevents re-initialization of the implementation contract. Standard initializer functions (__ERC20_init, __ERC20Permit_init, __Ownable_init) are used, ensuring proper setup during proxy deployment. This approach aligns with best practices for upgradeable contracts (7.7 Upgrades).

Final RecommendationWhat to do about this score

It is recommended to thoroughly audit all external contracts, especially ITaxProcessor, to ensure their security and intended behavior.

Consider implementing a multi-signature wallet or a timelock for critical owner-controlled state transitions to enhance decentralization and provide users with a reaction window. Evaluate the immutability of the liquidationThreshold and block.timestamp reliance for state changes, and consider making them configurable or using more robust time sources if the economic impact is significant. Finally, address the unused state variable to improve code clarity.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age16h
Contract0x49f5…7777
Deployer0x7af4…090a
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
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 4, 202675High
  2. Aug 14, 202648Medium

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

Related Audits

6 more on the recordAll audits
bStocks Never SleepBSTOCKS · BNB Chain75HighWorldMobileTokenWMTX · BNB Chain75HighBaby BFTBBFT · BNB Chain75HighZypher TokenPOP · BNB Chain76HighSOLANASOL · BNB Chain74HighSTBL_Token - STBL Governance TokenSTBL · BNB Chain76High

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