Hyperliquid's consensus client is closed-source, distributed as a GPG-signed binary; the wire-format consensus signature scheme is not publicly specified. This blocks Gate 2 reconstruction for any consensus-layer cryptographic claim. HyperBFT is named (HotStuff variant) but the underlying signature primitive is not. Bridge TVL ~$4.57B sits behind ECDSA secp256k1 validator hot/cold wallets; five Hyper Foundation validators control ~81% of staked HYPE, concentrating the post-CRQC forge surface to a small operationally-coordinated entity.
Summary
Hyperliquid is a perpetuals-focused L1 secured by HyperBFT (HotStuff-derivative) running a closed-source Rust validator binary. User and bridge signing is ECDSA over secp256k1 (EIP-712 typed data for user-signed actions; ecrecover for validator hot/cold wallet signatures on Arbitrum-side Bridge2). HyperEVM is a Cancun-without-blobs EVM at chain ID 999. Active validator set is 21 by stake; the Hyper Foundation operates 5 validators controlling ~81% of staked HYPE. Total bridge value locked is ~$4.57B (Arbitrum-side $3.27B + HL L1 $1.30B). The Hyper Foundation has made no public post-quantum statement, published no PQC roadmap, and disclosed no migration architecture. A third-party project (qLABS / 01 Quantum) launched a quantum-resistant token (qONE) on HyperEVM in February 2026 using IronCAP code-based dual-signature wrappers; this is application-layer overlay deployed without protocol-level Hyperliquid endorsement. HyperBFT consensus signature primitive is not publicly specified, the published validator binary verifies via GPG, but the wire-format crypto is undocumented (1a partially voided, 4f voided). Gate 1a-Sig FAIL, Gate 1a-KEM FAIL. Gate 2 PARTIAL FAIL (closed-source consensus client). QRI raw 15, after-cap 10, Band 1 Unaware.
What the gates say
- Gate 1a, Hybrid signature: FAIL , no documented hybrid signature composition; ECDSA secp256k1 is the only signing primitive at user, bridge, and presumed consensus layers
- Gate 1a, Hybrid KEM: FAIL , validator gossip and RPC TLS classical X25519 / RSA-based; no documented hybrid KEM
- Gate 1b, Commit-to-hash: COND , no OR-composition exists to apply commit-to-hash discipline to
- Gate 2, Evidence reconstruction: COND , PARTIAL FAIL (consensus-layer signature primitive is not reconstructible from public artifacts due to closed-source consensus client; 1a partially voided; 4f voided; 1e partial
- Gate 3, Primitive naming: COND , PARTIAL FAIL (consensus-signature primitive unnamed in any official source. User and bridge primitives are fully named: ECDSA secp256k1, Keccak-256, EIP-712
Burn-vs-rescue policy on file
Declared option f, Undeclared. No public Hyper Foundation statement on freeze, burn, STARK rescue, hybrid client-layer migration, rate-limit canary, or optional migration policy for quantum-recovery scenarios. The bridge has a Byzantine-fault dispute-and-lock mechanism but no quantum-specific recovery framework.
Seven dimensions
Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.
1 Cryptographic Exposure weight 15% 18 / 100
Penalty: consensus-layer signature scheme is not named in any official Hyperliquid public source, Gate 3 partial fail at consensus surface. The validator client is distributed as a closed-source signed binary; only the visor/runner code is public.
ECDSA secp256k1 (user-signed actions and L1 actions; EIP-712 typed-data signing) · ECDSA secp256k1 (validator hot-wallet and cold-wallet signatures on Bridge2) · Keccak-256 (HyperEVM hash primitive; Cancun specification without blobs) · HyperBFT (named as consensus algorithm, HotStuff-derivative, but specific consensus-signature primitive not documented in any public Hyperliquid artifact) ECDSA secp256k1 (user actions + bridge validator signatures)→ Shor-break-via-DL-without-pairingsKeccak-256→ Grover-weaken (256→128-bit effective preimage strength)HyperBFT consensus signature primitive→ unnamed publicly, assumed Shor-vulnerable based on EVM-aligned key model
0 PQ-safe family deployed.
No NIST PQC primitives deployed.
Consensus client distributed as closed-source signed binary; bridge contract is plain Solidity using OpenZeppelin libraries (Pausable, ReentrancyGuard, ERC20Permit, SafeERC20). Library provenance: OpenZeppelin contracts; Arbitrum Nitro ArbSys precompile reference; standard ecrecover precompile. Stateless. Cryptanalytic tier 1. The closed-source consensus client means consensus-layer crypto cannot be third-party audited for constant-time behavior.
2 Quantum Recovery Exposure weight 10% 18 / 100
EOA-style ECDSA keys identical to Ethereum-style addressing. Every user public key is revealed at first transaction. For perp traders, this is universal: every order placement reveals the signing pubkey. Bridge TVL ~$4.57B sits behind quantum-vulnerable ECDSA keys at all times.
No distinct cold-key scheme separate from active-key scheme; all keys are ECDSA secp256k1. Validator cold wallets used for unlocking the bridge are also ECDSA Ethereum addresses, same primitive, same Shor exposure.
Perpetuals positions are short-lived but user wallet keys persist; validator hot/cold wallet signatures persist as the cryptographic anchor for validator-set updates and historical bridge withdrawals. Historical signatures (validator-set update signatures, batched withdrawal signatures) are forgeable post-Shor.
API surface (api.hyperliquid.xyz, rpc.hyperliquid.xyz/evm) terminates classical TLS. Validator gossip uses ports 4001/4002 over the public internet; the wire-protocol cryptography is not publicly documented. No PQ KEM at any transport surface.
3 Metadata, Anonymity & Confidentiality weight 13% 21 / 100
Pseudonymous (Ethereum-style 0x addresses) but fully transparent: order book state, fills, and positions are public on-chain. No shielding, no mixing, no hidden balances at protocol level. Lower score than e.g. Bitcoin's pseudonymity reflects the additional metadata leakage of order book and trading flow.
The default and dominant RPC endpoint is rpc.hyperliquid.xyz/evm operated by the foundation. Third-party RPC providers (QuickNode, Alchemy, Dwellir) exist but the foundation-operated endpoint is the canonical default. Five Hyper Foundation validators controlling ~81% of staked HYPE. Validator metadata retention policy is undeclared.
Bridge2 contract on Arbitrum is the canonical USDC entry/exit point. Deposits and withdrawals are individually visible on Arbitrum (DepositEvent / RequestedWithdrawal / FinalizedWithdrawal) and linkable to L1 user addresses. Additional bridge surfaces (LayerZero, deBridge, Across, Wormhole HyperEVM) add further passive-observer correlation paths.
A transparent order book has no shielded historical state to retroactively de-anonymize. Shor on secp256k1 enables post-hoc forgery of historical authorizations but does not retroactively reveal anything that was not already public.
No mixnet, no on-chain shuffling, no commit-reveal pattern.
4 Migration Architecture weight 10% 17 / 100
No documented protocol-level algorithm-switching framework. HyperBFT is identified by name only; no public spec describes how validator-signature primitive could be changed without coordinated client upgrade. The validator client is a closed-source signed binary; consensus-level upgrades require the foundation to ship a new binary. EIP-1559 enabled on HyperEVM but no EIP-7702-style hooks documented.
HyperEVM is Cancun-without-blobs and EVM-equivalent at the precompile layer. No native account abstraction documented in the Hyperliquid spec. ERC-4337 theoretically deployable but no foundation-published entrypoint or paymaster. EIP-7702 live status on HyperEVM not declared. User L1 actions support an 'API wallet' (sub-key delegation via approveAgent), application-layer key rotation, not protocol-level account abstraction.
Mainnet launched 2023; HIP-3 (permissionless perp deployment) activated mainnet 2025-10-13; HIP-4 (outcome contracts) announced 2026-02-02. Multiple coordinated upgrades have shipped without contested forks. Track record is short (≤3 years) and limited to non-cryptographic upgrades.
No hybrid-PQC plan published. The bridge contract architecture (validator quorum signing) could in principle be extended to validate hybrid signatures, but this is not specified anywhere in foundation artifacts. HyperEVM precompile model could host PQ-verification precompiles, possible architecturally, not announced.
N/A, no stateful hash signature scheme deployed. Default 15/15 for stateless schemes.
VOID. HyperBFT is a HotStuff-derivative which conventionally uses BLS aggregation in consensus, but Hyperliquid does not publicly document its consensus-signature primitive. With the consensus client closed-source and the wire-protocol crypto unspecified, the BFT-aggregation-path declaration cannot be evaluated. Per Gate 2, the sub-score is voided.
5 Deployment Execution weight 22% 15 / 100
0%. No PQ primitive in any consensus path, bridge path, or user-signing path. The qONE token launch on HyperEVM (2026-02-11) deploys IronCAP code-based dual-signature wrappers at the application contract layer for that specific token; this is not Hyperliquid protocol PQC.
Consensus client distributed as closed-source signed binary; no public source repository for the validator client. No PQ code merged.
All 21 active validators sign with ECDSA secp256k1 hot/cold wallets per the bridge contract spec.
VOIDED per v3.1 (5a = 0). Independently, no Hyper Foundation post, doc, or HIP names a PQC-related milestone with a date or enforcement mechanism.
Hyper Foundation has made zero PQC announcements and shipped zero PQC. Ratio undefined / not adverse. Full credit because the chain has not engaged in announce-without-ship behavior.
Undisclosed. No PQ scheme adopted, so no per-block byte multiplier is published.
6 Supply Chain Vendor Readiness weight 22% 6 / 100
Top-3 wallets: MetaMask (default for HyperEVM via custom RPC + chainId 999), Rabby, Hyperliquid native frontend (web app at app.hyperliquid.xyz). None has a published PQC roadmap with primitive-named ML-DSA / SLH-DSA / Falcon support shipped to mainnet.
Top-3 bridges: Hyperliquid Bridge2 (Arbitrum-side, native, $3.27B Arbitrum-side TVL), LayerZero (HyperEVM live), Wormhole (HyperEVM live). None has a published PQC roadmap with primitive-named PQ signature/KEM shipped. Bridge2's validator-quorum signing is ECDSA secp256k1 throughout.
Top-3 custodians: Anchorage Digital Bank (Grayscale Hyperliquid ETF custodian as of 2026-04-20 amendment, replacing Coinbase), BitGo Bank & Trust (joint custodian on 21Shares THYP filing 2026-04-14), Coinbase Custody (HYPE supported). MPC-PQ readiness flagged is research-only across all three.
Top-3 RPC: foundation-operated rpc.hyperliquid.xyz/evm (default), QuickNode, Alchemy. Foundation RPC has no PQ TLS posture documented. HSMs: not chain-specific (validators run on commodity hardware per official spec). TEE: not in spec.
7 Governance & Coordination weight 8% 16 / 100
21 active validators. Five Hyper Foundation validators controlled approximately 81% of staked HYPE per January 2025 reporting. Nakamoto coefficient on stake is effectively 1 (foundation controls quorum). Single dominant client implementation (closed-source binary).
HIP-3 (2025-10-13) and HIP-4 (2026-02-02) shipped on schedule, no contested forks. No upgrade executed under adversarial pressure (no live exploit, no halt-and-restart, no contested rollback).
Hyperliquid Labs (engineering, ~11 employees) and the Hyper Foundation (ecosystem support) are named entities. Jeff Yan is publicly named CEO/co-founder. The Hyperliquid Policy Center launched as a separate nonprofit led by Jake Chervinsky. No named PQC lead, no published PQ working group.
The closest precedent is the JELLYJELLY oracle-manipulation incident (March 2025) where validators voted to delist JELLY perps and reverse positions; this involved coordinated emergency action but not cryptographic change.
No canary, no tripwire, no rate-limited spending rule, no community honeypot. The bridge has a dispute-period locking mechanism for invalid signatures, but this is a Byzantine-fault response, not a quantum-attack tripwire.
X + Y vs Z, when does the math turn against you?
v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?
Verdict
X+Y range 17–28 years, Crisis Zone (vs Z10 2030); Outside risk window (vs Z25 2035)
Z-compliance
Outside compliance window (NIST IR 8547 disallowance 2035)
Source-disagreement disclosure
v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.
24 (older Hyperliquid Wiki references) vs 21 (2025–2026 reporting and current Hyperliquid Docs language). Current state is 21 active validators per the staking/validators dashboard reporting. Resolved to 21.
Bridge2.sol header comment states 'The L1 runs tendermint consensus' (legacy language); current HyperCore overview states 'secured by HyperBFT, a variant of HotStuff consensus.' The Tendermint reference is a stale code comment from the legacy bridge era. Resolved to HyperBFT (HotStuff variant).
Five foundation validators ≈81% reported by external analysts in January 2025; the foundation's response did not deny the figure but emphasized plans to grow the validator pool. Treated as best available 2025 figure pending updated public disclosure.
Delta-QRI under alternative weighting
Under a hypothetical alternative weighting that gave +5% to Dim 5 and -5% to Dim 7 (heavier deployment-execution emphasis), QRI would drop by approximately 1 point. Material conclusions unchanged.
Announcement-to-shipped ratio
Announced: 0. Shipped: 0. Ratio: 0.
Tag: none, no washing. Third-party qLABS / 01 Quantum announcements are not Hyperliquid Foundation announcements; the Hyper Foundation has not endorsed, integrated, or promoted these third-party initiatives in official channels.
Peers in the L1 profile
9 chains closest to Hyperliquid by Stage then QRI.