Quantum Audit Logo
Launch App

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

Is Eden Token Safe?

EDENEthereum
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
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
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.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 87.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
21.0%Contracts66.9%Wallets12.0%Everyone else
21.0%Contracts66.9%Wallets12.0%
ContractsWalletsEveryone elseBubble area = share of supply
88.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking21.0%
  • Walletsanonymous holders, free to sell66.9%
  • Everyone elsethe rest of the supply12.0%
Effective concentrationwhat the score reads75.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$624.9K across 2 pairs

The risk score reads depth across every pair.

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$624.8KShare of depth100.0%
Top-1 Unlocked Holder87.0%
Top-3 Unlocked100.0%
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.

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control and Single Point of Failure

The 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)H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Absence of Timelock for Critical Operations

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

Issue

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

Fix

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

Status

Unresolved

Low

Reliance on External OpenZeppelin Contracts

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

Issue

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

Fix

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

Status

Unresolved

Info

No Pause Mechanism

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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

Governance1/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to decentralize control over critical roles, particularly the DEFAULT_ADMIN_ROLE, by implementing a multi-signature wallet or a robust governance mechanism.

Additionally, integrating a timelock for sensitive operations like role changes and contract upgrades would provide a crucial window for review and intervention, significantly mitigating the impact of potential compromises. Consider adding a pause mechanism for emergency situations.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age10mo
Contract0x24a3…0035
Deployer0xb09f…19bc
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Eden Token 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, 202685Critical

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

Related Audits

6 more on the recordAll audits
ZK CoinZKC · Ethereum85CriticalRender TokenRNDR · Ethereum85CriticalGensynAI · Ethereum86CriticalSparkSPK · Ethereum86CriticalCircle Wrapped BitcoinCIRBTC · Ethereum86CriticalapyUSDEthereum83High

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 Is this your token? Publish your own audit on this page