Is Edel Safe? Smart Contract Security Analysis

Security Findings

1 Med3 Low1 Info

Medium

Centralized Control by Owner

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

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

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

StatusUnresolved

Low

Immutability of Key Operational Addresses

L-01The `_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).

IssueThe `_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).

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

StatusUnresolved

Low

External Protocol Dependency Risk

L-02The 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).

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

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

StatusUnresolved

Low

Publicly Callable Single-Use Liquidity Pool Creation

L-03The `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).

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

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

StatusUnresolved

Info

Incomplete Code Provided for Levy Logic

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow10/10

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

GovernanceLow7/10

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

UpgradesLow9/10

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.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

51.6% in top 10

9.4% in wallets42.2% in contracts

Effective Concentration26.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

$675.2K across 8 pairs

AerodromeWETHanalysed$671.5K AerodromeUSDC$2.9K 0xB0C2…9C88BG$201 Uniswap v4ETH$175 PancakeswapWETH$171 Uniswap v4USDC$109

Show 2 more pairsShow less

Uniswap v4ETH$39 Hydrex CLAMMWETH$22

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

4 addresses

Deployer

0xfe6a…f136

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.

What Raised This Score

6 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

Is Edel Safe?

Security Findings

Centralized Control by Owner

Immutability of Key Operational Addresses

External Protocol Dependency Risk

Publicly Callable Single-Use Liquidity Pool Creation

Incomplete Code Provided for Levy Logic

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Edel?