Hyperliquid HYPE

Claim: No public cryptographic inventory or quantum threat model covering critical Hyperliquid mechanisms is present in the supplied record.

Coverage basis: Official architecture documentation identifies HyperBFT, HyperCore, and HyperEVM but does not inventory signature algorithms, attack windows, affected assets, bridges, wallets, or quantum mitigations.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: cap-applying

Quantum blocker: No public cryptographic inventory or quantum threat model exists for the production system.

Assurance: The absence finding is bounded to the supplied canonical record; exact algorithms remain incompletely documented.

General architecture documentation is not equivalent to a quantum-specific inventory or threat model.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-l1/l1-overview
• https://github.com/hyperliquid-dex

Claim: No public evidence record demonstrates a project quantum assessment, mitigation design, implementation, testnet, or mainnet protection.

Coverage basis: Public documentation, repository metadata, audits, and explorer evidence describe the production system but do not provide PQ specifications, code references, transaction proofs, or reproducible quantum-risk analytics.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: There is no verifiable public record of project PQ assessment or mitigation work.

Assurance: Available sources identify classical production architecture but do not substantiate quantum protection.

Unsupported application-layer PQ claims receive no credit.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://hyperliquid.gitbook.io/hyperliquid-docs/audits
• https://github.com/hyperliquid-dex
• https://app.hyperliquid.xyz/explorer

Claim: Production order and transaction authorization appears to use EIP-712 and classical Ethereum-compatible signatures, with no evidenced PQC or hybrid-PQC mainnet path.

Coverage basis: The explorer shows standard production accounts and transactions; secondary evidence identifies EIP-712 signing, conventionally associated with secp256k1 ECDSA.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Active production spend and order authorization remains classical-only.

Assurance: EIP-712 is supported by a secondary source rather than an explicit primary algorithm specification; no contradictory PQ path is evidenced.

Exact authorization behavior across every HyperCore and HyperEVM action is not fully inventoried.

• https://app.hyperliquid.xyz/explorer
• https://www.zealynx.io/glossary/eip-712

Claim: Standard transacted accounts create long-exposure classical ownership surfaces, and no PQ account format or exposure-reduction mechanism is evidenced.

Coverage basis: The mainnet explorer displays persistent addresses and transaction histories consistent with a classical account namespace; EIP-712 signing supports the classical-key assessment.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Transacted classical accounts can present offline key-recovery targets without an evidenced migration path.

Assurance: The explorer strongly evidences persistent production accounts, although account-level exposure timing was not quantitatively analyzed.

No address-reuse, exposed-key balance, or dormant-value analytics were supplied.

• https://app.hyperliquid.xyz/explorer
• https://www.zealynx.io/glossary/eip-712

Claim: HyperBFT relies on validator quorum authentication, with no evidenced PQC or hybrid-PQC validator signatures or block certificates.

Coverage basis: Official documentation describes stake-weighted HyperBFT validators, and secondary evidence describes a greater-than-two-thirds signed quorum.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Consensus-critical validator authentication is not shown to resist quantum key recovery or signature forgery.

Assurance: The exact validator signature algorithm is unresolved, but the signature-based consensus dependency is evidenced and no PQ mechanism is shown.

No exact validator algorithm is asserted beyond the supplied evidence.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-l1/l1-overview
• https://www.gate.com/learn/articles/what-is-hyperliquid-hype/6916

Claim: No quantum-safe evidence is supplied for HyperCore or HyperEVM state binding, bridge verification, supply controls, commitments, or data-availability authentication.

Coverage basis: Official documentation establishes HyperCore and HyperEVM state components, while bridge-audit documentation establishes bridge contracts; cryptographic details and PQ controls are absent.

Implementation score: 0 · Evidence confidence: Low

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

Quantum blocker: Quantum safety of critical state-binding and bridge-verification paths cannot be verified.

Assurance: Bridge contract audits do not establish quantum-safe verification or cover the full state-integrity scope.

No pairing-specific cap is applied because the supplied evidence does not establish a critical pairing or commitment dependency.

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

Claim: No native shielded transaction, privacy pool, or protocol-level zero-knowledge proof layer is identified in the evaluated production scope.

Coverage basis: The supplied architecture describes an exchange L1, HyperCore, and HyperEVM without identifying a privacy or shielded-state subsystem.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: This does not assess arbitrary HyperEVM applications that may independently deploy proof systems.

Privacy failure is not asserted for a layer not evidenced as part of the protocol design.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-l1/l1-overview
• https://app.hyperliquid.xyz/explorer

Claim: No PQC, hybrid-PQC, or satisfied-by-design treatment is evidenced for P2P transport, node identity, or peer authentication.

