Is 吉祥马 Safe? Smart Contract Security Analysis

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Audit History

1 audit on record

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The FlapTaxTokenV2 contract implements an upgradeable ERC20 token with advanced tax mechanisms, including anti-farmer and time-dependent taxes, and dynamic liquidation thresholds. The contract utilizes OpenZeppelin's upgradeable standards and incorporates gas optimizations. While the core tax and liquidation logic is well-structured with reentrancy guards, the high degree of owner centralization presents a significant governance risk. Minor logical inconsistencies and dependencies on external contracts for critical operations were also identified.

Final Recommendation: To enhance the security and decentralization of the FlapTaxTokenV2 protocol, consider implementing a multi-signature wallet or a time-locked governance mechanism for critical owner-controlled functions. This would mitigate the risks associated with a single point of failure. Additionally, review the external dependencies for the tax liquidation process, potentially adding robust error handling or fallback mechanisms to ensure token transfers remain operational even if external calls fail.

Category Ratings

TechnicalLow

9/10

The contract demonstrates good technical practices, including the use of OpenZeppelin upgradeable contracts and a gas-optimized `PackedPoolState` struct (7.1 Architecture, 7.2 Code Security). A reentrancy guard (`notLiquidating`) is correctly implemented for the `_liquidateTax` function. However, th

GovernanceLow

7/10

The contract features configurable tax rates, durations, and dynamic liquidation thresholds, providing flexibility for protocol management (7.4 Economic). However, the owner possesses extensive control over all critical parameters, including tax rates, liquidation settings, and external contract add

UpgradesLow

10/10

The contract is designed for upgradeability using OpenZeppelin's `Initializable` pattern, correctly calling `_disableInitializers()` in the constructor and using the `initializer` modifier (7.7 Upgrades). This ensures a robust upgrade path. A `custom:security-note` within the `PackedPoolState`

LP Distribution

LP Burned20.8%

LP Locked20.8%

Top-1 Unlocked Holder2.3%

What Raised This Score

4 factors

Top-10 concentration > 50% (69.8% total → 60.4% effective; 54.1% in EOAs, 15.7% in contracts — heavy)
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

Security Findings

7 total

1 High 2 Medium 2 Low 2 Info

H-01HighUnresolved

Excessive Owner Privileges and Centralization Risk

The `owner` role has extensive control over critical contract parameters, including `taxRate`, `taxDuration`, `antiFarmerDuration`, `liquidationThreshold`, `liqExpectedOutputAmount`, `quoteToken`, `v2Router`, `taxProcessor`, `dividendContract`, and the ability to add/remove pools and manage migration states. This high degree of centralization means a single compromised owner key could lead to malicious changes, such as setting prohibitive tax rates, redirecting tax funds, or disrupting core functionality, posing a significant risk to the protocol's integrity and user funds. (7.3 Access Control, 7.5 Governance)

Recommendation: Implement a multi-signature wallet (e.g., Gnosis Safe) for the `owner` role to require multiple approvals for critical operations. For highly sensitive functions, consider adding a time-lock mechanism to allow users to react to pending changes. Explore progressive decentralization by introducing community governance for certain parameters over time.

M-01MediumUnresolved

Inconsistent Initialization of `taxExpirationTime`

In the `initialize` function, `poolState.taxExpirationTime` is set to `params.taxDuration`, which is a duration in seconds. However, in `finalizeMigration`, this value is then updated by adding `block.timestamp` to convert it into an absolute timestamp. This design means `taxExpirationTime` stores a duration initially and only becomes an absolute timestamp after `finalizeMigration` is called. If `finalizeMigration` is significantly delayed or never called, the intended tax expiration logic could be misinterpreted or behave unexpectedly, potentially leading to taxes expiring prematurely or much later than anticipated from the initial `taxDuration` parameter. (7.2 Code Security)

Recommendation: To improve clarity and consistency, consider initializing `taxExpirationTime` directly as an absolute timestamp (`block.timestamp + params.taxDuration`) in the `initialize` function if the tax is intended to start immediately upon deployment. If the tax period is meant to begin only after migration finalization, ensure this is clearly documented and that `finalizeMigration` is called promptly. Alternatively, rename the `taxExpirationTime` variable to `taxDuration` in `initialize` to accurately…

M-02MediumUnresolved

