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 →

妖蝶 妖蝶
0xf609…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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with custom tax mechanics, anti-farmer logic, and a multi-state pool system. The contract utilizes OpenZeppelin's upgradeable standards, ensuring a robust foundation for upgradeability and ERC20 compliance. Key strengths include the use of packed storage for gas efficiency and clear state management. However, potential reentrancy and denial-of-service risks exist within the `_liquidateTax` function due to likely external calls to `ITaxProcessor` and `IDividend` (based on imported interfaces and stored addresses), which could lead to critical vulnerabilities if not properly guarded. Additionally, the immutability of critical external contract addresses and significant owner privileges introduce medium-level operational and centralization risks.

1 High2 Medium2 Low2 Informational
Volume 24h
$207.9K
Liquidity
$123.2K
Price
$0.001413
Token Age
13d
Top 10 Holders
53.8%

Security Findings

1 High2 Med2 Low2 Info
High

Potential Reentrancy and Denial of Service in `_liquidateTax`

H-01The `_liquidateTax` function is called on every `_transfer` and is responsible for collecting and potentially distributing tax. While the provided code snippet is truncated, the presence of `taxProcessor` and `dividendContract` addresses, along with imported interfaces `ITaxProcessor` and `IDividend`, strongly suggests that external calls to these contracts occur within the full `_liquidateTax` function. If these external calls are made without proper reentrancy guards (e.g., Checks-Effects-Interactions pattern) or before critical state updates, a malicious external contract could re-enter `FlapTaxTokenV3` and exploit its state. Furthermore, if these external calls revert, they could cause…
IssueThe `_liquidateTax` function is called on every `_transfer` and is responsible for collecting and potentially distributing tax. While the provided code snippet is truncated, the presence of `taxProcessor` and `dividendContract` addresses, along with imported interfaces `ITaxProcessor` and `IDividend`, strongly suggests that external calls to these contracts occur within the full `_liquidateTax` function. If these external calls are made without proper reentrancy guards (e.g., Checks-Effects-Interactions pattern) or before critical state updates, a malicious external contract could re-enter `FlapTaxTokenV3` and exploit its state. Furthermore, if these external calls revert, they could cause…
FixImplement a reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard`) on the `_liquidateTax` function or ensure that all external calls adhere strictly to the Checks-Effects-Interactions pattern. Specifically, all state changes should occur before any external calls. Additionally, consider implementing robust error handling or fallback mechanisms for external calls to prevent denial of service.
StatusUnresolved
Medium

Immutability of Critical External Contract Addresses

M-01The `taxProcessor` and `dividendContract` addresses are set during the `initialize` function and cannot be changed thereafter. This design choice means that if these external contracts need to be updated, replaced due to bugs, vulnerabilities, or changes in business logic, a full contract upgrade of `FlapTaxTokenV3` would be required. This reduces operational flexibility and increases the complexity and risk associated with necessary updates.
IssueThe `taxProcessor` and `dividendContract` addresses are set during the `initialize` function and cannot be changed thereafter. This design choice means that if these external contracts need to be updated, replaced due to bugs, vulnerabilities, or changes in business logic, a full contract upgrade of `FlapTaxTokenV3` would be required. This reduces operational flexibility and increases the complexity and risk associated with necessary updates.
FixConsider adding owner-controlled functions (e.g., `setTaxProcessor(address newProcessor)`) to allow the owner to update these critical external contract addresses. Implement a timelock or multi-signature wallet for such changes to provide an additional layer of security and transparency.
StatusUnresolved
Medium

Centralization Risk with Owner Privileges

M-02The `onlyOwner` role has significant control over critical contract state transitions, specifically `startMigration` and `finalizeMigration`. These functions can alter the token's tax behavior and operational state. While common in initial project phases, this level of control by a single entity introduces a centralization risk, as a compromised owner key or a malicious owner could unilaterally change core tokenomics.
IssueThe `onlyOwner` role has significant control over critical contract state transitions, specifically `startMigration` and `finalizeMigration`. These functions can alter the token's tax behavior and operational state. While common in initial project phases, this level of control by a single entity introduces a centralization risk, as a compromised owner key or a malicious owner could unilaterally change core tokenomics.
FixEvaluate the long-term governance model. For production environments, consider transitioning ownership to a multi-signature wallet (e.g., Gnosis Safe) or a decentralized autonomous organization (DAO) to distribute control and enhance security. Implement a timelock for critical owner actions to provide a window for community review and reaction.
StatusUnresolved
Low

Lack of Event Emission for Critical Parameter Changes

L-01While `PoolStateChanged` is emitted for state transitions, other critical parameters like `antiFarmerDuration`, `liqExpectedOutputAmount`, `mainPool`, or changes to the `pools` mapping (if such modification functions were implemented) do not emit events. The absence of events for such changes makes it challenging for off-chain monitoring tools, block explorers, and users to track and verify modifications to the contract's operational parameters.
IssueWhile `PoolStateChanged` is emitted for state transitions, other critical parameters like `antiFarmerDuration`, `liqExpectedOutputAmount`, `mainPool`, or changes to the `pools` mapping (if such modification functions were implemented) do not emit events. The absence of events for such changes makes it challenging for off-chain monitoring tools, block explorers, and users to track and verify modifications to the contract's operational parameters.
FixEmit events for all significant parameter changes that affect the contract's behavior or tokenomics. This improves transparency, auditability, and allows for easier integration with external monitoring systems.
StatusUnresolved
Low

Potential for MEV/Front-running on `_liquidateTax` Thresholds

L-02The `_liquidateTax` function's behavior, including state transitions (e.g., `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) and tax collection, is dependent on `block.timestamp` and `balanceOf(address(this))` relative to `liquidationThreshold`. Sophisticated actors (MEV bots) could potentially time their transactions to trigger or avoid certain tax/liquidation events, or even manipulate the `balanceOf(address(this))` by sending tokens just before a liquidation check, to gain an economic advantage.
IssueThe `_liquidateTax` function's behavior, including state transitions (e.g., `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) and tax collection, is dependent on `block.timestamp` and `balanceOf(address(this))` relative to `liquidationThreshold`. Sophisticated actors (MEV bots) could potentially time their transactions to trigger or avoid certain tax/liquidation events, or even manipulate the `balanceOf(address(this))` by sending tokens just before a liquidation check, to gain an economic advantage.
FixWhile difficult to fully eliminate, consider if the precise timing of `_liquidateTax` triggers can be made less predictable or if the impact of small manipulations can be minimized. For example, using a time-weighted average for `block.timestamp` or adding a small random delay (if feasible) could reduce predictability. However, this is often a trade-off with design simplicity.
StatusUnresolved
Info

