Hyperliquid HYPE

Claim: Hyperliquid's public documentation describes its cryptographic primitives (ECDSA secp256k1 for transactions, BLS for validator signatures) across API docs, bridge docs, and staking docs, but the Hyperliquid Foundation has not published a formal cryptographic inventory or quantum threat model.

Coverage basis: Scattered public documentation identifies primitives but no single inventory or quantum risk assessment exists.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No public cryptographic inventory or quantum threat model published by the Hyperliquid Foundation.

Assurance: Third-party sources (Chainstack, qLABS QVS index, LayerQu) have independently documented Hyperliquid's cryptographic primitives. The project's own documentation describes ECDSA and BLS usage in passing but provides no consolidated inventory or quantum threat analysis.

Implementation Score 0.00 because no public inventory or quantum threat model exists, meeting the 'No implementation or no credible technical claim' threshold.

• https://docs.chainstack.com/docs/hyperliquid-authentication-guide
• https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/bridge
• https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/staking
• https://github.com/hyperliquid-dex/contracts/blob/master/Bridge2.sol
• https://qlabs.tech/blog/qlvi

Claim: Code repositories, API documentation, bridge contracts, and third-party analyses provide evidence of Hyperliquid's cryptographic design, but this evidence has not been compiled by the project into a quantum readiness assessment.

Coverage basis: Third-party and public code evidence exists but is not organized as a quantum assessment by the project.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Evidence exists (code, specs, audit reports) but the project has not assembled it into a quantum-specific evidence record. Confidence is Medium because primary sources are verifiable but scattered.

Implementation Score 0.00 for absence of project-published evidence record for quantum readiness.

• https://github.com/hyperliquid-dex
• https://github.com/hyperliquid-dex/contracts/blob/master/Bridge2.sol
• https://docs.chainstack.com/docs/hyperliquid-authentication-guide
• https://hyperliquid.gitbook.io/hyperliquid-docs/audits

Claim: All Hyperliquid transaction signatures use ECDSA secp256k1 via EIP-712 typed data signing. No PQC or hybrid-PQC path exists.

Coverage basis: ECDSA secp256k1 only; confirmed by Chainstack docs, SDK source code, and API specifications.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: ECDSA secp256k1 spend authorization is entirely quantum-vulnerable. Shor's algorithm recovers private keys from exposed public keys.

Assurance: Multiple independent primary sources confirm ECDSA-only signing. The Chainstack API documentation explicitly describes secp256k1 ECDSA signatures with r,s,v components. The Python SDK source code uses ecdsa.PrivateKey for signing.

This is the most critical quantum vulnerability. Every user transaction permanently exposes the signer's public key, enabling offline key recovery by a CRQC.

• https://docs.chainstack.com/docs/hyperliquid-authentication-guide
• https://docs.chainstack.com/api/hyperliquid/
• https://github.com/hyperliquid-dex
• https://docs.chainstack.com/reference/hyperliquid-exchange-c-signer-action

Claim: Hyperliquid uses EVM-style 20-byte hashed addresses. Public keys are revealed in the ECDSA signature of every transaction (r,s,v recovery), creating permanent long-exposure vulnerability.

Coverage basis: EVM-compatible address format; public key exposed on first spend. No PQ/hybrid controls exist.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: All accounts that have sent a transaction have permanently exposed public keys with no migration, freeze, or deprecation path.

Assurance: The qLABS QVS index independently confirms PKE=10 (maximum public key exposure score). Standard Ethereum-compatible wallets (MetaMask) are used, meaning public keys are derivable from every signed transaction.

This is a long-exposure (at-rest) attack surface. Unlike UTXO chains with fresh addresses per transaction, the account model means one spend permanently compromises the entire account history and future balance.

• https://docs.chainstack.com/docs/hyperliquid-authentication-guide
• https://docs.chainstack.com/api/hyperliquid/
• https://qlabs.tech/blog/qlvi

Claim: HyperBFT consensus uses BLS signatures for validator authentication, block certification, and round commitment. A 2/3 quorum of stake-weighted BLS signatures is required.

