On-chain security analysis — is it a scam or legit?
BNB ChainThe FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and a multi-state pool system.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xc502…1e28No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
_liquidateTax_liquidateTax function performs an external call to _processTax(taxAmount) on the taxProcessor contract. Before this call, currentPoolState.notLiquidating is set to false, and after the call, it is reset to true. If the taxProcessor contract is malicious or compromised, it could re-enter _liquidateTax or other functions in FlapTaxTokenV3 before notLiquidating is reset. This could lead to unexpected state changes, double-spending of collected taxes, or other malicious actions. This is a classic reentrancy pattern (7.2 Code Security, 7.6 External).H-01The _liquidateTax function performs an external call to _processTax(taxAmount) on the taxProcessor contract. Before this call, currentPoolState.notLiquidating is set to false, and after the call, it is reset to true. If the taxProcessor contract is malicious or compromised, it could re-enter _liquidateTax or other functions in FlapTaxTokenV3 before notLiquidating is reset. This could lead to unexpected state changes, double-spending of collected taxes, or other malicious actions. This is a classic reentrancy pattern (7.2 Code Security, 7.6 External).
Implement a reentrancy guard (e.g., OpenZeppelin's ReentrancyGuard) on the _liquidateTax function or ensure that all state changes related to notLiquidating are completed *before* any external calls are made. Alternatively, consider a 'checks-effects-interactions' pattern.
Unresolved
taxExpirationTime Calculation in finalizeMigrationfinalizeMigration function, the taxExpirationTime is updated with currentPoolState.taxExpirationTime + block.timestamp. The currentPoolState.taxExpirationTime is initialized with params.taxDuration in initialize. Adding block.timestamp to an already set duration (which is likely intended to be a future timestamp) will result in an incorrect and potentially extremely long or unintended expiration time. This logic error could lead to taxes being enforced for a much longer period than intended, impacting the token's economic model (7.4 Economic, 7.2 Code Security).H-02In the finalizeMigration function, the taxExpirationTime is updated with currentPoolState.taxExpirationTime + block.timestamp. The currentPoolState.taxExpirationTime is initialized with params.taxDuration in initialize. Adding block.timestamp to an already set duration (which is likely intended to be a future timestamp) will result in an incorrect and potentially extremely long or unintended expiration time. This logic error could lead to taxes being enforced for a much longer period than intended, impacting the token's economic model (7.4 Economic, 7.2 Code Security).
The taxExpirationTime should be set to block.timestamp + params.taxDuration (or a similar calculation based on the intended duration from the current time) in finalizeMigration, not currentPoolState.taxExpirationTime + block.timestamp. Review the intended behavior for taxExpirationTime and correct the calculation accordingly.
Unresolved
owner role has extensive control over critical contract functions, including startMigration and finalizeMigration, which dictate the transition between different PoolStates. The owner also controls the taxProcessor and dividendContract addresses through initialization parameters. While this may be intended for initial setup and operational flexibility, it introduces a single point of failure and trust. A compromised owner key could lead to unauthorized state changes or manipulation of the token's economic model (7.3 Access Control, 7.5 Governance).M-01The owner role has extensive control over critical contract functions, including startMigration and finalizeMigration, which dictate the transition between different PoolStates. The owner also controls the taxProcessor and dividendContract addresses through initialization parameters. While this may be intended for initial setup and operational flexibility, it introduces a single point of failure and trust. A compromised owner key could lead to unauthorized state changes or manipulation of the token's economic model (7.3 Access Control, 7.5 Governance).
Consider implementing a multi-signature wallet for the owner role to reduce the risk associated with a single point of compromise. As the protocol matures, explore decentralizing control through a governance mechanism or time-locked operations for critical functions.
Unresolved
uint48/uint64 Expiration TimestaxExpirationTime (uint64) and antiFarmerExpirationTime (uint48) variables store timestamps. Calculations like block.timestamp + antiFarmerDuration (where antiFarmerDuration is uint256) could potentially result in values exceeding the maximum capacity of uint48 or uint64 if the durations are extremely long. While block.timestamp itself is typically within uint48 range for many years, adding a very large antiFarmerDuration could cause an overflow, leading to incorrect expiration times (7.2 Code Security, 7.4 Economic).M-02The taxExpirationTime (uint64) and antiFarmerExpirationTime (uint48) variables store timestamps. Calculations like block.timestamp + antiFarmerDuration (where antiFarmerDuration is uint256) could potentially result in values exceeding the maximum capacity of uint48 or uint64 if the durations are extremely long. While block.timestamp itself is typically within uint48 range for many years, adding a very large antiFarmerDuration could cause an overflow, leading to incorrect expiration times (7.2 Code Security, 7.4 Economic).
Ensure that antiFarmerDuration and taxDuration parameters are constrained to values that, when added to block.timestamp, will not exceed the maximum values of uint48 or uint64. Alternatively, consider using uint256 for all timestamp-related variables if extremely long durations (beyond ~136 years for uint48 or ~584 billion years for uint64) are a design requirement, or implement explicit overflow checks.
Unresolved
_liquidateTax and Pool State Machine_liquidateTax function is invoked on every transfer to mainPool and is responsible for multiple state transitions, tax processing, and liquidation logic. The overall PoolState machine, with its five distinct states and various transition conditions, adds significant complexity to the contract. Complex logic increases the surface area for potential bugs and makes auditing and reasoning about the contract's behavior more challenging (7.1 Architecture, 7.2 Code Security).I-01The _liquidateTax function is invoked on every transfer to mainPool and is responsible for multiple state transitions, tax processing, and liquidation logic. The overall PoolState machine, with its five distinct states and various transition conditions, adds significant complexity to the contract. Complex logic increases the surface area for potential bugs and makes auditing and reasoning about the contract's behavior more challenging (7.1 Architecture, 7.2 Code Security).
Consider refactoring _liquidateTax into smaller, more focused functions to improve readability and maintainability. Thoroughly document the state machine transitions and their conditions to ensure clarity and prevent unintended behavior. Implement comprehensive unit tests for all state transitions and tax calculation scenarios.
Unresolved
The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and a multi-state pool system. The audit identified a critical reentrancy vulnerability in the tax liquidation process and a significant logical error in the calculation of tax expiration times during state transitions. These issues pose substantial risks to the contract's integrity and economic model.
The contract utilizes OpenZeppelin's upgradeable standards for ERC20 and access control, demonstrating a commitment to established patterns (7.1 Architecture). The tax calculation logic is generally sound, and packed storage is used for efficiency (7.2 Code Security). However, a significant reentrancy vulnerability exists in the _liquidateTax function due to an external call to _processTax without a reentrancy guard, potentially allowing malicious re-entry before state updates are complete. Additionally, the calculation of taxExpirationTime in finalizeMigration is incorrect, leading to an unintended and potentially exploitable duration (7.2 Code Security).
The contract implements a multi-state system for tax enforcement and migration, with onlyOwner functions controlling key state transitions (startMigration, finalizeMigration) (7.5 Governance). This provides centralized control over the token's operational phases. The economic model involves dynamic buy/sell taxes and a liquidation mechanism for collected taxes (7.4 Economic). A potential issue exists where uint48/uint64 expiration times could overflow if antiFarmerDuration or taxExpirationTime are set to extremely large values, although this is less likely with typical durations (7.4 Economic).
The contract is designed as an upgradeable proxy using OpenZeppelin's Initializable pattern (7.7 Upgrades). The constructor correctly calls _disableInitializers(), and the initialize function sets up the contract state appropriately. This adherence to established upgradeability patterns minimizes common upgrade-related risks.
Address the reentrancy vulnerability in _liquidateTax by implementing a reentrancy guard before the external call to _processTax.
Correct the taxExpirationTime calculation in finalizeMigration to ensure accurate duration setting. Review the potential for integer overflow in time-related variables and consider using uint256 for durations if extremely long periods are intended.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Randy contract on BNB Chain is 0x4154b19017a63d054ad1888bbde1e188253a7777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Randy is 66/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $48.6K.
As of Sep 4, 2026, the 10 largest holders own 40.2% of the supply. The Holders section on this page shows who they are by holder type.
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
