Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Edel Safe?

EDELBase
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 record
SummaryAI Copilot

The audit reviewed the provided Solidity code for ContractOne, an ERC20 token implementing a time-decaying levy mechanism and integration with Aerodrome for liquidity provision.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Medium finding(s) from audit
  • 3 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (51.6% total → 26.3% effective; 9.4% in EOAs, 42.2% 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)
  • 1 Medium finding(s) from audit
  • 3 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

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
42.2%Contracts9.4%Wallets48.4%Everyone else
42.2%Contracts9.4%48.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
51.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking42.2%
  • Walletsanonymous holders, free to sell9.4%
  • Everyone elsethe rest of the supply48.4%
Effective concentrationwhat the score reads26.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$675.2K across 8 pairs
LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$671.5KShare of depth99.5%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xc94f…27ca0x3a60…26a70x3ea7…c5bc

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

Security Findings

1 Medium3 Low1 Info
Medium

Centralized Control by Owner

The contract inherits Ownable, granting a single external address (the owner) significant control over the contract. While the current code does not expose many owner-only functions beyond standard Ownable features, any future additions of administrative functions could introduce a single point of failure or potential for malicious actions if the owner's private key is compromised. This centralization affects access control (7.3 Access Control) and operational risk (7.8 Operations).M-01

Issue

The contract inherits Ownable, granting a single external address (the owner) significant control over the contract. While the current code does not expose many owner-only functions beyond standard Ownable features, any future additions of administrative functions could introduce a single point of failure or potential for malicious actions if the owner's private key is compromised. This centralization affects access control (7.3 Access Control) and operational risk (7.8 Operations).

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the contract owner to distribute control among multiple trusted parties. This enhances security by requiring multiple approvals for critical operations, reducing the risk associated with a single point of failure.

Status

Unresolved

Low

Immutability of Key Operational Addresses

The _lpRecipient and _levyRecipients addresses are set as immutable in the constructor. While this prevents unauthorized modification, it also means these addresses cannot be updated if they become compromised, inactive, or if the project's operational needs change. This could lead to levy funds or LP tokens being sent to an inaccessible or malicious address, impacting economic stability and operations (7.4 Economic, 7.8 Operations).L-01

Issue

The _lpRecipient and _levyRecipients addresses are set as immutable in the constructor. While this prevents unauthorized modification, it also means these addresses cannot be updated if they become compromised, inactive, or if the project's operational needs change. This could lead to levy funds or LP tokens being sent to an inaccessible or malicious address, impacting economic stability and operations (7.4 Economic, 7.8 Operations).

Fix

Assess the long-term operational requirements. If flexibility is desired, consider implementing owner-controlled functions to update these recipient addresses. If immutability is a deliberate design choice, ensure robust, long-term security and management of the designated recipient addresses.

Status

Unresolved

Low

External Protocol Dependency Risk

The contract relies on external protocols, specifically Aerodrome DEX (router, factory, pool) and WETH, for its liquidity provision mechanism. The security and functionality of ContractOne are directly dependent on the correct and secure operation of these external contracts. Any vulnerabilities, exploits, or unexpected behavior in Aerodrome or WETH could directly impact the functionality and assets managed by this contract (7.6 External).L-02

Issue

The contract relies on external protocols, specifically Aerodrome DEX (router, factory, pool) and WETH, for its liquidity provision mechanism. The security and functionality of ContractOne are directly dependent on the correct and secure operation of these external contracts. Any vulnerabilities, exploits, or unexpected behavior in Aerodrome or WETH could directly impact the functionality and assets managed by this contract (7.6 External).

Fix

Regularly monitor the security posture and operational status of all integrated external protocols. Implement robust error handling and consider circuit breakers or emergency mechanisms if the contract's functionality is critically dependent on external systems that could fail or be exploited.

Status

Unresolved

Low

Publicly Callable Single-Use Liquidity Pool Creation

The createLiquidityPool function is external and can be called by any address, but only once. While the function includes checks for ethAmount, maxSlippageBps, and ensures LP tokens are sent to _lpRecipient, allowing any user to trigger this critical, one-time setup could lead to suboptimal initial liquidity parameters if not coordinated. A malicious or uncoordinated actor could front-run the intended caller with less favorable slippage settings (within the allowed range) or a smaller ETH amount, potentially impacting the initial market health (7.4 Economic, 7.8 Operations).L-03

Issue

