Quantum Audit Logo

Is ElonCoin a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

ElonCoin ELONCOIN
0xece9…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an ERC20 token with advanced tax mechanisms, including asymmetric buy/sell taxes, anti-farmer tax, and a dynamic liquidation threshold. The contract utilizes OpenZeppelin's upgradeable patterns and gas-optimized storage. Key findings include significant centralization of control by the owner, critical trust placed in the external TaxProcessor contract, and complexity in the core transfer logic. While robust security practices like SafeERC20 and reentrancy guards are present, the high degree of external dependency and owner privilege introduces substantial risk.

2 High2 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$659.8800
Liquidity
$22.9K
Price
$0.00004525
Token Age
1d
Top 10 Holders
35.1%

Security Findings

2 High2 Med1 Low1 Info
High

Centralization Risk via Owner Privileges

H-01The `onlyOwner` role has extensive control over critical contract parameters and external dependencies. This includes setting tax rates (`setTaxRates`), durations (`setTaxDuration`, `setAntiFarmerDuration`), external contract addresses (`setTaxProcessor`, `setDividendContract`, `setV2Router`, `setQuoteToken`), and managing pool addresses (`addPool`, `removePool`). This centralizes significant power, making the protocol highly dependent on the owner's integrity and operational security. A compromised owner key could lead to malicious changes, fund manipulation, or system disruption.
IssueThe `onlyOwner` role has extensive control over critical contract parameters and external dependencies. This includes setting tax rates (`setTaxRates`), durations (`setTaxDuration`, `setAntiFarmerDuration`), external contract addresses (`setTaxProcessor`, `setDividendContract`, `setV2Router`, `setQuoteToken`), and managing pool addresses (`addPool`, `removePool`). This centralizes significant power, making the protocol highly dependent on the owner's integrity and operational security. A compromised owner key could lead to malicious changes, fund manipulation, or system disruption.
FixConsider implementing a multi-signature wallet for the owner role to require multiple approvals for critical operations. Explore mechanisms for progressive decentralization of some parameters over time, or introduce time-locks for sensitive changes to allow community review.
StatusUnresolved
High

Critical Trust in `TaxProcessor` Contract

H-02The `taxProcessor` contract is granted a highly privileged role. It is responsible for processing collected taxes and, critically, can influence the `liquidationThreshold` via the internal `_adjustLiquidationThreshold` function, which is called by the `taxProcessor`. A compromised or malicious `taxProcessor` could lead to manipulation of the token's economic parameters, such as the liquidation threshold, or misuse of collected tax funds, directly impacting token holders and protocol stability.
IssueThe `taxProcessor` contract is granted a highly privileged role. It is responsible for processing collected taxes and, critically, can influence the `liquidationThreshold` via the internal `_adjustLiquidationThreshold` function, which is called by the `taxProcessor`. A compromised or malicious `taxProcessor` could lead to manipulation of the token's economic parameters, such as the liquidation threshold, or misuse of collected tax funds, directly impacting token holders and protocol stability.
FixConduct a thorough security audit of the `TaxProcessor` contract itself. Implement strict access controls within `TaxProcessor` and ensure its logic is robust against manipulation. Consider adding safeguards in `FlapTaxTokenV3` to limit the frequency or magnitude of `liquidationThreshold` adjustments, even by the `taxProcessor`.
StatusUnresolved
Medium

Complex `_transfer` Logic and Tax Calculation

M-01The overridden `_transfer` function incorporates complex logic for calculating and applying asymmetric buy/sell taxes, anti-farmer taxes, and interacting with the `taxProcessor`. The intricate flow, especially the timing of external calls to `ITaxProcessor(taxProcessor).processTax` relative to internal transfers and state updates, increases the surface area for subtle bugs, incorrect tax calculations, or reentrancy issues if not thoroughly tested. While a `notLiquidating` flag is used as a reentrancy guard, the overall complexity remains a concern.
IssueThe overridden `_transfer` function incorporates complex logic for calculating and applying asymmetric buy/sell taxes, anti-farmer taxes, and interacting with the `taxProcessor`. The intricate flow, especially the timing of external calls to `ITaxProcessor(taxProcessor).processTax` relative to internal transfers and state updates, increases the surface area for subtle bugs, incorrect tax calculations, or reentrancy issues if not thoroughly tested. While a `notLiquidating` flag is used as a reentrancy guard, the overall complexity remains a concern.
FixPerform extensive unit and integration testing, including edge cases for tax rates (zero, max), different pool states, and anti-farmer periods. Consider using formal verification tools to prove the correctness of the `_transfer` and tax calculation logic. Document the exact flow and state changes clearly.
StatusUnresolved
Medium

Potential for Economic Manipulation via `taxProcessor` (External Dependency)

