Quantum Audit Logo
Launch App

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

Is Euler Safe?

EULEthereum
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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 High · 1 Medium · 2 Info4
SummaryAI Copilot

The Eul contract implements an ERC20 token with voting capabilities and a controlled minting mechanism.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (57.7% total → 44.4% effective; 35.5% in EOAs, 22.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.0% (independent LP — depth risk, pool = 54% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 54% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
22.2%Contracts35.5%Wallets42.3%Everyone else
22.2%Contracts35.5%Wallets42.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
57.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking22.2%
  • Walletsanonymous holders, free to sell35.5%
  • Everyone elsethe rest of the supply42.3%
Effective concentrationwhat the score reads44.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$1.98M across 5 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$1.08MShare of depth54.5%
Top-1 Unlocked Holder96.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x74a0…50960xd82f…e9620x51f1…21890xe8b6…f1e00xbabe…87b60x1ed4…01620x1a8e…15d0

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

Security Findings

1 High1 Medium2 Info
High

Centralized Control of Administrative Roles

The contract's constructor assigns both the DEFAULT_ADMIN_ROLE and the ADMIN_ROLE to the treasury_ address. This design centralizes significant power, including the ability to mint new tokens, update the treasury address, and manage all other roles (grant/revoke), to a single entity. If the treasury address is a single EOA (Externally Owned Account), it represents a single point of failure, making the system vulnerable to compromise of that key or malicious actions by its holder. (7.3 Access Control, 7.5 Governance)H-01

Issue

The contract's constructor assigns both the DEFAULT_ADMIN_ROLE and the ADMIN_ROLE to the treasury_ address. This design centralizes significant power, including the ability to mint new tokens, update the treasury address, and manage all other roles (grant/revoke), to a single entity. If the treasury address is a single EOA (Externally Owned Account), it represents a single point of failure, making the system vulnerable to compromise of that key or malicious actions by its holder. (7.3 Access Control, 7.5 Governance)

Fix

It is highly recommended to assign the DEFAULT_ADMIN_ROLE and ADMIN_ROLE to a robust multi-signature wallet or a DAO governance contract. This distributes control and requires multiple approvals for critical operations, significantly reducing the risk associated with a single point of failure.

Status

Unresolved

Medium

Lack of Safe DEFAULT_ADMIN_ROLE Transfer Mechanism

The contract, while using OpenZeppelin's AccessControl, does not implement a specific, multi-step mechanism for safely transferring the DEFAULT_ADMIN_ROLE to a new entity. The DEFAULT_ADMIN_ROLE is its own administrator, meaning its management is critical. A direct grantRole followed by revokeRole or renounceRole by the old admin carries inherent risks, such as the old admin failing to revoke/renounce or a new admin not being able to take over if the transaction fails. If the initial treasury address (holding DEFAULT_ADMIN_ROLE) is compromised or becomes inaccessible, the ultimate administrative control of the system could be lost or become unrecoverable. (7.3 Access Control,…M-01

Issue

The contract, while using OpenZeppelin's AccessControl, does not implement a specific, multi-step mechanism for safely transferring the DEFAULT_ADMIN_ROLE to a new entity. The DEFAULT_ADMIN_ROLE is its own administrator, meaning its management is critical. A direct grantRole followed by revokeRole or renounceRole by the old admin carries inherent risks, such as the old admin failing to revoke/renounce or a new admin not being able to take over if the transaction fails. If the initial treasury address (holding DEFAULT_ADMIN_ROLE) is compromised or becomes inaccessible, the ultimate administrative control of the system could be lost or become unrecoverable. (7.3 Access Control,…

Fix

Implement a dedicated, multi-step transfer mechanism for the DEFAULT_ADMIN_ROLE. This typically involves a proposeNewAdmin function, followed by an acceptNewAdmin function from the proposed address, ensuring a secure and deliberate transfer of control. This pattern prevents accidental loss of administrative privileges.

Status

Unresolved

Info

Inflationary Tokenomics

The token design includes an annual minting mechanism, allowing the ADMIN_ROLE to mint new tokens equivalent to 2.718% of the current total supply. This is an intentional economic model that results in a continuously increasing total supply. While this is a design choice and not a vulnerability, it's important for users and stakeholders to be aware of the inflationary nature of the token and its potential impact on token value over time. (7.4 Economic)I-01

Issue

The token design includes an annual minting mechanism, allowing the ADMIN_ROLE to mint new tokens equivalent to 2.718% of the current total supply. This is an intentional economic model that results in a continuously increasing total supply. While this is a design choice and not a vulnerability, it's important for users and stakeholders to be aware of the inflationary nature of the token and its potential impact on token value over time. (7.4 Economic)

Fix

Ensure that the inflationary model is clearly communicated in all project documentation, whitepapers, and user interfaces. Transparency regarding tokenomics helps manage user expectations and provides a complete picture of the token's economic design.

Status

Unresolved

Info

Absence of Emergency Pause Functionality

The contract lacks an emergency pause mechanism. In the event of a critical vulnerability discovery, a major market exploit, or other unforeseen circumstances, the ability to temporarily halt critical operations (like minting or transfers) can be crucial for mitigating damage and allowing time for a resolution. Without such a mechanism, the protocol might be exposed to prolonged risk during an incident. (7.2 Code Security, 7.8 Operations)I-02

Issue

The contract lacks an emergency pause mechanism. In the event of a critical vulnerability discovery, a major market exploit, or other unforeseen circumstances, the ability to temporarily halt critical operations (like minting or transfers) can be crucial for mitigating damage and allowing time for a resolution. Without such a mechanism, the protocol might be exposed to prolonged risk during an incident. (7.2 Code Security, 7.8 Operations)

Fix

Consider integrating a pause mechanism (e.g., using OpenZeppelin's Pausable contract) that can be triggered by the DEFAULT_ADMIN_ROLE or a designated emergency multisig. This would provide a safety switch to protect users and the protocol during critical events.

Status

Unresolved

Analysis

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

The Eul contract implements an ERC20 token with voting capabilities and a controlled minting mechanism. The contract leverages OpenZeppelin's battle-tested AccessControl and ERC20Votes libraries, contributing to a solid technical foundation. However, the initial setup centralizes significant administrative power to a single 'treasury' address, posing a single point of failure. Additionally, the contract lacks a robust mechanism for safely transferring the ultimate administrative role and does not include an emergency pause functionality. The token's inherent inflationary model is an important economic consideration.

Technical7/10Low risk

The technical implementation of the Eul token is robust, utilizing OpenZeppelin's ERC20Votes and AccessControl for standard and secure functionalities (7.2 Code Security). The Solidity version 0.8.0+ inherently protects against integer overflow/underflow. The minting logic is straightforward, calculating a percentage of total supply and updating the next minting timestamp (7.1 Architecture). However, the contract lacks an emergency pause mechanism, which could be a valuable safety feature in unforeseen circumstances (7.2 Code Security).

Governance1/10High risk

The contract's governance model, based on AccessControl, initially centralizes significant power. The constructor assigns both the DEFAULT_ADMIN_ROLE and ADMIN_ROLE to a single treasury address, making it a single point of failure for minting and role management (7.3 Access Control, 7.5 Governance). While the ERC20Votes extension provides a foundation for decentralized governance, the current administrative setup is highly centralized. Economically, the token features an annual minting mechanism, increasing the total supply by 2.718% (7.4 Economic).

Upgrades3/10High risk

The Eul contract is implemented as a standard, non-upgradeable contract. It does not utilize any proxy patterns (e.g., UUPS, Transparent, Beacon) (7.7 Upgrades). Therefore, there are no upgrade-related risks such as proxy initialization flaws, storage collisions, or logic errors during an upgrade. Any changes to the contract's logic would require a new deployment and migration of assets.

Final RecommendationWhat to do about this score

It is strongly recommended to secure the treasury address with a robust multi-signature wallet or a well-governed DAO contract to mitigate the single point of failure identified.

Consider implementing a multi-step process for transferring the DEFAULT_ADMIN_ROLE to ensure a safe transition of ultimate administrative control. Additionally, evaluate the benefits of adding an emergency pause mechanism to provide a safety net for critical situations.

Contract & Record

2 audits on record
TypeVault, Token
NetworkEthereum
Token age9mo
Contract0xd9fc…e07b
Deployer0xee00…c8c5
Badge for your website
Euler 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. Sep 4, 202655Medium
  2. Jul 27, 202654Medium
  3. Jul 26, 202689Critical

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

Frequently Asked Questions

Is Euler a scam?

Based on automated analysis, Euler scores 89/100 (Critical Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Euler safe to buy?

Our scanner flagged a risk score of 89/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Euler been audited?

The contract is open-source and verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
Helix TokenHLX · Ethereum55MediumQuantQNT · Ethereum55MediumNeuralAINEURAL · Ethereum55MediumPepeCatPCAT · Ethereum55MediumMilady Cult CoinCULT · Ethereum55MediumcheqdCHEQ · Ethereum55Medium

Would You Like a More Detailed Audit of Euler?

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