The createLiquidityPool function is external and can be called by any address, but only once. While the function includes checks for ethAmount, maxSlippageBps, and ensures LP tokens are sent to _lpRecipient, allowing any user to trigger this critical, one-time setup could lead to suboptimal initial liquidity parameters if not coordinated. A malicious or uncoordinated actor could front-run the intended caller with less favorable slippage settings (within the allowed range) or a smaller ETH amount, potentially impacting the initial market health (7.4 Economic, 7.8 Operations).

Fix

While the current implementation ensures the LP tokens go to the designated recipient, consider restricting the createLiquidityPool function to the owner or a trusted address. This would allow for controlled and coordinated liquidity pool creation with optimal parameters, preventing potential griefing or suboptimal initial market conditions.

Status

Unresolved

Info

Incomplete Code Provided for Levy Logic

The provided source code for the getCurrentLevyBps() function and the latter part of _updateLevyReductionStatus() is truncated. This prevents a full and accurate assessment of the core levy calculation and reduction mechanism, which is central to the token's economic model. Without this code, potential issues such as incorrect levy calculation, unexpected reduction behavior, or edge case vulnerabilities cannot be identified.I-01

Issue

The provided source code for the getCurrentLevyBps() function and the latter part of _updateLevyReductionStatus() is truncated. This prevents a full and accurate assessment of the core levy calculation and reduction mechanism, which is central to the token's economic model. Without this code, potential issues such as incorrect levy calculation, unexpected reduction behavior, or edge case vulnerabilities cannot be identified.

Fix

Provide the complete and untruncated source code for all contract functions, especially getCurrentLevyBps() and _updateLevyReductionStatus(), to enable a comprehensive security audit of the levy mechanism.

Status

Unresolved

Analysis

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

The audit reviewed the provided Solidity code for ContractOne, an ERC20 token implementing a time-decaying levy mechanism and integration with Aerodrome for liquidity provision. The contract utilizes OpenZeppelin libraries for security and best practices. However, a significant portion of the levy reduction logic (getCurrentLevyBps() and _updateLevyReductionStatus()) was truncated, preventing a complete assessment of this critical component. Identified risks include centralized ownership, immutability of key operational addresses, and reliance on external protocols.

Technical10/10Low risk

The contract demonstrates good technical practices by inheriting from OpenZeppelin's ERC20, ERC20Permit, Ownable, and ReentrancyGuard. It also uses SafeERC20, Math, and SafeCast for robust arithmetic operations (7.2 Code Security). The createLiquidityPool function correctly employs nonReentrant and handles external calls to WETH and Aerodrome (7.6 External). However, the provided source code for getCurrentLevyBps() and the latter part of _updateLevyReductionStatus() is truncated, which prevents a full technical review of the levy calculation and reduction logic, posing an unknown risk (7.1 Architecture, 7.2 Code Security).

Governance7/10Low risk

The tokenomics include an initial levy on swaps that reduces over time, with a portion of initial tokens allocated for liquidity provision and the remainder to a specified recipient. Levy funds are distributed to a rotating list of immutable recipients (7.4 Economic). The Ownable pattern grants the deployer significant control, representing a centralization risk (7.3 Access Control). Key operational addresses like _lpRecipient and _levyRecipients are immutable, which prevents malicious changes but also hinders updates if an address becomes compromised or inactive (7.8 Operations).

Upgrades9/10Low risk

The contract is not designed with an upgrade proxy pattern (e.g., UUPS, Transparent) and is therefore not upgradeable. This eliminates upgrade-related risks such as storage collisions or proxy misconfigurations (7.7 Upgrades). Any changes to the contract's logic would require a new deployment.

Final RecommendationWhat to do about this score

It is recommended to provide the complete source code for a comprehensive security assessment, particularly for the levy reduction logic.

Consider implementing a multi-signature wallet for owner functions to mitigate centralization risks. For immutable addresses, ensure robust key management or consider a mechanism for updates if operational flexibility is desired in the future. Thoroughly test all external interactions, especially with Aerodrome, to ensure expected behavior under various conditions.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkBase
Token age9mo
Contract0xfb31…cc95
Deployer0xfe6a…f136
Badge for your website
Edel 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. Aug 14, 202616Low

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

Frequently Asked Questions

What is the EDEL contract address?

The Edel contract on Base is 0xfb31f85a8367210b2e4ed2360d2da9dc2d2ccc95. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Edel a scam?

Quantum Audit's risk score for Edel is 16/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: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is EDEL liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $675.2K.

Who holds EDEL?

As of Sep 4, 2026, the 10 largest holders own 51.6% of the supply. The Holders section on this page shows who they are by holder type.

Would You Like a More Detailed Audit of Edel?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page