Is ElonCoin a Scam? Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Potential Reentrancy in `_transfer` via `_processTax`

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.

IssueThe `_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.

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

StatusUnresolved

Medium

Immutability of `taxProcessor` and `dividendContract` Addresses

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.

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

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

StatusUnresolved

Low

Complex State Transition Logic in `_liquidateTax`

L-01The `_liquidateTax` function contains intricate conditional logic for transitioning between `PoolState`s (`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.

IssueThe `_liquidateTax` function contains intricate conditional logic for transitioning between `PoolState`s (`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.

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

StatusUnresolved

Info

Truncated Code for `_processTax` Function

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.

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

FixProvide the complete and untruncated source code for all relevant contracts, especially `_processTax` and the `ITaxProcessor` interface implementation, to enable a full security audit.

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceLow8/10

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

UpgradesMedium5/10

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

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Holder Composition

46.8% in top 10

10.5% in wallets36.4% in contracts

Effective Concentration25.0%

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

$32.7K across 2 pairs

Pancakeswap v2WBNBanalysed$32.7K Uniswap v2USDT$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

2 addresses

Deployer

0xc51e…d26a

Unlocked LP Held By

0x6992…374b

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

8 factors

Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Top-10 concentration > 20% (46.8% total → 25.0% effective; 10.5% in EOAs, 36.4% in contracts — mild)
Liquidity < $50k ($32,727 across 2 pairs — thin market)
Token age < 30 days (still settling)
1 High finding(s) from audit
1 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

Is ElonCoin a Scam?

Security Findings

Potential Reentrancy in `_transfer` via `_processTax`

Immutability of `taxProcessor` and `dividendContract` Addresses

Complex State Transition Logic in `_liquidateTax`

Truncated Code for `_processTax` Function

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of ElonCoin?