Quantum Audit Logo

Is Max Sister Safe?

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

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

Max Sister LILY
0x7dbc…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and state transitions. The contract leverages OpenZeppelin's upgradeable contracts and includes features like anti-farmer protection and tax liquidation. While the architecture is generally sound and follows good practices for upgradeability, potential reentrancy risks in the tax liquidation logic (due to truncated code), significant owner privileges, and variable gas costs for users interacting with the main pool warrant attention. The overall risk level is assessed as Medium.

1 High2 Medium1 Low1 Informational
Volume 24h
$131.2K
Liquidity
$39.2K
Price
$0.0001306
Token Age
28d
Top 10 Holders
37.2%

Security Findings

1 High2 Med1 Low1 Info
High

Potential Reentrancy Risk in `_liquidateTax`

H-01The `_liquidateTax` function collects tax amounts and likely performs external calls to `ITaxProcessor` and `IDividend` contracts for distribution, as indicated by the contract's imports and the function's purpose. The provided code snippet for `_liquidateTax` is truncated, preventing a full analysis. Without proper implementation of the Checks-Effects-Interactions pattern and robust reentrancy guards (beyond the `notLiquidating` flag, whose full usage is unknown), external calls within this function could be vulnerable to reentrancy attacks, allowing an attacker to drain funds or manipulate contract state.
IssueThe `_liquidateTax` function collects tax amounts and likely performs external calls to `ITaxProcessor` and `IDividend` contracts for distribution, as indicated by the contract's imports and the function's purpose. The provided code snippet for `_liquidateTax` is truncated, preventing a full analysis. Without proper implementation of the Checks-Effects-Interactions pattern and robust reentrancy guards (beyond the `notLiquidating` flag, whose full usage is unknown), external calls within this function could be vulnerable to reentrancy attacks, allowing an attacker to drain funds or manipulate contract state.
FixProvide the complete source code for the `_liquidateTax` function for a thorough review. Ensure that all external calls are made after all state changes have been applied (Effects) and that a reentrancy guard (like the `notLiquidating` flag) is correctly implemented to prevent re-entry during external calls. Consider using OpenZeppelin's `ReentrancyGuard` or a similar pattern.
StatusUnresolved
Medium

Centralization Risk with Owner Privileges

M-01The `owner` role has significant control over critical contract functions, including `startMigration` and `finalizeMigration`. These functions directly control the `PoolState` transitions, which dictate the token's tax rates and anti-farmer mechanisms. A compromised owner key or a malicious owner could unilaterally alter the token's economic behavior, potentially leading to unexpected taxes or state changes for users.
IssueThe `owner` role has significant control over critical contract functions, including `startMigration` and `finalizeMigration`. These functions directly control the `PoolState` transitions, which dictate the token's tax rates and anti-farmer mechanisms. A compromised owner key or a malicious owner could unilaterally alter the token's economic behavior, potentially leading to unexpected taxes or state changes for users.
FixImplement a multi-signature wallet for the `owner` address to require multiple approvals for critical operations. Alternatively, integrate a time-lock mechanism for sensitive functions, introducing a delay between the owner's decision and its execution, allowing the community to react to potentially malicious actions.
StatusUnresolved
Medium

Variable Gas Costs and State Changes on Transfers to `mainPool`

M-02The `_liquidateTax` function is called unconditionally at the beginning of every `_transfer` operation if the recipient (`to`) is the `mainPool`. This means that any transfer to the `mainPool` can trigger complex logic, including state transitions (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) and tax liquidation. This can lead to unpredictable and potentially high gas costs for users, as well as unexpected changes in the token's tax rates during a seemingly simple transfer operation.
IssueThe `_liquidateTax` function is called unconditionally at the beginning of every `_transfer` operation if the recipient (`to`) is the `mainPool`. This means that any transfer to the `mainPool` can trigger complex logic, including state transitions (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) and tax liquidation. This can lead to unpredictable and potentially high gas costs for users, as well as unexpected changes in the token's tax rates during a seemingly simple transfer operation.
FixEvaluate if `_liquidateTax` needs to be called on *every* transfer to `mainPool`. Consider alternative mechanisms, such as a separate `liquidateTax` function that can be called by anyone (or specific roles) when conditions are met, or a more gas-efficient check within `_transfer` to only trigger `_liquidateTax` under specific, less frequent circumstances. Clearly document the gas implications and potential state changes for users interacting with the `mainPool`.
StatusUnresolved
Low

`uint48` for `antiFarmerExpirationTime`

