Is 蝴蝶人生 Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 Med1 Low2 Info

Critical

Reentrancy Vulnerability in `_liquidateTax`

C-01The `_liquidateTax` function, called by `_transfer`, attempts to prevent reentrancy by setting `currentPoolState.notLiquidating = false;` before making external calls to `ITaxProcessor.processTax` and `IDividend.distributeDividends`. However, `currentPoolState` is a local memory variable. The updated `poolState` (storage) is only written *after* these external calls complete. If an external call re-enters `_transfer` (and subsequently `_liquidateTax`), the `poolState.notLiquidating` in storage would still be `true` from the perspective of the re-entrant call, allowing the liquidation logic to execute again. This could lead to double processing of tax funds, unexpected state changes, or drai…

IssueThe `_liquidateTax` function, called by `_transfer`, attempts to prevent reentrancy by setting `currentPoolState.notLiquidating = false;` before making external calls to `ITaxProcessor.processTax` and `IDividend.distributeDividends`. However, `currentPoolState` is a local memory variable. The updated `poolState` (storage) is only written *after* these external calls complete. If an external call re-enters `_transfer` (and subsequently `_liquidateTax`), the `poolState.notLiquidating` in storage would still be `true` from the perspective of the re-entrant call, allowing the liquidation logic to execute again. This could lead to double processing of tax funds, unexpected state changes, or drai…

FixImplement a proper reentrancy guard using the Checks-Effects-Interactions pattern. Update the `poolState.notLiquidating` storage variable *before* any external calls are made. A robust solution would be to use OpenZeppelin's `ReentrancyGuard` modifier on the `_liquidateTax` function or ensure the storage variable `poolState.notLiquidating` is updated to `false` before any external calls and reverted to `true` only after all external calls have successfully completed.

StatusUnresolved

Medium

Centralized Control by Owner

M-01The contract grants significant control to the `onlyOwner` for critical operations such as `startMigration` and `finalizeMigration`. While this provides clear administrative control, it introduces a single point of failure. A compromise of the owner's private key could lead to unauthorized manipulation of the token's state and tax mechanisms, potentially causing economic instability or loss of funds.

IssueThe contract grants significant control to the `onlyOwner` for critical operations such as `startMigration` and `finalizeMigration`. While this provides clear administrative control, it introduces a single point of failure. A compromise of the owner's private key could lead to unauthorized manipulation of the token's state and tax mechanisms, potentially causing economic instability or loss of funds.

FixConsider implementing a multi-signature wallet for the owner address to distribute control and reduce the risk of a single point of failure. Alternatively, explore transitioning to a more decentralized governance model (e.g., a DAO) for critical protocol decisions, or at least for the most sensitive functions.

StatusUnresolved

Medium

Critical External Dependency Risk

M-02The contract relies on external `ITaxProcessor` and `IDividend` contracts for core tax processing and dividend distribution. The addresses for these contracts are set during initialization and cannot be changed post-deployment. If these external contracts contain vulnerabilities, are malicious, or become unmaintained, they could lead to a denial of service for token transfers (if they revert) or a loss of collected tax funds (if they mismanage or are exploited).

IssueThe contract relies on external `ITaxProcessor` and `IDividend` contracts for core tax processing and dividend distribution. The addresses for these contracts are set during initialization and cannot be changed post-deployment. If these external contracts contain vulnerabilities, are malicious, or become unmaintained, they could lead to a denial of service for token transfers (if they revert) or a loss of collected tax funds (if they mismanage or are exploited).

FixThoroughly audit the `ITaxProcessor` and `IDividend` contracts to ensure their security and reliability. Consider adding an `onlyOwner` function to allow updating these critical external addresses in case of an emergency or to facilitate upgrades of these dependencies. Implement circuit breakers or emergency stop functions that can disable or bypass these external calls if they become problematic.

StatusUnresolved

Low

Lack of Emergency Pause Mechanism

