Quantum Audit Logo

Is 金蟾 a Scam?

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

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

金蟾 JIN
0x49f5…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 16h old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

2 High2 Medium1 Informational
! 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.
Volume 24h
$9.5K
Liquidity
$17.4K
Price
$0.00002798
Token Age
16h
Top 10 Holders
51.4%

Security Findings

2 High2 Med1 Info
High

External Contract Dependency Risk

H-01The `_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)
IssueThe `_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)
FixThoroughly 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).
StatusUnresolved
High

Centralized Control over Token State Transitions

H-02The `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)
IssueThe `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)
FixConsider 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.
StatusUnresolved
Medium

Immutable Liquidation Threshold

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

Reliance on `block.timestamp` for Critical State Transitions

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

Unused State Variable `initialLiquidationThreshold`

I-01The 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)
IssueThe 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)
FixRemove the `initialLiquidationThreshold` variable if it serves no purpose, or integrate it into the contract's logic if it was intended to be used.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh2/10

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

UpgradesMedium4/10

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

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

51.4% in top 10
11.5% in wallets39.9% in contracts
Effective Concentration27.5%

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

$17.4K

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
0x7af4…090a
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)
  • 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

Related Audits

6 more on the record
bStocks Never Sleep (BSTOCKS)Critical RiskZypher Token (POP)Critical RiskSOLANA (SOL)Critical RiskSTBL_Token - STBL Governance Token (STBL)Critical RiskTartSwap (TART)Critical RiskSpaceX (SPCXB)Critical Risk

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