Coverage basis: A validator-based L1 has network communication, but the supplied sources provide no cryptographic P2P specification or evidence that node identity is isolated from critical control paths.

Implementation score: 0 · Evidence confidence: None

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

Quantum blocker: The role and quantum safety of peer and node authentication cannot be verified.

Assurance: No direct P2P cryptographic evidence was supplied.

The layer is not N/A merely because its implementation is undocumented.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-l1/l1-overview
• https://github.com/hyperliquid-dex

Claim: No production wallet, custody, HSM, signer, or hardware-wallet workflow supporting PQC or hybrid-PQC authorization is evidenced.

Coverage basis: User actions use the standard account and EIP-712 signing model; no alternative PQ wallet or custody path appears in the supplied documentation or repository evidence.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Critical users and custodians have no evidenced production PQ signing workflow.

Assurance: No exchange, custodian, HSM, or hardware-wallet attestations were supplied.

The native ownership path itself remains classical.

• https://github.com/hyperliquid-dex
• https://app.hyperliquid.xyz/explorer
• https://www.zealynx.io/glossary/eip-712

Claim: No economically relevant production value is evidenced as protected by protocol-level PQC or hybrid-PQC controls.

Coverage basis: Classical accounts and transactions are live, but no protected-value analytics, PQ account class, migration telemetry, or complete-by-design protection is documented.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Protected value-at-risk coverage is absent or unmeasurable while classical value remains exposed.

Assurance: No supply, active-balance, treasury, bridge, custody, or dormant-account data were supplied, so an exact percentage is not asserted.

The project does not qualify as PQ-native or migration-complete by design.

• https://github.com/hyperliquid-dex
• https://app.hyperliquid.xyz/explorer
• https://www.zealynx.io/glossary/eip-712

Claim: No evidence shows treasuries, exchanges, custodians, bridges, foundation accounts, validators, or major protocol wallets migrated to PQ or hybrid controls.

Coverage basis: Explorer, repository, and audit records identify production activity and a bridge but provide no protected-wallet attestations or protocol-enforced PQ ownership.

Implementation score: 0 · Evidence confidence: Low

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

Quantum blocker: Critical wallets and bridge control paths have no evidenced quantum-safe migration.

Assurance: The record does not establish balances or control structures for individual critical wallets.

A major-value-pool cap is not selected because material pool sizes and specific control paths are not established by canonical evidence.

• https://hyperliquid.gitbook.io/hyperliquid-docs/audits
• https://github.com/hyperliquid-dex
• https://app.hyperliquid.xyz/explorer

Claim: Classical production accounts exist, but vulnerable balances and pools are not identified, measured, deprecated, migrated, frozen, or addressed by a recovery policy.

Coverage basis: The explorer establishes a classical account environment; no legacy-state inventory, migration analytics, or enforcement policy is supplied.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Legacy classical ownership coverage cannot be measured and no treatment path is evidenced.

Assurance: The term legacy denotes balances that would remain vulnerable under a future migration; no migration is currently evidenced.

Absent balance analytics prevent quantification of dormant or unmigratable value.

• https://github.com/hyperliquid-dex
• https://app.hyperliquid.xyz/explorer
• https://www.zealynx.io/glossary/eip-712

Claim: No official public quantum migration or protection roadmap with sequencing, activation criteria, and dependencies is supplied.

Coverage basis: Official documentation and visible repository evidence contain no substantiated PQ migration plan.

Implementation score: 0 · Evidence confidence: Low

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

Quantum blocker: There is no evidenced roadmap for replacing vulnerable transaction, consensus, wallet, and bridge cryptography.

Assurance: The assessment is limited to the supplied canonical record; no third-party initiative is treated as an official protocol roadmap.

Roadmap intent would not constitute production protection even if later supplied.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-l1/l1-overview
• https://github.com/hyperliquid-dex

Claim: No PQ or hybrid account creation, wallet tooling, transaction path, custody path, warning, or migration prompt is evidenced on mainnet.

Coverage basis: Current user activity follows standard accounts and EIP-712 signing; no PQ alternative or protected default is documented.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: Users cannot access an evidenced production PQ authorization path and remain on vulnerable defaults.

Assurance: No wallet or frontend artifact demonstrating PQ functionality was supplied.

The absence of prompts is material because the underlying classical path remains active and unprotected.

• https://github.com/hyperliquid-dex
• https://app.hyperliquid.xyz/explorer
• https://www.zealynx.io/glossary/eip-712

Claim: No deprecation, freeze, disabled-legacy-signing rule, mandatory migration deadline, unsafe-path restriction, or ecosystem coordination mechanism is evidenced.

