Is Ethena (ENA) Safe? Smart Contract Security Analysis

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2359

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

This report details the security audit of the ENA token contract, which serves as the governance token for the Ethena protocol. The contract is an ERC20 token with burnable and permit functionalities, inheriting from OpenZeppelin's Ownable2Step for robust access control. Key features include a controlled annual minting mechanism and a significant initial token distribution. The audit identified a High-severity issue related to centralized minting authority, two Medium-severity issues concerning initial supply distribution and reliance on block.timestamp, and several Low/Informational findings. The overall risk level is assessed as Medium, primarily due to the centralized control over token supply inflation.

Final Recommendation: It is recommended to implement robust multi-signature or time-locked controls for the contract owner address, especially given its centralized minting authority. This would significantly mitigate the risk associated with a single point of failure. Additionally, ensure that the `_treasury` and `_foundation` addresses receiving the initial token supply are secured with strong operational controls, preferably multi-signature wallets, to protect the substantial token holdings. While `block.timestamp` is generally acceptable for yearly cooldowns, consider the implications for any future time-sensitive operations.

Category Ratings

TechnicalLow

7/10

The ENA contract demonstrates good technical architecture (7.1) by extending well-audited OpenZeppelin libraries for ERC20, burnable, permit, and two-step ownership functionalities. Code security (7.2) is enhanced by using Solidity 0.8.20, which includes default overflow/underflow checks, and by pre

GovernanceHigh

2/10

The economic model (7.4) features a controlled inflation mechanism where the contract owner can mint new tokens annually, capped at 10% of the total supply. This centralized minting authority (7.5) grants significant power to a single entity, posing a risk if the owner's key is compromised or m

UpgradesMedium

5/10

The ENA token contract is not designed to be upgradeable (7.7). This means its logic is immutable once deployed, eliminating upgrade-related risks such as proxy implementation vulnerabilities or administrative key compromises during upgrades. However, it also means that any discovered vulnerabilitie

LP Distribution

Top-1 Unlocked Holder97.8%

Top-3 Unlocked99.9%

What Raised This Score

9 factors

Ownership NOT renounced — Timelock 24h delay
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 50% (60.0% total → 51.2% effective; 45.3% in EOAs, 14.6% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 97.8% (independent LP — depth risk, pool = 83% of DEX liquidity)
LP top3 unlocked holders = 99.9% (independent LP — depth risk, pool = 83% of DEX liquidity)
1 High finding(s) from audit
2 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 Findings

7 total

1 High 2 Medium 1 Low 3 Info

H-01HighUnresolved

Centralized Minting Authority

The `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This allows the owner to inflate the token supply annually up to `MAX_INFLATION` (10% of total supply). While limits are in place, this centralizes significant control over the token's economic policy in a single entity. A compromise of the owner's private key or malicious action by the owner could lead to uncontrolled inflation, devaluing the token.

Recommendation: Implement a robust multi-signature wallet or a decentralized autonomous organization (DAO) for the contract owner address. This would distribute control and require multiple approvals for critical operations like minting, significantly reducing the risk of a single point of failure or malicious unilateral action.

M-01MediumUnresolved

Reliance on `block.timestamp` for Critical Cooldown

The `MINT_WAIT_PERIOD` (365 days) relies on `block.timestamp` to enforce the yearly minting cooldown. While miner manipulation of `block.timestamp` is typically limited to small deviations to avoid network rejection, it is not entirely immune to manipulation. For a yearly cooldown, the impact is generally low, but it's a general pattern to be aware of for time-sensitive operations.

Recommendation: For a yearly cooldown, `block.timestamp` is often considered acceptable. However, for future critical time-sensitive operations, consider using a decentralized oracle service (e.g., Chainlink Keepers or a dedicated time oracle) to provide a more robust and less manipulable time source.

M-02MediumUnresolved

Significant Initial Supply Distribution to Specific Addresses

The constructor mints a substantial initial supply of 15 billion tokens to `_treasury` and `_foundation` addresses. The security and operational controls around these addresses are critical. If these are externally owned accounts (EOAs), they represent a single point of failure. If they are multi-signature wallets, their security depends on the configuration and key management practices.

Recommendation: Ensure that the `_treasury` and `_foundation` addresses are secured with robust operational controls, ideally multi-signature wallets with a sufficient number of signers and proper key management procedures. Regularly audit the security practices surrounding these critical addresses.

L-01LowUnresolved

Inflexible Inflation Rate

The `MAX_INFLATION` is defined as a `constant` (10%), meaning it cannot be modified after contract deployment. While this provides predictability for token holders, it removes the flexibility to adjust the inflation rate in response to future economic conditions or evolving protocol needs. This is a design choice that trades adaptability for certainty.

Recommendation: This is a design decision. If future flexibility is desired, consider making `MAX_INFLATION` a state variable that can be updated by the owner or a governance mechanism, potentially with a time-lock or multi-signature approval for changes.

I-01InformationalResolved

Efficient `uint40` Usage for Timestamp

The `lastMintTimestamp` variable is declared as `uint40`. This is an efficient use of storage compared to `uint256` for storing timestamps, as `uint40` is sufficient to store Unix timestamps for many centuries, leading to gas savings.

Recommendation: No action required. This is a good practice for gas optimization.

I-02InformationalResolved

Robust Ownership Transfer Mechanism

The contract utilizes OpenZeppelin's `Ownable2Step` for ownership transfers. This mechanism requires a two-step process (propose and accept), significantly reducing the risk of accidental ownership loss during transfer, which is a common vulnerability in `Ownable` contracts.

Recommendation: No action required. This is a good security practice.

I-03InformationalResolved

Prevention of Ownership Renunciation

The `renounceOwnership` function is explicitly overridden to revert, preventing the owner from accidentally or maliciously relinquishing control of the contract. This is a good security practice for contracts with critical owner-controlled functions.