Quantum Audit Logo
Launch App

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

Is Max Sister Safe?

LILYBNB Chain
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance8/10Upgrades5/10Checks passed5 of 7Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and state transitions.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 20%
  • Liquidity < $50k
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax3% / 3.6%

Holders

as of audit · Sep 4, 2026
19.9%Contracts17.3%Wallets62.8%Everyone else
19.9%Contracts17.3%Wallets62.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
37.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking19.9%
  • Walletsanonymous holders, free to sell17.3%
  • Everyone elsethe rest of the supply62.8%
Effective concentrationwhat the score reads25.3%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$39.3K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$39.2KShare of depth99.8%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 High2 Medium1 Low1 Info
High

Potential Reentrancy Risk in _liquidateTax

The _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.H-01

Issue

The _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.

Fix

Provide 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.

Status

Unresolved

Medium

Centralization Risk with Owner Privileges

The 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.M-01

Issue

The 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.

Fix

Implement 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.

Status

Unresolved

Medium

Variable Gas Costs and State Changes on Transfers to mainPool

The _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.M-02

Issue

The _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.

Fix

Evaluate 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.

Status

Unresolved

Low

uint48 for antiFarmerExpirationTime

The 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.L-01

Issue

The 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.

Fix

Consider 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.

Status

Unresolved

Info

Ambiguous Initialization of taxExpirationTime

In 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.I-01

Issue

In 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.

Fix

To 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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).

Governance8/10Low risk

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.

Upgrades5/10Medium risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to complete the audit of the full _liquidateTax function to ensure no reentrancy vulnerabilities exist, especially concerning external calls to taxProcessor and dividendContract.

Consider implementing a multi-signature wallet or a time-lock for critical owner-controlled functions to mitigate centralization risks. Additionally, thoroughly test the gas implications of the _liquidateTax function being called on every transfer to the main pool to ensure a predictable user experience.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age28d
Contract0x7dbc…7777
Deployer0x374d…10d6
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
Max Sister security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202633Low
  2. Sep 3, 202614Low

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

Related Audits

6 more on the recordAll audits
ARKBNB Chain33Low牛来BNB Chain33LowSaturnBNB Chain33LowTrusta.AITA · BNB Chain33LowMeta Financial AIMEFAI · BNB Chain33LowXeleb AIXCX · BNB Chain33Low

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 Is this your token? Publish your own audit on this page