Single Point of Failure in Tax Liquidation via `v2Router`

The `_liquidateTax` function relies on an external `v2Router` address (e.g., Uniswap V2 Router) to swap collected tax tokens for `quoteToken`. If this `v2Router` contract is compromised, becomes unavailable, or is maliciously upgraded (even if the owner can change it), the tax liquidation mechanism could fail. This would lead to an accumulation of tax tokens within the contract, preventing their proper processing and distribution, and potentially disrupting the token's economic model. (7.6 External)

Recommendation: While the owner can update `v2Router`, consider implementing a fallback mechanism or a grace period for `v2Router` changes. Additionally, explore integrating with multiple DEX routers or a decentralized oracle for price discovery during liquidation to reduce reliance on a single external entity. Implement monitoring for `v2Router` functionality to detect issues promptly.

L-01LowUnresolved

`uint96` for `liquidationThreshold` with `maxSupply` Considerations

The `PackedPoolState` struct uses `uint96` for `liquidationThreshold`. A `custom:security-note` in the code correctly highlights that if the `maxSupply` of the token (currently `1e9 ether`) were to increase beyond `~79B ether`, `uint96` might not be sufficient, leading to potential overflow issues. While `1e9 ether` is well within `uint96` limits, this represents a future upgrade risk if the `maxSupply` is ever significantly increased without a corresponding adjustment to the `liquidationThreshold` type. (7.7 Upgrades, 7.2 Code Security)

Recommendation: Maintain vigilance regarding the `maxSupply` and `liquidationThreshold` types during any future upgrades or modifications to the token's supply. If `maxSupply` is ever increased beyond `uint96` capacity, ensure `liquidationThreshold` is upgraded to a larger type (e.g., `uint128` or `uint256`) to prevent silent overflows and maintain correct liquidation logic. Document this constraint clearly for future developers.

L-02LowUnresolved

Revert Risk from External Calls in `_liquidateTax`

The `_liquidateTax` function makes external calls to `ITaxProcessor(taxProcessor).processTax` and `IDividend(dividendContract).trackShare`. If these external contracts revert due to an error, unexpected state, or malicious design, the `_liquidateTax` function will also revert. Since `_liquidateTax` is called within the `_transfer` function, a failure in these external calls could prevent users from transferring tokens when the liquidation condition is met, leading to a denial of service for transfers. (7.2 Code Security, 7.6 External)

Recommendation: Consider wrapping the external calls to `processTax` and `trackShare` in `try/catch` blocks. This would allow the `_liquidateTax` function (and thus `_transfer`) to complete even if the external calls fail, potentially logging the error and allowing the tax tokens to accumulate for later manual processing or retry. This would prioritize token transfer availability over immediate tax processing in case of external contract issues.

I-01InformationalUnresolved

Redundant `IERC20` Import

The contract imports `IERC20` from `lib/openzeppelin-contracts/contracts/token/ERC20/IERC20.sol`. However, `ERC20Upgradeable` (which `FlapTaxTokenV2` inherits from) already imports `IERC20` internally. Additionally, `SafeERC20` is used for external `IERC20` interactions, which also handles its own `IERC20` requirements. Therefore, this explicit import of `IERC20` is redundant and can be removed without affecting functionality. (7.2 Code Security)

Recommendation: Remove the redundant `import {IERC20} from "lib/openzeppelin-contracts/contracts/token/ERC20/IERC20.sol";` statement to clean up the code and improve readability.

I-02InformationalUnresolved

Missing Zero Address Checks in Setter Functions

Several setter functions, such as `setQuoteToken`, `setV2Router`, and `setTaxProcessor`, do not include explicit checks to prevent setting critical addresses to `address(0)`. While `taxProcessor` is checked in `initialize`, it can be subsequently set to `address(0)` by the owner. Setting these critical addresses to zero could lead to broken functionality (e.g., tax liquidation failing if `v2Router` or `quoteToken` is zero) and operational issues. (7.2 Code Security)

Recommendation: Add `require(newAddress != address(0), "Zero address not allowed")` checks to setter functions for critical addresses like `setQuoteToken`, `setV2Router`, and `setTaxProcessor` to prevent accidental or malicious misconfiguration. For `setDividendContract`, where `address(0)` might be a valid 'no dividend' state, ensure this behavior is clearly documented.

Is 吉祥马 Safe? 吉祥马