Ethena ENA

Claim: No cryptographic inventory has been published by Ethena Labs. Third-party assessments (EternaX April 2026, Google Quantum AI March 2026, BMIC April 2026) document ECDSA secp256k1 as the exclusive signature scheme for ENA token transactions, admin multisigs, and protocol operations.

Coverage basis: Third-party research reports document the cryptographic surface. ENA token contract is verified on Etherscan confirming standard ERC-20 implementation with no custom cryptography.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No project-published cryptographic inventory exists

Assurance: Third-party inventories are credible and consistent but do not substitute for a project-published assessment. The cryptographic surface is publicly verifiable from Etherscan and GitHub.

Ethena Labs has not acknowledged quantum risk in any official documentation, blog post, or roadmap. All quantum vulnerability documentation comes from independent researchers.

• https://eternax.ai
• https://arxiv.org
• https://bmic.ai
• https://etherscan.io/token/0x57e114b691db790c35207b2e685d4a43181e6061
• https://docs.ethena.fi/solution-design/key-addresses
• https://docs.ethena.fi/solution-design/overview/github-overview

Claim: Source code is open-source (GitHub) and verified on Etherscan. Classical security audits exist. Third-party quantum vulnerability research provides evidence record, but Ethena Labs has published no quantum-specific evidence.

Coverage basis: Open-source repositories at github.com/ethena-labs, verified contracts on Etherscan, published classical audits, and independent quantum research papers.

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Code and audits are publicly available. Evidence of quantum vulnerability is well-documented by third parties but no project-published quantum risk assessment exists.

The evidence record for quantum vulnerability is comprehensive from external sources but entirely absent from Ethena's own publications.

• https://github.com/ethena-labs
• https://etherscan.io/token/0x57e114b691db790c35207b2e685d4a43181e6061
• https://docs.ethena.fi/resources/audits
• https://code4rena.com/audits/2024-11-ethena-labs-invitational

Claim: All ENA token transactions use standard Ethereum ECDSA secp256k1 signatures. No PQC or hybrid-PQC signature support exists on mainnet or any testnet.

Coverage basis: ENA is an ERC-20 token on Ethereum. Transaction authorization inherits Ethereum's ECDSA account model. Verified via Etherscan contract code and on-chain transaction analysis.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All spend authorization is ECDSA secp256k1-only with no PQC or hybrid-PQC path

Assurance: High confidence: on-chain evidence is definitive. ECDSA-only status is confirmed by multiple independent sources.

Every ENA token transfer requires an ECDSA signature. For any Ethereum EOA that has broadcast a transaction, the secp256k1 public key is permanently exposed on-chain and harvestable for future quantum attack.

• https://etherscan.io/token/0x57e114b691db790c35207b2e685d4a43181e6061
• https://eternax.ai
• https://arxiv.org
• https://bmic.ai

Claim: ENA uses standard Ethereum EOA accounts. Public keys are exposed on first transaction broadcast. No address rotation, PQ-safe key derivation, or hybrid controls exist.

Coverage basis: Standard Ethereum account model. ENA token does not introduce custom address schemes or key derivation.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Long-exposure public keys for all transacted EOA accounts with no migration or rotation path

Assurance: Standard Ethereum EOA exposure model. BMIC analysis confirms that every ENA wallet that has broadcast a transaction has an exposed public key.

Accounts that have only received ENA and never sent a transaction have not exposed their public key (only the keccak256 address hash is visible), providing partial protection. However, admin multisig signers have all transacted and have exposed keys.

• https://etherscan.io/token/0x57e114b691db790c35207b2e685d4a43181e6061
• https://bmic.ai

Claim: ENA is an ERC-20 token without an independent consensus mechanism. Consensus authentication is handled by Ethereum L1.

Coverage basis: Token-only scope. No validator signatures, VRFs, randomness beacons, or block certification exist at the token level.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: ENA token state integrity is managed by Ethereum L1. No independent commitments, nullifiers, accumulators, or data-availability mechanisms exist at the token level.

Coverage basis: Standard ERC-20 token. State (balances, allowances) is maintained by the Ethereum EVM.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: ENA has no privacy layer, ZK proof system, shielded transactions, note encryption, viewing keys, or stealth addresses.

Coverage basis: Standard transparent ERC-20 token with no privacy features.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: ENA is a token, not a P2P network. No independent node identity or peer authentication exists.

Coverage basis: Token-only scope.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: Ethena protocol admin multisigs (Gnosis Safe, 5/11 and 7/10 signers) use standard Ethereum ECDSA accounts. OES custody (Copper, Fireblocks) uses MPC/multisig with presumed ECDSA/EdDSA key material. MINTER_ROLE and REDEEMER_ROLE are EOA hot wallets. No PQ/hybrid support exists in any critical wallet or custody workflow.

Coverage basis: Official documentation at docs.ethena.fi, GitHub repositories, on-chain multisig addresses, and third-party research (Google Quantum AI, BCAS audit).

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All admin multisigs, OES custody, minter/redeemer keys are ECDSA-based with exposed public keys and no PQ migration path

Assurance: Admin multisig addresses and configurations are publicly documented. The Google Quantum AI paper (March 2026) explicitly identifies Ethena USDe admin keys as quantum-vulnerable. OES custody provider MPC implementations are not independently auditable for quantum resistance.

The 5/11 dev multisig (0x3b0aaf6e6fcd4a7ceef8c92c32dfea9e64dc1862) owns Ethena's deployed mainnet smart contracts. The 7/10 protocol multisig holds ownership of core contracts. All signers use standard Ethereum ECDSA accounts. GATEKEEPER_ROLE addresses are also EOA-based and have transacted, exposing their public keys.

• https://docs.ethena.fi/solution-design/key-addresses
• https://docs.ethena.fi/solution-design/key-trust-assumptions
• https://docs.ethena.fi/solution-design/overview/github-overview
• https://etherscan.io/address/0x3b0aaf6e6fcd4a7ceef8c92c32dfea9e64dc1862
• https://bcas.io
• https://arxiv.org

Claim: 0% of ENA and USDe value is protected from quantum key-recovery attacks. All value resides in ECDSA-secured accounts or admin-controlled contracts with no PQC migration.

Coverage basis: ENA token market cap and USDe stablecoin supply (~$3B+) are entirely on ECDSA-secured infrastructure. No migration has occurred. Coverage is <25%, corresponding to score 1 of 20 (implementation score 0.05).

Implementation score: 0.05 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: 100% of protocol value-at-risk is quantum-vulnerable with no migration path

Assurance: Value-at-risk figures from third-party sources (EternaX: $5.9B total; StablePQC: ~$3B USDe admin-governed). Exact vulnerable value requires on-chain analytics beyond current evidence scope. Confidence capped at Medium due to reliance on third-party estimates rather than protocol-published data.

ENA governance token market cap fluctuates. USDe is the primary economic asset at ~$3B+. Admin key compromise would affect both. Coverage is effectively 0% — no migration, no PQ protection, no freeze/deprecation policy for vulnerable accounts.

• https://eternax.ai
• https://arxiv.org
• https://bmic.ai

Claim: No critical wallets (admin multisigs, OES custody, minter/redeemer hot wallets, treasury, foundation) have been migrated to PQC or are inherently PQ-native. All use standard ECDSA.

Coverage basis: Official key address documentation and on-chain verification of multisig addresses.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: All critical wallets remain ECDSA-only with no migration or PQ-native path

Assurance: Admin multisig addresses are publicly documented and their ECDSA nature is verifiable from Ethereum's account model. OES custody provider key configurations are not publicly auditable.

The dev multisig (5/11, 0x3b0aaf...) controls contract upgrades and parameter changes. The protocol multisig (7/10) controls ownership. Reserve fund (4/10, 0x2b5ab...) holds protocol funds. None have PQ protection.

• https://docs.ethena.fi/solution-design/key-addresses
• https://docs.ethena.fi/solution-design/key-trust-assumptions
• https://etherscan.io/address/0x3b0aaf6e6fcd4a7ceef8c92c32dfea9e64dc1862

Claim: No identification, measurement, deprecation, migration, freeze, or burn program exists for quantum-vulnerable ENA/USDe accounts or admin keys.

Coverage basis: Absence of any such program in Ethena documentation, GitHub, or public communications.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No legacy vulnerable account identification or deprecation program exists

Assurance: No evidence found of any program to identify, measure, or address quantum-vulnerable accounts. Medium confidence reflects the possibility of unannounced internal work.

Unlike Bitcoin's BIP-360 or Ethereum's planned EIP-8141 account abstraction migration, Ethena has no mechanism for users to migrate to PQ-safe accounts independently of Ethereum L1.

Claim: No public migration roadmap, PQC upgrade plan, sequencing, activation criteria, or dependencies have been published by Ethena Labs.

Coverage basis: Comprehensive review of Ethena documentation, GitHub, blog posts, and governance forum reveals no quantum-related planning.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No migration roadmap exists

Assurance: Medium confidence: no public roadmap found. Possibility of unannounced internal planning cannot be excluded but has no QRI weight without public evidence.

Ethena's dependency on Ethereum L1's ~2029 PQC timeline means token-specific migration would likely need to follow or coordinate with Ethereum's account abstraction upgrades (EIP-8141). No such coordination is evidenced.

• https://docs.ethena.fi/
• https://github.com/ethena-labs
• https://gov.ethenafoundation.com/

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, or migration prompts exist for ENA holders or protocol operators.

Coverage basis: Absence of any such tooling or documentation in Ethena's public resources.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No migration tooling, wallet support, or user-facing migration path exists

Assurance: High confidence: comprehensive absence of any PQ migration tooling across all public Ethena resources.

Ethena's mint/redeem flow uses EIP-712 signatures verified via ecrecover, which is ECDSA-based. Migration would require fundamental changes to this architecture.

• https://docs.ethena.fi/
• https://github.com/ethena-labs

Claim: No enforcement mechanisms exist (deprecation, freeze, disabled legacy signing, restricted withdrawals, unsafe-path blocking, mandatory migration deadlines). No exchange, custody, bridge, wallet, or infrastructure coordination for quantum migration is evidenced.

Coverage basis: Absence of any such mechanisms or coordination in public documentation or on-chain governance.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No migration enforcement or ecosystem coordination mechanisms exist

Assurance: Medium confidence: no public coordination found. Ethena has relationships with exchanges and custodians (Copper, Fireblocks) that could facilitate future coordination, but no quantum-specific coordination is evidenced.

Ethena's GATEKEEPER_ROLE provides classical pause capability but has no quantum-specific function. The 7-day time-locked multisig governance could theoretically coordinate a migration but no plan exists.

Claim: No quantum-specific emergency disclosure or incident-response process exists. Ethena has a general Immunefi bug bounty program and classical security processes but nothing addressing quantum vulnerability disclosure or response.

Coverage basis: Immunefi bug bounty page and Ethena documentation show classical security processes only.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: General security infrastructure exists (bug bounty, multisig governance, GATEKEEPER_ROLE pause mechanism) but none is quantum-specific. This is an assurance gap rather than a direct quantum-critical vulnerability in the current production system.

Ethena's GATEKEEPER_ROLE and time-locked multisig provide classical incident response capability that could theoretically be used during a quantum emergency, but no quantum-specific procedures, thresholds, or communication plans exist.

• https://immunefi.com/bug-bounty/ethena/information/
• https://docs.ethena.fi/solution-design/key-trust-assumptions