M-02The `taxProcessor` contract determines the `liqThresholdDirection` which directly influences the token's `liquidationThreshold`. If the `taxProcessor` relies on external data (e.g., spot prices from DEXes, volume metrics) that can be manipulated (e.g., via flash loans or concentrated liquidity attacks), it could lead to an undesirable or exploitative adjustment of the liquidation threshold. This could negatively impact token economics, liquidity, or trigger unintended liquidations.
IssueThe `taxProcessor` contract determines the `liqThresholdDirection` which directly influences the token's `liquidationThreshold`. If the `taxProcessor` relies on external data (e.g., spot prices from DEXes, volume metrics) that can be manipulated (e.g., via flash loans or concentrated liquidity attacks), it could lead to an undesirable or exploitative adjustment of the liquidation threshold. This could negatively impact token economics, liquidity, or trigger unintended liquidations.
FixEnsure the `taxProcessor` uses robust, decentralized, and manipulation-resistant oracle solutions for any external data feeds that inform `liqThresholdDirection`. Implement circuit breakers or rate limits on `liquidationThreshold` adjustments to prevent rapid or extreme changes, even if triggered by the `taxProcessor`.
StatusUnresolved
Low

Immutable Threshold Limits Require New Implementation for Changes

L-01`MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` are declared as `immutable` and set in the constructor of the implementation contract. While this is an explicit design choice to establish system-wide, unchangeable limits for all clones, it means that any future adjustment to these fundamental limits would necessitate deploying an entirely new implementation contract and migrating all existing proxies to it, rather than a simple upgrade of the current implementation.
Issue`MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` are declared as `immutable` and set in the constructor of the implementation contract. While this is an explicit design choice to establish system-wide, unchangeable limits for all clones, it means that any future adjustment to these fundamental limits would necessitate deploying an entirely new implementation contract and migrating all existing proxies to it, rather than a simple upgrade of the current implementation.
FixAcknowledge this design constraint and ensure that the chosen immutable values are thoroughly vetted for long-term suitability. If flexibility for these parameters is desired in the future, a different architectural approach would be required, potentially involving configurable parameters stored in a separate, upgradeable configuration contract.
StatusUnresolved
Info

Initial Token Distribution to `msg.sender`

I-01During the `initialize` function, the entire `maxSupply` of tokens is minted to `msg.sender`. This means the deployer or initializer address will initially hold all 1 billion tokens. While a common pattern for initial distribution, it centralizes the entire token supply at a single address immediately after deployment.
IssueDuring the `initialize` function, the entire `maxSupply` of tokens is minted to `msg.sender`. This means the deployer or initializer address will initially hold all 1 billion tokens. While a common pattern for initial distribution, it centralizes the entire token supply at a single address immediately after deployment.
FixEnsure that the address used for initialization is a secure, multi-signature wallet or a controlled distribution contract. Have a clear and transparent plan for the subsequent distribution of these tokens to avoid perceived centralization of token holdings.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract demonstrates good technical practices, leveraging OpenZeppelin's upgradeable contracts and `SafeERC20` for secure token interactions (7.2 Code Security). Gas optimization is evident through the `PackedPoolState` struct. A reentrancy guard (`notLiquidating` flag) is implemented to protect critical state changes during liquidation. However, the overridden `_transfer` function introduces considerable complexity due to its integrated tax calculation and external calls to the `taxProcessor`, increasing the potential for subtle bugs (7.2 Code Security).

GovernanceHigh3/10

The protocol exhibits a high degree of centralization, with the `onlyOwner` role possessing extensive control over critical parameters such as tax rates, durations, and external contract addresses (7.3 Access Control, 7.4 Economic). A significant trust assumption is placed on the `taxProcessor` contract, which can adjust the `liquidationThreshold` and handles collected taxes; a compromise here could severely impact the protocol (7.6 External). While the `maxSupply` is fixed and `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` are immutable at the implementation level, the dynamic `liquidationThreshold` mechanism, influenced by the `taxProcessor`, introduces potential economic manipulation risks if the `taxProcessor` relies on vulnerable external data (7.4 Economic).

UpgradesHigh3/10

The contract correctly implements OpenZeppelin's `Initializable` pattern and `_disableInitializers()` in the constructor, ensuring proper upgradeability (7.7 Upgrades). The use of `immutable` variables for `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` means these core limits cannot be changed via a standard upgrade, requiring a new implementation deployment for any adjustments. Standard storage layout considerations apply for future upgrades, particularly concerning the `PackedPoolState` struct, to maintain compatibility (7.7 Upgrades).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

35.1% in top 10
8.8% in wallets26.3% in contracts
Effective Concentration19.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

$22.9K

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.

Key Addresses

1 addresses
Deployer
0x94ef…eff0

What Raised This Score

8 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • Liquidity < $50k ($22,856 across 1 pairs — thin market)
  • Token age < 7 days (early, volatile)
  • 2 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
Pro Token (PRO)High RiskSUMMERHigh RiskSomniaOFT (SOMI)High RiskGoPlus Security (GPS)High RiskAsteroid Shiba (ASTEROID)High RiskCaldera (ERA)High Risk

Would You Like a More Detailed Audit of ElonCoin?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit