Is Euler (EUL) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med2 Info

High

Centralized Control of Administrative Roles

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

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

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

StatusUnresolved

Medium

Lack of Safe `DEFAULT_ADMIN_ROLE` Transfer Mechanism

M-01The 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,…

IssueThe 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,…

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

StatusUnresolved

Info

Inflationary Tokenomics

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

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

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

StatusUnresolved

Info

Absence of Emergency Pause Functionality

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow7/10

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

GovernanceHigh1/10

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

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

57.7% in top 10

35.5% in wallets22.2% in contracts

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

$1.98M across 5 pairs

Uniswap v4ETHanalysed$1.08M Uniswap v4USDC$874.6K Uniswap v3WETH$18.3K Uniswap v2WETH$6.6K BalancerWETH$3.4K

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 Holder96.0%

Top-3 Unlocked100.0%

Key Addresses

8 addresses

Deployer

0xee00…c8c5

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.

What Raised This Score

8 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

Is Euler Safe?

Security Findings

Centralized Control of Administrative Roles

Lack of Safe `DEFAULT_ADMIN_ROLE` Transfer Mechanism

Inflationary Tokenomics

Absence of Emergency Pause Functionality

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of Euler?