L-01The contract lacks a general emergency pause mechanism (e.g., using OpenZeppelin's `Pausable` module) that could temporarily halt sensitive operations like token transfers. In the event of a critical bug discovery, a market exploit, or other unforeseen circumstances, the absence of such a mechanism could prevent the team from quickly mitigating damage.

IssueThe contract lacks a general emergency pause mechanism (e.g., using OpenZeppelin's `Pausable` module) that could temporarily halt sensitive operations like token transfers. In the event of a critical bug discovery, a market exploit, or other unforeseen circumstances, the absence of such a mechanism could prevent the team from quickly mitigating damage.

FixIntegrate OpenZeppelin's `PausableUpgradeable` contract. This would allow the owner (or a designated role) to pause and unpause transfers and other critical functions, providing a crucial safety net during emergencies.

StatusUnresolved

Info

Immutability of `metaURI`

I-01The `metaURI` variable, which stores the token's metadata URI, is set during initialization and cannot be updated thereafter. While this ensures immutability, it removes the flexibility to change the URI if, for example, the hosting service changes, the link breaks, or the metadata itself needs to be updated.

IssueThe `metaURI` variable, which stores the token's metadata URI, is set during initialization and cannot be updated thereafter. While this ensures immutability, it removes the flexibility to change the URI if, for example, the hosting service changes, the link breaks, or the metadata itself needs to be updated.

FixIf flexibility is desired for future updates, consider adding an `onlyOwner` function to allow modification of the `metaURI`. If the immutability is an intentional design choice, ensure this is clearly documented.

StatusUnresolved

Info

Potential for Decreasing `liquidationThreshold`

I-02The `_liquidateTax` function includes logic to decrease the `liquidationThreshold` by 10% (`currentPoolState.liquidationThreshold * 9 / 10`) if the `taxAmount` is less than the current threshold. This mechanism could lead to a continuously decreasing threshold over time if collected tax amounts are frequently low. A very low `liquidationThreshold` might make it difficult to trigger the desired liquidation behavior, potentially accumulating large amounts of tax that are never processed.

IssueThe `_liquidateTax` function includes logic to decrease the `liquidationThreshold` by 10% (`currentPoolState.liquidationThreshold * 9 / 10`) if the `taxAmount` is less than the current threshold. This mechanism could lead to a continuously decreasing threshold over time if collected tax amounts are frequently low. A very low `liquidationThreshold` might make it difficult to trigger the desired liquidation behavior, potentially accumulating large amounts of tax that are never processed.

FixReview the long-term economic implications of a continuously decreasing `liquidationThreshold`. Ensure this behavior aligns with the protocol's intended design. Consider implementing a minimum floor for the `liquidationThreshold` or providing an `onlyOwner` function to reset or adjust it if it drops to an undesirable level.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages OpenZeppelin's upgradeable ERC20, Ownable, and Permit modules, demonstrating a commitment to established standards (7.2 Code Security). The state-based tax mechanism is complex but structured. However, a critical reentrancy vulnerability was identified in the `_liquidateTax` function, where the reentrancy guard is applied to a local memory variable rather than the storage state, allowing re-entrant calls to bypass the intended protection (7.2 Code Security). This flaw could lead to double spending of collected tax funds or unexpected state manipulation. The reliance on external `ITaxProcessor` and `IDividend` contracts introduces further technical risk if these dependencies are not robust (7.6 External).

GovernanceMedium6/10

The contract's economic model is centered around a dynamic tax system and liquidation mechanism, with `maxSupply` being fixed at initialization (7.4 Economic). The `_liquidateTax` function includes logic to adjust the `liquidationThreshold`, which could potentially decrease over time, impacting the frequency of tax processing (7.4 Economic). Governance is highly centralized, with the `OwnableUpgradeable` pattern granting the owner exclusive control over critical state transitions like `startMigration` and `finalizeMigration` (7.5 Governance). This single point of control presents a significant risk if the owner's key is compromised, as it could lead to unauthorized changes in the token's operational state.

UpgradesLow8/10

The contract is designed as an upgradeable proxy implementation, correctly utilizing OpenZeppelin's `Initializable` and `Upgradeable` patterns (7.7 Upgrades). The `_disableInitializers()` in the constructor and the `initializer` modifier are correctly implemented, preventing re-initialization. State variables are managed, with `PackedPoolState` efficiently using a single storage slot. Future upgrades must carefully consider storage layout, especially if new variables are added to `PackedPoolState` or if the order of existing variables is changed, to avoid storage collisions (7.7 Upgrades).

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

29.8% in top 10

4.5% in wallets25.3% in contracts

Effective Concentration14.6%

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

$251.6K across 4 pairs

Pancakeswap v2AAPLBanalysed$251.6K Pancakeswap v2FIST$4 Pancakeswap v2WBNB$4 Pancakeswap v2USDT$2

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 Holder62.9%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0xc95b…b24b

Unlocked LP Held By

0x1584…cb020x14e5…be4a

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

What Raised This Score

7 factors

Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 62.9% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
Token age < 30 days (still settling)
1 Critical 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

Final Recommendation

AI Copilot

Address the critical reentrancy vulnerability in `_liquidateTax` by implementing a robust reentrancy guard that updates storage state before external calls, or by using OpenZeppelin's `ReentrancyGuard` modifier.…

Read the verdictHide

Enhance security by considering a multi-signature wallet for ownership or implementing a more decentralized governance model to mitigate the risks associated with centralized control. Thoroughly audit all external dependencies (`ITaxProcessor`, `IDividend`) and consider adding mechanisms for updating these addresses or implementing emergency circuit breakers. Finally, evaluate the economic implications of the `liquidationThreshold` adjustment logic and consider adding a minimum floor or owner-controlled reset mechanism.

Contract

TypeFlapTaxTokenV3

Audit History

1 audit on record

Sep 1234

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

Not Signed In

Is 蝴蝶人生 Safe?

Security Findings

Reentrancy Vulnerability in `_liquidateTax`

Centralized Control by Owner

Critical External Dependency Risk

Lack of Emergency Pause Mechanism

Immutability of `metaURI`

Potential for Decreasing `liquidationThreshold`

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of 蝴蝶人生?