Coverage basis: BLS signature aggregation for validator consensus. Confirmed by bridge documentation, staking docs, Eco article, and Bridge2.sol contract.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: BLS validator signatures are vulnerable to Shor's algorithm. A quantum adversary can forge validator signatures to compromise consensus finality.

Assurance: The Eco article (May 2026) and bridge documentation explicitly describe BLS aggregation for validator signatures. The Bridge2.sol contract's checkValidatorSignatures function verifies ECDSA-recovered signers against a validator set, consistent with BLS-based L1 signing. No independent audit of consensus cryptography exists.

Triggers Readiness & Risk Cap: 'Consensus finality, validator authentication, randomness, or block certification remains quantum-vulnerable on a chain where that layer is applicable' → Max QRI 70.

• https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/bridge
• https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/staking
• https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/overview
• https://github.com/hyperliquid-dex/contracts/blob/master/Bridge2.sol

Claim: The Hyperliquid-Arbitrum bridge relies on BLS validator signatures for deposit crediting, withdrawal authorization, and validator set updates. Bridge verification is entirely dependent on quantum-vulnerable BLS signatures.

Coverage basis: BLS-based bridge verification. Confirmed by official bridge docs and Bridge2.sol source code.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: Bridge withdrawal authorization depends on BLS validator signatures. A quantum adversary can forge signatures to drain all bridged assets.

Assurance: The Zellic audit (August 2023) confirmed the bridge's reliance on 2/3 validator signatures but predates NIST PQC standardization and did not evaluate quantum threat models. The bridge architecture remains unchanged per May 2026 sources.

No KZG, pairing-based commitments, or other quantum-vulnerable state mechanisms beyond BLS signatures have been identified. HyperBFT state integrity is consensus-derived.

• https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/bridge
• https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/bridge2
• https://github.com/hyperliquid-dex/contracts/blob/master/Bridge2.sol
• https://www.scribd.com/document/683456789/2308-Hyperliquid-Zellic-Audit-Report

Claim: Hyperliquid does not implement privacy features, shielded pools, ZK proofs, or confidential transactions at the protocol level.

Coverage basis: No privacy layer exists in HyperCore or HyperEVM.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Correctly marked N/A. No privacy-specific quantum attack surface exists to evaluate.

• https://hyperliquid.gitbook.io/hyperliquid-docs

Claim: Hyperliquid's P2P networking layer cryptography is not publicly documented. Likely uses classical cryptography for node-to-node communication.

Coverage basis: No public documentation of P2P cryptography. Not independently verifiable.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: P2P cryptography is not documented. While P2P identity is not directly consensus, spend, bridge, or custody-critical in most BFT designs, the lack of documentation prevents verification. This is a minor concern relative to spend authorization and consensus vulnerabilities.

Even if P2P were quantum-safe, it would not mitigate the critical vulnerabilities in spend authorization and consensus layers. Score impact is minimal.

Claim: All wallet and custody workflows rely on standard ECDSA secp256k1 keys. Standard Ethereum-compatible wallets (MetaMask, hardware wallets) are used. No PQ wallet support exists.

Coverage basis: ECDSA-only wallet ecosystem. No PQ wallet, HSM, or custody path.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Standard ECDSA wallets are the only supported path. No PQ hardware wallet, HSM, or custody integration exists. This is a direct consequence of the ECDSA-only spend authorization layer.

Wallet/custody vulnerability is derivative of the spend authorization vulnerability scored above. No independent wallet-level quantum attack vector exists beyond the ECDSA dependency.

• https://docs.chainstack.com/docs/hyperliquid-authentication-guide
• https://github.com/hyperliquid-dex

Claim: 0% of value-at-risk is protected. All HYPE tokens (market cap approximately $10B as of early 2026), all bridged USDC, all open positions, and all staked assets are secured exclusively by quantum-vulnerable ECDSA and BLS cryptography.

Coverage basis: 0% protection. No PQ migration has occurred. No PQ-native asset exists at protocol level.

Implementation score: 0.05 · Evidence confidence: High

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

Quantum blocker: 100% of native HYPE value-at-risk and all bridged assets are quantum-vulnerable with zero migration coverage.