Hardcoded `maxSupply`

I-01The `maxSupply` is declared as a `constant` with a value of `1e9 ether`. This means the total supply of the token is fixed at deployment and cannot be changed without a contract upgrade. While this is a common and often desired characteristic for ERC20 tokens, it limits future flexibility if the project's tokenomics require adjustments to the total supply.
IssueThe `maxSupply` is declared as a `constant` with a value of `1e9 ether`. This means the total supply of the token is fixed at deployment and cannot be changed without a contract upgrade. While this is a common and often desired characteristic for ERC20 tokens, it limits future flexibility if the project's tokenomics require adjustments to the total supply.
FixNo direct action is required if this is an intentional design choice. However, ensure that the project's long-term tokenomics plan accounts for this immutability. If future flexibility is desired, consider making `maxSupply` a state variable controlled by governance.
StatusUnresolved
Info

`MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` Immutability

I-02The `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` values are set as `immutable` in the constructor. This design choice means these base liquidation thresholds cannot be modified in future upgrades. While `initialLiquidationThreshold` is set from `START_LIQ_THRESHOLD` and might be mutable, the core immutable values could restrict future flexibility if the underlying economic model needs to adapt to unforeseen market conditions or protocol changes.
IssueThe `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` values are set as `immutable` in the constructor. This design choice means these base liquidation thresholds cannot be modified in future upgrades. While `initialLiquidationThreshold` is set from `START_LIQ_THRESHOLD` and might be mutable, the core immutable values could restrict future flexibility if the underlying economic model needs to adapt to unforeseen market conditions or protocol changes.
FixNo direct action is required if this immutability is an intentional design constraint. Ensure that the project's long-term economic model is robust enough to not require changes to these fundamental thresholds. If flexibility is paramount, consider making these configurable state variables, albeit with increased complexity.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract leverages OpenZeppelin's battle-tested upgradeable contracts for ERC20, access control, and initialization, which is a strong foundation (7.1 Architecture, 7.2 Code Security). The `PackedPoolState` struct efficiently uses storage slots. However, the `_liquidateTax` function, which is called on every transfer, likely involves external calls to `ITaxProcessor` and `IDividend` (7.2 Code Security, 7.6 External). If these calls are not protected by reentrancy guards or follow the Checks-Effects-Interactions pattern, they could lead to reentrancy attacks or denial of service if external calls revert. The truncation of the provided code prevents a full analysis of this critical section.

GovernanceLow7/10

The `OwnableUpgradeable` pattern provides clear access control for critical functions like `startMigration` and `finalizeMigration` (7.3 Access Control, 7.5 Governance). The tokenomics involve dynamic tax rates and anti-farmer mechanisms, which are managed through state transitions. However, the owner has significant control over these state changes, introducing a centralization risk (7.5 Governance). The `taxProcessor` and `dividendContract` addresses are immutable after initialization, limiting operational flexibility (7.8 Operations). Additionally, the time-based and balance-based triggers in `_liquidateTax` could create opportunities for MEV or front-running by sophisticated actors (7.4 Economic).

UpgradesLow10/10

The contract correctly implements the OpenZeppelin upgradeable pattern, including `Initializable` and calling `_disableInitializers()` in the constructor (7.7 Upgrades). This ensures proper initialization and prevents re-initialization of the constructor. Storage layout for `PackedPoolState` is optimized, and new variables should be appended to avoid collisions in future upgrades. However, `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` are `immutable`, meaning their base values cannot be altered in future upgrades, which is a design constraint.

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

53.8% in top 10
49.6% in wallets4.2% in contracts
Effective Concentration51.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

$123.3K across 2 pairs
Pancakeswap v2WBNBanalysed$123.2K99.9%Pancakeswap v2BAN$1360.1%

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
0x2533…275d

What Raised This Score

5 factors
  • Top-10 concentration > 50% (53.8% total → 51.3% effective; 49.6% in EOAs, 4.2% in contracts — heavy)
  • Token age < 30 days (still settling)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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
ZygoSwap (ZSWAP)Medium RiskSIRENMedium RiskMEET48 Token (IDOL)Medium Riskbinanceus doodles (BOODLES)Medium RiskMarsCoinMedium RiskANDYMedium 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