Quantum Audit Logo
Launch App

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

Is ElonCoin a Scam?

ELONCOINBNB 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 recordNew Launch · 1d old
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance4/10Upgrades4/10Checks passed3 of 5Findings2 High · 2 Medium · 1 Low · 1 Info6
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.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • LP lock status UNKNOWN — the pool's LP could not be read
  • Liquidity < $50k
  • Token age < 7 days
  • 2 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)
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 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

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.

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockUnknown
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
26.3%Contracts8.8%Wallets64.9%Everyone else
26.3%Contracts8.8%64.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
35.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking26.3%
  • Walletsanonymous holders, free to sell8.8%
  • Everyone elsethe rest of the supply64.9%
Effective concentrationwhat the score reads19.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$22.9K

The risk score reads depth across every pair.

LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$22.9KShare of depth100.0%

Security Findings

2 High2 Medium1 Low1 Info
High

Centralization Risk via Owner Privileges

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

Issue

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

Fix

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

Status

Unresolved

High

Critical Trust in TaxProcessor Contract

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

Issue

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

Fix

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

Status

Unresolved

Medium

Complex _transfer Logic and Tax Calculation

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

Issue

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

Fix

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

Status

Unresolved

Medium

Potential for Economic Manipulation via taxProcessor (External Dependency)

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

Issue

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

Fix

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

Status

Unresolved

Low

Immutable Threshold Limits Require New Implementation for Changes

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

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.

Fix

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

Status

Unresolved

Info

Initial Token Distribution to msg.sender

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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

Governance4/10Medium risk

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

Upgrades4/10Medium risk

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

Final RecommendationWhat to do about this score

It is strongly recommended to decentralize control where feasible, or at minimum, implement a robust multi-signature wallet for the owner role to mitigate the high centralization risk.

A comprehensive audit of the TaxProcessor contract is crucial, given its privileged role and potential impact on the token's economic stability and fund management. Additionally, thorough testing, including fuzzing and formal verification, should be conducted on the complex _transfer and tax calculation logic to identify any subtle edge cases or reentrancy vulnerabilities.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age1d
Contract0xece9…7777
Deployer0x94ef…eff0
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
ElonCoin 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, 202662Medium
  2. Jul 31, 202655Medium

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

Related Audits

6 more on the recordAll audits
Starpower NetworkSTAR · BNB Chain62MediumXRP TokenXRP · BNB Chain62MediumBTR tokenBTR · BNB Chain62MediumIrysBNB Chain62MediumNEXSTNXT · BNB Chain62MediumGENBNB Chain62Medium

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