Assurance: The qLABS QVS index estimates HYPE market cap at ~$10B (EVR=4). No protected value exists. The qONE token is a separate application-layer asset and does not protect HYPE or bridged USDC.

Triggers Readiness & Risk Cap: 'Active production spend authorization remains entirely ECC/BLS/Schnorr/EdDSA-only' → Max QRI 40. Also triggers: 'Material long-exposure quantum-vulnerable value exists with no migration path' → Max QRI 55.

• https://qlabs.tech/blog/qlvi
• https://layerqu.com/chains/hyperliquid/

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) have been migrated to PQ protection. The Hyperliquid Foundation, validators, and all users rely exclusively on ECDSA/BLS keys.

Coverage basis: Zero critical wallet migration. No PQ-native path exists.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No critical wallets have been migrated to PQ protection. Foundation, validator, exchange, and custody keys are all quantum-vulnerable.

Assurance: Absence of any PQ wallet or migration attestation is well-established by the complete lack of PQ infrastructure across the Hyperliquid ecosystem.

Validator keys (both hot and cold wallets for bridge) are particularly critical. Cold wallet compromise would allow unlocking the bridge after a malicious withdrawal.

Claim: No identification, measurement, deprecation, or migration of quantum-vulnerable accounts has been performed. All existing accounts are vulnerable and no freeze/deprecation mechanism exists.

Coverage basis: No legacy pool identification or management.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The project has not published any accounting of vulnerable accounts, nor any policy for deprecation, freezing, or burning unmigratable vulnerable value.

The account model means all spent-from addresses are permanently vulnerable. Without a freeze or deprecation mechanism, there is no practical way to retire vulnerable accounts.

Claim: No quantum migration roadmap has been published by the Hyperliquid Foundation. The third-party qLABS/01 Quantum roadmap covers their own qONE token and Migration Toolkit, not a protocol-level HYPE or consensus migration.

Coverage basis: No official roadmap. Third-party plans do not cover native protocol migration.

Implementation score: 0 · Evidence confidence: High

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

Quantum blocker: No quantum migration roadmap exists from the Hyperliquid Foundation. Third-party qLABS efforts are not a substitute for protocol-level migration planning.

Assurance: Both the qLABS QVS index (MU=10, maximum unpreparedness) and LayerQu (Stage 0, 'Unaware') independently confirm the complete absence of a Hyperliquid Foundation quantum roadmap. The qLABS blog explicitly states: 'Hyperliquid Foundation has published no PQC roadmap, no PQ research program, no merged protocol proposal, no PQC testnet.'

The qLABS Layer 1 Migration Toolkit (targeted end of March 2026) is a third-party tool for smart-contract-based migration. It does not constitute a protocol-level migration plan endorsed or implemented by the Hyperliquid core team.

• https://qlabs.tech/blog/qlvi
• https://layerqu.com/chains/hyperliquid/

Claim: No PQ account creation, wallet tooling, transaction paths, custody paths, user warnings, education, or migration prompts exist. All defaults are classical ECDSA.

Coverage basis: Zero migration accessibility. No PQ defaults or tooling.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The complete absence of any PQ tooling, wallet support, or migration path is well-established by the lack of any PQ documentation, code, or announcements from the Hyperliquid team.

Users have no way to create a quantum-safe account or migrate existing funds even if they wanted to.

Claim: No enforcement mechanisms exist. No exchange, custody, bridge, wallet, or infrastructure coordination for quantum migration has been initiated. No unsafe-path blocking, deprecation, or mandatory migration deadlines exist.

Coverage basis: Zero enforcement or coordination.

Implementation score: 0 · Evidence confidence: High

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

Assurance: No evidence of any migration coordination activity. The project has not engaged exchanges, custodians, or wallet providers on quantum migration.

Without enforcement mechanisms, even a future opt-in PQ path would leave classical accounts vulnerable indefinitely.

Claim: No quantum-specific emergency disclosure, incident-response, or governance process has been published by the Hyperliquid Foundation.

Coverage basis: No quantum-specific IR process.

Implementation score: 0 · Evidence confidence: Low

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

