Quantum Audit Logo

Is Eden Token Safe?

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

Is this your token? Publish your own audit on this page →

Eden Token EDEN
0x24a3…0035
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The Eden token contract, implemented as an upgradeable ERC-20 token using OpenZeppelin's UUPS proxy pattern and AccessControl, exhibits a robust architectural foundation. However, the high degree of centralized control over critical functions like minting, burning, and upgrades by a single administrative role presents a significant single point of failure. The absence of a timelock for these sensitive operations further amplifies this risk, warranting careful consideration for enhanced security measures.

1 High1 Medium1 Low1 Informational
Volume 24h
$61.1K
Liquidity
$624.8K
Price
$0.06183
Token Age
10mo
Top 10 Holders
88.0%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control and Single Point of Failure

H-01The `DEFAULT_ADMIN_ROLE` (initially assigned to a single `_admin` address) has ultimate control over all other roles, including `MINTER_ROLE`, `BURNER_ROLE`, and `UPGRADE_ROLE`. This creates a single point of failure where a compromise of this admin key could lead to arbitrary token minting/burning, and malicious contract upgrades, severely impacting the protocol's integrity and user funds. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
IssueThe `DEFAULT_ADMIN_ROLE` (initially assigned to a single `_admin` address) has ultimate control over all other roles, including `MINTER_ROLE`, `BURNER_ROLE`, and `UPGRADE_ROLE`. This creates a single point of failure where a compromise of this admin key could lead to arbitrary token minting/burning, and malicious contract upgrades, severely impacting the protocol's integrity and user funds. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `DEFAULT_ADMIN_ROLE` and other critical roles to require multiple approvals for sensitive operations. Consider distributing roles among multiple trusted entities to reduce the risk associated with a single compromised key.
StatusUnresolved
Medium

Absence of Timelock for Critical Operations

M-01The contract lacks a timelock mechanism for critical administrative actions such as role management (granting/revoking `MINTER_ROLE`, `BURNER_ROLE`, `UPGRADE_ROLE`) and contract upgrades. This means that any authorized but compromised account could execute malicious operations instantly, leaving no time for detection or community intervention. (7.3 Access Control, 7.5 Governance, 7.8 Operations)
IssueThe contract lacks a timelock mechanism for critical administrative actions such as role management (granting/revoking `MINTER_ROLE`, `BURNER_ROLE`, `UPGRADE_ROLE`) and contract upgrades. This means that any authorized but compromised account could execute malicious operations instantly, leaving no time for detection or community intervention. (7.3 Access Control, 7.5 Governance, 7.8 Operations)
FixIntegrate a timelock contract (e.g., OpenZeppelin's `TimelockController`) for all sensitive administrative operations. This would introduce a delay between the proposal and execution of critical actions, allowing time for monitoring and potential intervention.
StatusUnresolved
Low

Reliance on External OpenZeppelin Contracts

L-01The contract heavily relies on OpenZeppelin's upgradeable contracts (`AccessControlUpgradeable`, `ERC20Upgradeable`, `UUPSUpgradeable`). While these libraries are well-audited and widely used, any undiscovered vulnerability in these external dependencies could directly impact the security of the `Eden` contract. (7.6 External)
IssueThe contract heavily relies on OpenZeppelin's upgradeable contracts (`AccessControlUpgradeable`, `ERC20Upgradeable`, `UUPSUpgradeable`). While these libraries are well-audited and widely used, any undiscovered vulnerability in these external dependencies could directly impact the security of the `Eden` contract. (7.6 External)
FixWhile OpenZeppelin contracts are considered industry standard, it is prudent to stay informed about any security advisories or updates related to these libraries. Regularly review and update dependencies to their latest secure versions.
StatusUnresolved
Info

No Pause Mechanism

I-01The contract does not include a pause mechanism (e.g., `PausableUpgradeable`). In the event of an emergency or discovery of a critical vulnerability, there is no immediate way to halt operations like minting, burning, or transfers, which could exacerbate potential damage. (7.8 Operations)
IssueThe contract does not include a pause mechanism (e.g., `PausableUpgradeable`). In the event of an emergency or discovery of a critical vulnerability, there is no immediate way to halt operations like minting, burning, or transfers, which could exacerbate potential damage. (7.8 Operations)
FixConsider integrating OpenZeppelin's `PausableUpgradeable` module to provide an emergency pause functionality. This would allow authorized roles to temporarily halt critical operations in case of an exploit or unforeseen issue, limiting potential damage.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract leverages battle-tested OpenZeppelin libraries for ERC-20, AccessControl, and UUPS upgradeability, ensuring a solid technical foundation (7.1 Architecture, 7.2 Code Security). The implementation of `_authorizeUpgrade` correctly restricts upgrade permissions to the `UPGRADE_ROLE` (7.3 Access Control). However, the highly centralized control structure, where a single `DEFAULT_ADMIN_ROLE` can manage all other critical roles, including those for minting, burning, and upgrades, introduces a significant technical risk (7.3 Access Control).

GovernanceHigh1/10

The economic model is a standard ERC-20 token with controlled minting and burning capabilities (7.4 Economic). Governance is highly centralized, relying solely on role-based access control where a single `DEFAULT_ADMIN_ROLE` can grant or revoke all other critical roles, including `MINTER_ROLE` and `BURNER_ROLE` (7.5 Governance). This concentration of power creates a substantial economic risk, as a compromised admin key could lead to arbitrary supply manipulation.

UpgradesHigh1/10

The contract correctly implements the UUPS upgradeability pattern using OpenZeppelin's `UUPSUpgradeable` module, allowing for future enhancements and bug fixes (7.7 Upgrades). The `_authorizeUpgrade` function is properly overridden and secured by the `UPGRADE_ROLE`, ensuring that only authorized entities can initiate upgrades (7.3 Access Control). However, the `DEFAULT_ADMIN_ROLE` ultimately controls the `UPGRADE_ROLE`, meaning a single point of failure exists for upgrade permissions, posing a risk if the admin key is compromised.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

88.0% in top 10
66.9% in wallets21.0% in contracts
Effective Concentration75.4%

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

$624.9K across 2 pairs
Uniswap v4USDTanalysed$624.8K100.0%Uniswap v4USDT$150.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 Holder87.0%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xb09f…19bc
Unlocked LP Held By
0xfd59…a7450x4208…e0bd0xd2b2…11ed

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

What Raised This Score

10 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (88.0% total → 75.4% effective; 66.9% in EOAs, 21.0% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 87.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 1 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
ZK Coin (ZKC)Critical RiskGensyn (AI)Critical RiskRe Protocol reUSD (REUSD)Critical RiskCOTICritical Riskdmt-natCritical RiskAllora (ALLO)Critical Risk

Would You Like a More Detailed Audit of Eden Token?

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

Get Detailed Audit