Quantum Audit Logo

Is Ethena Safe?

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

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

Ethena ENA
0x57e1…6061
Ethereum
Not verifiedThis 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 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High2 Medium1 Low3 Informational
Volume 24h
$569.9K
Liquidity
$781.6K
Price
$0.1672
Token Age
1y
Top 10 Holders
60.7%

Security Findings

1 High2 Med1 Low3 Info
High

Centralized Minting Authority

H-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Medium

Reliance on `block.timestamp` for Critical Cooldown

M-01The `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.
IssueThe `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.
FixFor 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.
StatusUnresolved
Medium

Significant Initial Supply Distribution to Specific Addresses

M-02The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Low

Inflexible Inflation Rate

L-01The `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.
IssueThe `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.
FixThis 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.
StatusUnresolved
Info

Efficient `uint40` Usage for Timestamp

I-01The `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.
IssueThe `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.
FixNo action required. This is a good practice for gas optimization.
StatusResolved
Info

Robust Ownership Transfer Mechanism

I-02The 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.
IssueThe 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.
FixNo action required. This is a good security practice.
StatusResolved
Info

Prevention of Ownership Renunciation

I-03The `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.
IssueThe `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.
FixNo action required. This is a good security practice.
StatusResolved

Category Ratings

TechnicalLow7/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 preventing ownership renunciation. However, the reliance on `block.timestamp` for the yearly minting cooldown (7.2) introduces a minor, though generally acceptable for long periods, dependency on miner-controlled values. The use of `uint40` for `lastMintTimestamp` is an efficient gas optimization.

GovernanceMedium4/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 misused. Furthermore, a substantial initial supply of 15 billion tokens is minted to specific treasury and foundation addresses in the constructor, making the security of these addresses paramount (7.8). While the `MAX_INFLATION` is a fixed constant, providing predictability, it also removes flexibility for future economic adjustments.

UpgradesMedium5/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 vulnerabilities or desired feature changes would require a new contract deployment and token migration.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

60.7% in top 10
44.3% in wallets16.4% in contracts
Effective Concentration50.9%

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.43M across 11 pairs
Uniswap v3WETHanalysed$781.6K54.8%Uniswap v4USDC$495.3K34.7%Uniswap v4ETH$83.0K5.8%Uniswap v3WETH$30.7K2.1%Uniswap v4USDT$23.9K1.7%Uniswap v4USDC$8.7K0.6%
Show 4 more pairsShow less
Uniswap v3WETH$2.1K0.2%Pancakeswap v3WETH$1.1K0.1%Uniswap v4USDT$4240.0%SupernovaWETH$1020.0%

One more pair holds $34 and is not listed.

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 Holder47.6%
Top-3 Unlocked66.2%

Key Addresses

11 addresses
Deployer
0x32a1…77de
Unlocked LP Held By
0x00bd…c55c0x64cd…876e0x984a…c6710xab32…b6ea0xa46a…8f820x339e…1cd90x2832…9f4c0xf8d0…dd0c0x4f04…42ff0x6788…8001

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

What Raised This Score

7 factors
  • Ownership NOT renounced — Timelock 24h delay
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (60.7% total → 50.9% effective; 44.3% in EOAs, 16.4% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 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

Related Audits

6 more on the record
EigenCloud (prev. EigenLayer) (EIGEN)High RiskYield Basis (YB)High RiskOlympus (OHM)High RiskFabric Protocol (ROBO)High RiskUSDeHigh RiskVirtuals Protocol (VIRTUAL)High Risk

Would You Like a More Detailed Audit of Ethena?

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

Get Detailed Audit