Assurance: While no quantum-specific IR process exists, this is treated as note-only per the QRI Note-Only Caveat Rule because the absence of a process does not create a new quantum-vulnerable path beyond those already identified. The bridge does have a general dispute period and cold-wallet emergency unlock mechanism, but these rely on the same quantum-vulnerable BLS signatures.

The bridge's existing dispute period and locker/finalizer mechanisms provide some operational security margin, but they depend on the same BLS-based validator signatures that are quantum-vulnerable.

Claim: Hyperliquid uses no PQC or hybrid-PQC algorithms. All cryptography is classical: ECDSA secp256k1 and BLS.

Coverage basis: No PQC algorithms deployed or planned at protocol level.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The complete absence of any PQC algorithm usage is conclusively established by the exclusively classical cryptography documented across all Hyperliquid sources.

Claim: The only independent audit (Zellic, August 2023) covers the bridge contract on Arbitrum. It reviewed classical bridge logic and did not evaluate quantum threat models. No audit of HyperBFT consensus cryptography, transaction signing, or validator key management exists.

Coverage basis: Single stale bridge audit. Core consensus and transaction crypto unaudited.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: Treated as confidence-only per QRI v3.1: the audit gap does not create a new quantum-vulnerable path beyond the already-identified ECDSA and BLS vulnerabilities. However, the absence of any audit of consensus and transaction cryptography is a significant general security concern. The Zellic audit is nearly 3 years old and predates NIST PQC standardization.

Even a perfect audit of the current classical implementation would not improve quantum readiness. The audit gap is an assurance concern, not a quantum-readiness deduction.

• https://hyperliquid.gitbook.io/hyperliquid-docs/audits
• https://www.scribd.com/document/683456789/2308-Hyperliquid-Zellic-Audit-Report

Claim: The Python SDK and bridge contracts are open source. Core HyperBFT consensus implementation is not fully public, preventing independent verification of consensus cryptography.

Coverage basis: Partial open source. Core consensus is closed/not fully public.

Implementation score: 0 · Evidence confidence: Medium

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

Assurance: The Hyperliquid GitHub organization hosts the Python SDK, bridge contracts, and some node tooling, but the full HyperBFT consensus implementation is not publicly available. This prevents independent verification of the exact BLS signature scheme, key management, and consensus protocol implementation.

This subfactor is about PQ implementation assurance, but since there is no PQ implementation, the score is 0.00. The partial open-source nature of the classical implementation is recorded as context.

• https://github.com/hyperliquid-dex

Claim: No parameter agility or cryptographic upgrade path is documented. There is no mechanism for transitioning from ECDSA/BLS to PQC algorithms.

Coverage basis: No documented upgrade path or parameter agility.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The project has published no documentation on how cryptographic algorithms could be upgraded, what parameters could be changed, or what the governance process would be for a quantum migration.

The absence of documented parameter agility makes it uncertain whether the protocol could accommodate a PQC migration without a fundamental architectural redesign.

Claim: No PQC signature scheme is deployed, so stateful-signature safety (XMSS/LMS anti-reuse, state management) is not applicable. No analysis of PQ-specific implementation risks has been published.

Coverage basis: Not applicable; no PQC signatures deployed.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Correctly marked N/A. No PQC signature scheme exists to evaluate for stateful-signature risks. This subfactor will become applicable if Hyperliquid deploys XMSS, LMS, or similar stateful hash-based signatures.

Claim: No performance or resource-impact analysis for PQC migration has been published by the Hyperliquid Foundation.

Coverage basis: No PQ performance analysis.

Implementation score: 0 · Evidence confidence: High

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

Assurance: Treated as note-only per QRI v3.1 Note-Only Caveat Rule: the absence of a PQ performance benchmark does not create a new quantum-vulnerable path. Hyperliquid's high-throughput design (200k orders/sec claimed) would make PQC signature size and verification cost a significant engineering concern for any future migration, but this is a future planning gap, not a current vulnerability.

Hyperliquid's performance requirements (sub-second finality, 200k+ orders/sec) would make PQC migration particularly challenging. Large PQC signatures (e.g., ML-DSA-87 at ~4.6KB) would significantly impact block size, bandwidth, and verification costs. This is an operational concern for future migration planning.