Quantum Audit Logo

Is 翻身币税助力凉兮翻身 Safe?

On-chain security analysis — is it a scam or legit?

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

翻身币税助力凉兮翻身 翻身币
0x28cd…7777
BNB Chain
Not verifiedThis 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 9d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and pool state transitions. The audit identified a critical reentrancy vulnerability in the tax liquidation logic and a high-severity issue where the contract fails to approve the tax processor, rendering a core function inoperable. Additionally, significant owner privileges and a hardcoded token supply were noted.

1 Critical1 High1 Medium1 Informational
Volume 24h
$510.4K
Liquidity
$61.7K
Price
$0.0002818
Token Age
24d
Top 10 Holders
31.8%

Security Findings

1 Crit1 High1 Med1 Info
Critical

Reentrancy Vulnerability in _liquidateTax

C-01The `_liquidateTax` function, called during `_transfer` operations to the `mainPool`, performs external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distributeDividends`. These external calls occur before the `currentPoolState.notLiquidating` flag is reset (or before the state update that would prevent re-execution). A malicious `taxProcessor` or `dividendContract` could re-enter the `_transfer` function, triggering `_liquidateTax` again while the initial execution is still in progress. This could lead to repeated tax liquidation, draining the contract's collected tax tokens, or other unexpected state manipulations.
IssueThe `_liquidateTax` function, called during `_transfer` operations to the `mainPool`, performs external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).distributeDividends`. These external calls occur before the `currentPoolState.notLiquidating` flag is reset (or before the state update that would prevent re-execution). A malicious `taxProcessor` or `dividendContract` could re-enter the `_transfer` function, triggering `_liquidateTax` again while the initial execution is still in progress. This could lead to repeated tax liquidation, draining the contract's collected tax tokens, or other unexpected state manipulations.
FixImplement a reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard`) on the `_liquidateTax` function. Alternatively, strictly follow the 'checks-effects-interactions' pattern: update all relevant state variables (like `notLiquidating`) *before* making any external calls.
StatusUnresolved
High

Missing ERC20 Approval for Tax Processor

H-01The `_liquidateTax` function collects `FlapTaxTokenV3` tokens as tax into the contract's balance via `_plainTransfer(from, address(this), tax);`. Subsequently, it calls `ITaxProcessor(taxProcessor).processTax(taxAmount, quoteToken, v2Router, liqExpectedOutputAmount)`. For the `taxProcessor` to utilize these collected `FlapTaxTokenV3` tokens (e.g., to swap them), it would typically need to call `transferFrom` on the `FlapTaxTokenV3` contract. However, the `FlapTaxTokenV3` contract never approves the `taxProcessor` to spend its own tokens. This will cause the `processTax` function to fail if it attempts to `transferFrom` the `FlapTaxTokenV3` contract's balance, rendering the tax processing me…
IssueThe `_liquidateTax` function collects `FlapTaxTokenV3` tokens as tax into the contract's balance via `_plainTransfer(from, address(this), tax);`. Subsequently, it calls `ITaxProcessor(taxProcessor).processTax(taxAmount, quoteToken, v2Router, liqExpectedOutputAmount)`. For the `taxProcessor` to utilize these collected `FlapTaxTokenV3` tokens (e.g., to swap them), it would typically need to call `transferFrom` on the `FlapTaxTokenV3` contract. However, the `FlapTaxTokenV3` contract never approves the `taxProcessor` to spend its own tokens. This will cause the `processTax` function to fail if it attempts to `transferFrom` the `FlapTaxTokenV3` contract's balance, rendering the tax processing me…
FixThe `FlapTaxTokenV3` contract must approve the `taxProcessor` to spend its own tokens. This can be done by calling `_approve(address(this), taxProcessor, type(uint256).max)` during initialization or by dynamically approving the exact `taxAmount` before calling `processTax`.
StatusUnresolved
Medium

High Centralization Risk with Owner Privileges

M-01The `OwnableUpgradeable` pattern grants significant control to the contract owner. Specifically, the `startMigration` and `finalizeMigration` functions, which are `onlyOwner`, allow the owner to unilaterally change the `PoolState` of the token. These state changes directly impact the tax rates (`buyTaxRate`, `sellTaxRate`) and transfer restrictions, giving the owner considerable power over the token's economic behavior and user experience (7.3 Access Control, 7.5 Governance).
IssueThe `OwnableUpgradeable` pattern grants significant control to the contract owner. Specifically, the `startMigration` and `finalizeMigration` functions, which are `onlyOwner`, allow the owner to unilaterally change the `PoolState` of the token. These state changes directly impact the tax rates (`buyTaxRate`, `sellTaxRate`) and transfer restrictions, giving the owner considerable power over the token's economic behavior and user experience (7.3 Access Control, 7.5 Governance).
FixConsider implementing a multi-signature wallet for ownership or introducing a timelock mechanism for critical state-changing functions like `startMigration` and `finalizeMigration`. This would provide a delay for users to react to impending changes and reduce the risk of a single point of compromise.
StatusUnresolved
Info

Hardcoded Max Supply

I-01The `maxSupply` variable is declared as a `public constant` with a value of `1e9 ether`. While this clearly defines the token's maximum supply, its constant nature means it cannot be modified in the future, even through upgrades. This design choice might limit flexibility if the project's tokenomics require adjustments to the total supply cap in the long term (7.4 Economic).
IssueThe `maxSupply` variable is declared as a `public constant` with a value of `1e9 ether`. While this clearly defines the token's maximum supply, its constant nature means it cannot be modified in the future, even through upgrades. This design choice might limit flexibility if the project's tokenomics require adjustments to the total supply cap in the long term (7.4 Economic).
FixIf future flexibility for supply adjustments is desired, consider making `maxSupply` a state variable that can be updated by governance or a privileged role, rather than a constant. If the fixed supply is an intentional and permanent design decision, no action is required.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages OpenZeppelin's upgradeable standards (ERC20Upgradeable, OwnableUpgradeable, Initializable), providing a solid foundation for token functionality and upgrade safety (7.1 Architecture). However, a critical reentrancy vulnerability exists in the `_liquidateTax` function due to external calls before state updates (7.2 Code Security). Furthermore, the `_liquidateTax` function fails to provide necessary ERC20 approvals for the `taxProcessor` to handle collected taxes, breaking core functionality (7.2 Code Security).

GovernanceLow8/10

The contract grants the owner significant control over key economic parameters and state transitions (7.5 Governance). Functions like `startMigration` and `finalizeMigration` allow the owner to change the `PoolState`, directly impacting tax rates and transfer restrictions. The `maxSupply` is a hardcoded constant, which limits future flexibility for tokenomics adjustments (7.4 Economic).

UpgradesLow9/10

The contract correctly implements the upgradeable pattern using OpenZeppelin's `Initializable` and `Upgradeable` contracts (7.7 Upgrades). The constructor calls `_disableInitializers()` and the `initialize` function uses the `initializer` modifier, preventing re-initialization. This setup ensures safe future upgrades of the contract logic.

Security Checklist

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

Holder Composition

31.8% in top 10
8.3% in wallets23.5% in contracts
Effective Concentration17.7%

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

$61.7K across 5 pairs
Pancakeswap v2WBNBanalysed$61.7K100.0%Pancakeswap v2USDT$00.0%Uniswap v2USDT$00.0%

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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

1 addresses
Deployer
0x7d58…8688

What Raised This Score

4 factors
  • Token age < 30 days (still settling)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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
BroccoliLow RiskWorld of Dypians (WOD)Low RiskMomentum (MNTM)Low RiskHachiko Inu (HACHIKO)Low RiskBanana For Scale (BANANAS31)Low RiskCubus Store Coin (CSC)Low Risk

Would You Like a More Detailed Audit of 翻身币税助力凉兮翻身?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit