Quantum Audit Logo

Is ELON a Scam?

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

ELON ELON
0xa3d3…aba3
Base
Not verifiedThis 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.
Last checked 9d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DopplerERC20V1 contract implements an ERC20 token with voting capabilities and a vesting mechanism. It utilizes Solady libraries for efficiency and security. The contract includes features such as a configurable balance limit and a pool locking mechanism. While the overall architecture appears sound and standard security practices like `Ownable` and `Initializable` are employed, the audit identified several areas for improvement, particularly concerning operational flexibility, upgrade safety, and the economic implications of initial token distribution. A significant portion of the core vesting logic was truncated, limiting a full assessment of its security.

2 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
$204.1K
Liquidity
$106.1K
Price
$0.000002519
Token Age
1d
Top 10 Holders
51.8%

Security Findings

2 Med1 Low1 Info
Medium

Immutable Controller Address for Balance Limit Feature

M-01The `controller` address, responsible for disabling the `isBalanceLimitActive` feature via `disableBalanceLimit()`, is set only during the `initialize` function. If the `balanceLimitEnd_` and `maxBalanceLimit_` parameters are both zero during initialization, the `controller` address remains `address(0)`. Even if the balance limit is active, the `controller` cannot be changed after initialization. This creates an operational inflexibility and a single point of failure: if the initial `controller` address is compromised or becomes inactive, the balance limit cannot be disabled without a contract upgrade.
IssueThe `controller` address, responsible for disabling the `isBalanceLimitActive` feature via `disableBalanceLimit()`, is set only during the `initialize` function. If the `balanceLimitEnd_` and `maxBalanceLimit_` parameters are both zero during initialization, the `controller` address remains `address(0)`. Even if the balance limit is active, the `controller` cannot be changed after initialization. This creates an operational inflexibility and a single point of failure: if the initial `controller` address is compromised or becomes inactive, the balance limit cannot be disabled without a contract upgrade.
FixImplement an `onlyOwner` function to allow the `controller` address to be updated after initialization. This would provide greater operational flexibility and resilience against a compromised or inactive controller.
StatusUnresolved
Medium

Upgradeability Risk with Dynamic Public Array

M-02The `vestingSchedules` array is declared as `public` and is a dynamic array. In upgradeable contracts, adding new state variables *after* a dynamic array in a future implementation can lead to storage slot collisions if the array grows significantly. While `vestingSchedules` is currently the last non-mapping state variable, this pattern introduces a risk if not carefully managed in future upgrades.
IssueThe `vestingSchedules` array is declared as `public` and is a dynamic array. In upgradeable contracts, adding new state variables *after* a dynamic array in a future implementation can lead to storage slot collisions if the array grows significantly. While `vestingSchedules` is currently the last non-mapping state variable, this pattern introduces a risk if not carefully managed in future upgrades.
FixWhen planning future upgrades, ensure that new state variables are not introduced in a way that would cause storage slot collisions with the `vestingSchedules` array. Consider using explicit storage gap patterns or placing dynamic arrays at the end of the storage layout to mitigate this risk.
StatusUnresolved
Low

High Initial Pre-Mint Allocation Parameters

L-01The constants `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are both set to `0.8 ether`, effectively allowing up to 80% of the `initialSupply` to be pre-minted and allocated through vesting schedules. While this is a design choice, such a high pre-allocation percentage can lead to significant token concentration in early beneficiaries, potentially impacting initial liquidity, decentralization, and market dynamics.
IssueThe constants `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are both set to `0.8 ether`, effectively allowing up to 80% of the `initialSupply` to be pre-minted and allocated through vesting schedules. While this is a design choice, such a high pre-allocation percentage can lead to significant token concentration in early beneficiaries, potentially impacting initial liquidity, decentralization, and market dynamics.
FixReview the tokenomics and distribution strategy to ensure that such a high pre-allocation aligns with the project's goals for decentralization and market health. Consider if a lower initial pre-mint percentage or a more diversified distribution strategy would be beneficial.
StatusUnresolved
Info

Incomplete Vesting Logic Provided for Audit

I-01The core logic for `_available`, `_releaseFor`, and `_releaseAllFor` functions, which are central to the vesting mechanism, is truncated in the provided source code. A comprehensive security assessment of the vesting functionality, including correct calculation of vested amounts, cliff/duration enforcement, and prevention of double-spending, cannot be performed without access to these critical internal implementations.
IssueThe core logic for `_available`, `_releaseFor`, and `_releaseAllFor` functions, which are central to the vesting mechanism, is truncated in the provided source code. A comprehensive security assessment of the vesting functionality, including correct calculation of vested amounts, cliff/duration enforcement, and prevention of double-spending, cannot be performed without access to these critical internal implementations.
FixProvide the complete source code for all internal vesting-related functions (`_available`, `_releaseFor`, `_releaseAllFor`) to enable a full and accurate security assessment of the vesting mechanism.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good technical practices, leveraging battle-tested Solady libraries for ERC20, Ownable, and Initializable functionalities (7.2 Code Security). Error handling is robust with custom error types, and the use of `LibTransient` for efficient storage is a positive architectural choice (7.1 Architecture). However, an operational inflexibility exists where the `controller` address, vital for managing the balance limit feature, is immutable after initialization (7.3 Access Control). Additionally, the use of a dynamic public array (`vestingSchedules`) in an upgradeable context introduces potential storage collision risks for future upgrades (7.7 Upgrades).

GovernanceMedium4/10

The contract's economic model includes a vesting mechanism with configurable schedules, which is a standard approach for token distribution. The `owner` role is appropriately restricted for critical functions like `lockPool` and `updateTokenURI` (7.5 Governance). However, the initial pre-mint allocation parameters allow for up to 80% of the initial supply to be vested, which could lead to significant token concentration (7.4 Economic). A comprehensive assessment of the core vesting logic (`_available`, `_releaseFor`, `_releaseAllFor`) was not possible due to truncated code, leaving a gap in the economic security analysis (7.4 Economic).

UpgradesLow7/10

The contract is designed for upgradeability, correctly using `Initializable` and `_disableInitializers()` (7.7 Upgrades). The storage layout for fixed variables appears straightforward. However, the presence of a public dynamic array (`vestingSchedules`) introduces a potential risk for storage slot collisions if new state variables are introduced after it in future upgrades, requiring careful management to maintain upgrade safety (7.7 Upgrades).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

51.8% in top 10
6.8% in wallets45.0% in contracts
Effective Concentration24.8%

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

$107.0K across 6 pairs
Uniswap v4SPCXcanalysed$106.1K99.2%Uniswap v3toby$6970.7%Uniswap v4USDC$1260.1%Uniswap v4USDC$740.1%Uniswap v4USDC$40.0%

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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xf793…af75
Unlocked LP Held By
0x0964…d359

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

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (51.8% total → 24.8% effective; 6.8% in EOAs, 45.0% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 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
aeonHigh RiskRobo Token (ROBO)High RiskPlumbingHigh RiskNockchain (NOCK)Medium RiskViciCoin (VCNT)High RiskgitlawbHigh Risk

Would You Like a More Detailed Audit of ELON?

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

Get Detailed Audit