Honeypot, rug-pull and ownership checks
BNB ChainThe FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and state-based pool interactions.
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 locked or burned.
0x6992…374bNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
_transfer via _processTax_transfer function calls _liquidateTax, which in turn calls _processTax (an external call to taxProcessor). While _liquidateTax uses a notLiquidating flag to prevent reentrant calls to itself, the _transfer function itself does not have a reentrancy guard. If the _processTax external call can reenter the token contract (e.g., by calling transfer or transferFrom), it could lead to unexpected behavior, state manipulation, or double-spending before the initial _transfer completes. The re-reading of poolState after _processTax further suggests potential state changes by the external call.H-01The _transfer function calls _liquidateTax, which in turn calls _processTax (an external call to taxProcessor). While _liquidateTax uses a notLiquidating flag to prevent reentrant calls to itself, the _transfer function itself does not have a reentrancy guard. If the _processTax external call can reenter the token contract (e.g., by calling transfer or transferFrom), it could lead to unexpected behavior, state manipulation, or double-spending before the initial _transfer completes. The re-reading of poolState after _processTax further suggests potential state changes by the external call.
Implement a reentrancy guard (e.g., OpenZeppelin's ReentrancyGuard) on the _transfer function or ensure that the _processTax function (and the taxProcessor contract) is designed to be non-reentrant. Follow the Checks-Effects-Interactions pattern strictly, ensuring all state changes are completed before any external calls.
Unresolved
taxProcessor and dividendContract AddressestaxProcessor and dividendContract are set only during the initialize function and cannot be modified later. This design choice introduces rigidity (7.8 Operations). If these external contracts need to be updated, replaced due to vulnerabilities, or if their addresses change for any reason, the FlapTaxTokenV3 contract itself would require an upgrade. Contract upgrades are more complex, costly, and carry higher risk than simply updating an address via an owner-controlled function.M-01The addresses for taxProcessor and dividendContract are set only during the initialize function and cannot be modified later. This design choice introduces rigidity (7.8 Operations). If these external contracts need to be updated, replaced due to vulnerabilities, or if their addresses change for any reason, the FlapTaxTokenV3 contract itself would require an upgrade. Contract upgrades are more complex, costly, and carry higher risk than simply updating an address via an owner-controlled function.
Consider adding owner-controlled functions (e.g., setTaxProcessor(address newProcessor)) to allow the owner to update the taxProcessor and dividendContract addresses. This would provide greater operational flexibility and reduce the need for full contract upgrades for simple address changes. Ensure appropriate access control and validation for these setter functions.
Unresolved
_liquidateTax_liquidateTax function contains intricate conditional logic for transitioning between PoolStates (TaxFree, TaxEnforced, TaxEnforcedAntiFarmer) based on block.timestamp and liquidationThreshold. While the current logic appears sound, complex state machines are inherently prone to subtle bugs or edge cases that might not be immediately apparent during initial review. Misconfigurations of taxExpirationTime, antiFarmerExpirationTime, or liquidationThreshold could lead to unexpected state transitions or tax processing behavior.L-01The _liquidateTax function contains intricate conditional logic for transitioning between PoolStates (TaxFree, TaxEnforced, TaxEnforcedAntiFarmer) based on block.timestamp and liquidationThreshold. While the current logic appears sound, complex state machines are inherently prone to subtle bugs or edge cases that might not be immediately apparent during initial review. Misconfigurations of taxExpirationTime, antiFarmerExpirationTime, or liquidationThreshold could lead to unexpected state transitions or tax processing behavior.
Thoroughly review and test all possible scenarios and edge cases for the state transition logic in _liquidateTax. Consider adding comprehensive unit tests and formal verification if possible, to ensure the state machine behaves as intended under all conditions. Document the expected behavior for each state transition clearly.
Unresolved
_processTax FunctionFlapTaxTokenV3.sol is truncated, specifically the implementation of the _processTax function within _liquidateTax. This function is critical for the core tax processing mechanism and involves an external call to taxProcessor. Without the complete code for _processTax, a full and comprehensive security assessment of the tax handling, external interactions, and potential vulnerabilities (e.g., reentrancy, gas limits, error handling) cannot be performed.I-01The provided source code for FlapTaxTokenV3.sol is truncated, specifically the implementation of the _processTax function within _liquidateTax. This function is critical for the core tax processing mechanism and involves an external call to taxProcessor. Without the complete code for _processTax, a full and comprehensive security assessment of the tax handling, external interactions, and potential vulnerabilities (e.g., reentrancy, gas limits, error handling) cannot be performed.
Provide the complete and untruncated source code for all relevant contracts, especially _processTax and the ITaxProcessor interface implementation, to enable a full security audit.
Unresolved
The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and state-based pool interactions. The audit identified a potential high-severity reentrancy vulnerability due to an external call within the transfer flow, and medium-severity concerns regarding the immutability of critical external contract addresses. A full assessment of the _processTax function was limited due to truncated code.
The contract leverages OpenZeppelin's upgradeable standards and SafeERC20 for secure token operations (7.2 Code Security). Gas optimizations are present through the PackedPoolState struct (7.1 Architecture). However, a potential reentrancy vulnerability exists in the _transfer flow due to an external call to _processTax (7.2 Code Security). The complex state transition logic in _liquidateTax also introduces potential for subtle bugs (7.2 Code Security).
The contract implements a multi-state tax system with owner-controlled migration phases, providing flexibility in token economics (7.4 Economic, 7.5 Governance). Owner privileges are appropriately restricted to critical state transitions (7.3 Access Control). A key concern is the immutability of the taxProcessor and dividendContract addresses after initialization, which could necessitate contract upgrades for simple address changes (7.4 Economic, 7.8 Operations).
The contract correctly implements the OpenZeppelin upgradeable pattern, including Initializable and _disableInitializers() in the constructor (7.7 Upgrades). Immutable variables are properly declared in the constructor, preventing storage slot conflicts during upgrades (7.7 Upgrades). The use of a single PackedPoolState struct for multiple state variables also helps mitigate storage layout risks during upgrades (7.7 Upgrades).
It is highly recommended to address the potential reentrancy vulnerability by implementing a reentrancy guard in the _transfer function or ensuring that _processTax cannot cause reentrant calls.
Consider adding owner-controlled functions to update the taxProcessor and dividendContract addresses to enhance operational flexibility. Thoroughly review the complex state transition logic in _liquidateTax for all possible edge cases, and ensure the complete _processTax function is audited.
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 ElonCoin contract on BNB Chain is 0x499c573997a1382f4051ece45b3d6b2f0e317777. 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 ElonCoin is 28/100 (Low 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: Locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $32.7K.
As of Sep 4, 2026, the 10 largest holders own 46.8% of the supply. The Holders section on this page shows who they are by holder type.
Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