Claim: Ethena uses no PQC algorithms. All cryptography is classical ECDSA secp256k1 and Keccak-256.

Coverage basis: Verified contract code on Etherscan and GitHub repositories confirm no PQC library usage.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No NIST-standardized or reviewed PQC algorithms in use

Assurance: High confidence. Verified contract code shows only standard OpenZeppelin libraries with no PQC imports or custom cryptography.

NIST finalized PQC standards (ML-KEM FIPS 203, ML-DSA FIPS 204, SLH-DSA FIPS 205) in August 2024. Ethena has adopted none of these.

• https://etherscan.io/token/0x57e114b691db790c35207b2e685d4a43181e6061
• https://github.com/ethena-labs

Claim: Multiple classical smart-contract security audits exist (Zellic, Quantstamp, Spearbit, Pashov, Code4rena, Cyfrin, Chaos Labs) from 2023-2024, but none include quantum or PQC scope. No quantum-focused audit exists.

Coverage basis: Audit reports published at docs.ethena.fi/resources/audits and in GitHub repositories.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: Classical audits verify smart contract correctness but are quantum-scope-mismatched. No auditor has evaluated Ethena's cryptography for quantum resistance. Audits are stale (2023-2024) relative to 2026 evaluation but remain relevant for classical implementation correctness.

The audit gap is material: no independent reviewer has assessed whether Ethena's admin key architecture, multisig configuration, or custody routing would survive a quantum-capable adversary. This is an assurance-only caveat because the quantum vulnerability (ECDSA-only) is independently verifiable from public code and on-chain evidence.

• https://docs.ethena.fi/resources/audits
• https://github.com/code-423n4/2023-10-ethena
• https://code4rena.com/audits/2024-11-ethena-labs-invitational

Claim: ENA token contract and core protocol contracts are open-source and verified on Etherscan with exact match to published source code. Reproducible builds are possible.

Coverage basis: Verified contract source on Etherscan, public GitHub repositories.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Full score. Source code is publicly available and verified. The implementation is standard OpenZeppelin with no obfuscation.

Open-source code is a necessary but insufficient condition for quantum readiness. It enables independent verification of the ECDSA-only status.

• https://etherscan.io/token/0x57e114b691db790c35207b2e685d4a43181e6061
• https://github.com/ethena-labs

Claim: No documented cryptographic parameter agility or upgrade path exists. The ENA token contract has no mechanism for signature algorithm migration. Protocol contracts use immutable cryptographic assumptions.

Coverage basis: Contract code shows no parameterization of signature algorithms or cryptographic agility features.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: The ENA token uses standard ERC-20 with no signature verification at the token level (signatures are at the Ethereum L1 transaction layer). Future Ethereum account abstraction (EIP-8141) could provide migration path but Ethena has not documented how it would leverage this.

Protocol admin multisigs and OES custody would require independent migration outside Ethereum's L1 upgrade path. No agility features exist for these off-chain or contract-level keys.

• https://etherscan.io/token/0x57e114b691db790c35207b2e685d4a43181e6061
• https://docs.ethena.fi/solution-design/overview/github-overview

Claim: No stateful PQC signatures (XMSS/LMS) are in use. This subfactor is not applicable to the current ECDSA-only production system.

Coverage basis: ECDSA is stateless. Stateful signature considerations only apply when XMSS/LMS-style schemes are deployed.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Claim: No performance or resource-impact analysis exists for PQC deployment in the Ethena protocol context.

Coverage basis: No such analysis found in any Ethena documentation or research publications.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Performance analysis would be relevant once a PQC migration path is proposed. Its absence does not independently reduce the QRI Score since no PQC deployment exists to analyze. This is a forward-looking assurance gap.

PQC signatures (ML-DSA: ~2.4KB, SLH-DSA: larger) would impact Ethereum gas costs for admin multisig transactions. No analysis of how this would affect Ethena's mint/redeem throughput or operational costs exists.