Coverage basis: The production record shows continued classical transactions without a documented enforcement or coordination path.

Implementation score: 0 · Evidence confidence: Low

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

Quantum blocker: Classical ownership and transaction paths remain available without an evidenced mechanism to retire or restrict them.

Assurance: Bridge directionality and withdrawal restrictions are unresolved, so no unrestricted-bridge cap is asserted.

No exchange, custodian, bridge, wallet, or infrastructure coordination evidence was supplied.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://hyperliquid.gitbook.io/hyperliquid-docs/audits
• https://github.com/hyperliquid-dex
• https://app.hyperliquid.xyz/explorer

Claim: No quantum-specific emergency disclosure, incident-response, or governance process is evidenced.

Coverage basis: The supplied documentation and repository record do not describe a quantum compromise response, emergency migration, or vulnerable-account policy.

Implementation score: 0 · Evidence confidence: Low

Issue classification: operational/product caveat · Score treatment: note-only

Assurance: Lack of a formal quantum incident-response playbook does not independently create a cap; current classical paths are separately scored and capped.

A general emergency-governance mechanism, if one exists, was not documented in the supplied record.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://github.com/hyperliquid-dex

Claim: No NIST-standardized, standards-track, or broadly reviewed PQC or hybrid-PQC algorithm is selected for a production Hyperliquid layer.

Coverage basis: Official documentation and repository metadata contain no PQ algorithm specification or integration evidence.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No production PQ algorithm selection exists for user or validator authorization.

Assurance: The absence assessment does not evaluate unsupported third-party application contracts.

No bespoke-PQC cap is applied because no production PQ design is evidenced.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://github.com/hyperliquid-dex

Claim: No independent audit covers a production PQ implementation, core user-signature path, or HyperBFT validator-authentication path.

Coverage basis: The official audit page lists legacy bridge and Circle-contract audits only, which are scope-mismatched for the core quantum-critical protocol.

Implementation score: 0 · Evidence confidence: High

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

Assurance: The audit gap limits assurance but does not independently cap the result; current classical vulnerabilities and absent PQ implementation are established separately.

Detailed audit dates and findings were not supplied in the dossier summary.

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

Claim: Public repositories exist, but no open-source, reproducible PQ or hybrid implementation for production-critical paths is evidenced.

Coverage basis: The organization hosts node and SDK repositories, but metadata does not establish PQ code, reproducible builds, exact deployed correspondence, or quantum test vectors.

Implementation score: 0 · Evidence confidence: Medium

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

Quantum blocker: No reproducible artifact verifies a production quantum-security property.

Assurance: General source availability is insufficient for implementation credit in this quantum-critical assurance category.

Specific cryptographic code paths were not surfaced in canonical evidence.

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

Claim: No documented parameter agility or upgrade path for replacing vulnerable user, validator, bridge, or wallet cryptography is supplied.

Coverage basis: Architecture and repository records provide no PQ suite negotiation, algorithm identifiers, activation mechanism, or compatibility plan.

Implementation score: 0 · Evidence confidence: Low

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

Quantum blocker: The ability to replace production classical cryptography without preserving vulnerable fallback paths is not evidenced.

Assurance: Future PQ-to-PQ agility is not the issue; the current record lacks an ECC-to-PQC path.

Ordinary software upgradeability does not by itself establish cryptographic agility.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-l1/l1-overview
• https://github.com/hyperliquid-dex

Claim: No implementation-risk controls for a PQ or hybrid signing path are documented because no such production path is evidenced.

Coverage basis: The record contains no treatment of PQ signing-state discipline, side channels, fault injection, HSM integration, hardware wallets, custody controls, or PQ key lifecycle management.

Implementation score: 0 · Evidence confidence: None

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

Assurance: These controls cannot be meaningfully reviewed until a PQ or hybrid design is specified; their absence does not create an additional cap beyond absent protection.

The subfactor is not N/A merely because implementation has not begun.

• https://hyperliquid.gitbook.io/hyperliquid-docs/audits
• https://github.com/hyperliquid-dex

Claim: No performance or resource-impact analysis exists for deploying PQ signatures or verification across transactions, validators, wallets, or nodes.

Coverage basis: No benchmark, block-size analysis, verification-cost model, fee analysis, mempool study, or validator hardware assessment is present in the canonical record.

Implementation score: 0 · Evidence confidence: None

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

Assurance: Missing formal benchmarks are a non-scoring assurance caveat unless resource constraints prevent safe use of an implemented PQ path; no such path is evidenced.

No independent performance-related cap is applied.

• https://hyperliquid.gitbook.io/hyperliquid-docs
• https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-l1/l1-overview
• https://github.com/hyperliquid-dex