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.
On-chain security analysis — is it a scam or legit?
Is Edel Safe?
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 →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.
- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking42.2%
- Walletsanonymous holders, free to sell9.4%
- Everyone elsethe rest of the supply48.4%
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- AerodromeWETHAnalysed$671.5K99.5%
- AerodromeUSDC$2.9K0.4%
- 0xB0C2…9C88BG$2010.0%
- Uniswap v4ETH$1750.0%
- PancakeswapWETH$1710.0%
- Uniswap v4USDC$1090.0%
Show 2 more pairs
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xc94f…27ca0x3a60…26a70x3ea7…c5bcNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
MediumCentralized 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
LowImmutability 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
LowExternal 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
LowPublicly 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
InfoIncomplete 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 4The 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).
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).
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- 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