L-01The `antiFarmerExpirationTime` variable is stored as a `uint48`. While `uint48` is sufficient for typical anti-farmer durations (up to approximately 8925 years from the Unix epoch), it imposes a hard limit on the maximum possible duration. In contrast, `taxExpirationTime` uses `uint64`. Using a smaller type than necessary for timestamps can lead to issues if the protocol's lifespan or desired durations exceed these limits in the distant future, or if there's a desire for consistency.
IssueThe `antiFarmerExpirationTime` variable is stored as a `uint48`. While `uint48` is sufficient for typical anti-farmer durations (up to approximately 8925 years from the Unix epoch), it imposes a hard limit on the maximum possible duration. In contrast, `taxExpirationTime` uses `uint64`. Using a smaller type than necessary for timestamps can lead to issues if the protocol's lifespan or desired durations exceed these limits in the distant future, or if there's a desire for consistency.
FixConsider using `uint64` for `antiFarmerExpirationTime` for consistency with `taxExpirationTime` and to provide a larger timestamp range, mitigating any potential future issues with extremely long durations. This change would have minimal gas impact.
StatusUnresolved
Info

Ambiguous Initialization of `taxExpirationTime`

I-01In the `initialize` function, `taxExpirationTime` is set to `uint64(params.taxDuration)`, which represents a duration. However, in `finalizeMigration`, this value is updated by adding `block.timestamp` (`currentPoolState.taxExpirationTime + block.timestamp`), effectively converting it into an absolute timestamp. This dual interpretation (duration vs. timestamp) can be confusing and might lead to misinterpretation of the variable's purpose at different stages of the contract's lifecycle.
IssueIn the `initialize` function, `taxExpirationTime` is set to `uint64(params.taxDuration)`, which represents a duration. However, in `finalizeMigration`, this value is updated by adding `block.timestamp` (`currentPoolState.taxExpirationTime + block.timestamp`), effectively converting it into an absolute timestamp. This dual interpretation (duration vs. timestamp) can be confusing and might lead to misinterpretation of the variable's purpose at different stages of the contract's lifecycle.
FixTo improve clarity, consider renaming `params.taxDuration` to `params.taxPeriod` or `params.taxDurationSeconds` to explicitly indicate it's a duration. Additionally, add comments in both `initialize` and `finalizeMigration` to clarify that `taxExpirationTime` initially stores a duration and is later converted to an absolute timestamp upon migration finalization.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates a solid technical foundation (7.1 Architecture) by utilizing OpenZeppelin's upgradeable ERC20 and access control modules, ensuring standard compliance and security patterns. The use of `PackedPoolState` for gas efficiency is a positive aspect. However, the truncated `_liquidateTax` function (7.2 Code Security) presents a potential reentrancy vulnerability if external calls are not properly guarded, and the complex state transition logic within `_transfer` can lead to variable gas costs and unexpected behavior for users (7.8 Operations).

GovernanceLow8/10

The contract's economic model (7.4 Economic) is based on dynamic tax rates and liquidation thresholds, which are configurable during initialization. The `owner` (7.3 Access Control) holds significant power, including the ability to initiate and finalize migration phases, which directly impacts the token's tax structure and functionality. This centralization of control (7.5 Governance) introduces a single point of failure and potential for economic manipulation if the owner's key is compromised or acts maliciously.

UpgradesMedium5/10

The contract is designed as an upgradeable proxy using the UUPS pattern (7.7 Upgrades), leveraging OpenZeppelin's `Initializable` and `ERC20Upgradeable` modules. The constructor correctly calls `_disableInitializers()`, and the `initialize` function uses the `initializer` modifier, which are standard and secure practices for upgradeable contracts. This design allows for future enhancements and bug fixes without redeploying the token, minimizing upgrade-related risks.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

37.2% in top 10
17.3% in wallets19.9% in contracts
Effective Concentration25.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

$39.3K across 2 pairs
Pancakeswap v2WBNBanalysed$39.2K99.8%Pancakeswap v3USDT$970.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

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

Key Addresses

1 addresses
Deployer
0x374d…10d6

What Raised This Score

8 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 20% (37.2% total → 25.3% effective; 17.3% in EOAs, 19.9% in contracts — mild)
  • Liquidity < $50k ($39,270 across 2 pairs — thin market)
  • Token age < 30 days (still settling)
  • 1 High 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

Related Audits

6 more on the record
ARKMedium Risk牛来Medium RiskSaturnMedium RiskXPIN Token (XPIN)Medium RiskTRADOORMedium RiskTutorial (TUT)Medium Risk

Would You Like a More Detailed Audit of Max Sister?

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

Get Detailed Audit