Institutional Blockchain, Regulatory & Post-Quantum Readiness Benchmark 2026

It is an institutional-readiness benchmark that evaluates post-quantum coverage, cryptographic agility, custody migration, privacy, performance, deployment evidence and standards quality. It is not a token-price or market-cap ranking.

Because post-quantum migration is not a one-time algorithm swap. Institutions must be able to replace algorithms, parameters and keys again if standards, cryptanalysis, regulation or hardware support changes. Crypto-agility remains the benchmark's largest single weight at 20%.

No. Transaction authorization is only one surface. Consensus signatures, validator identity, key establishment, networking, privacy encryption, bridges, custody, governance and existing exposed keys can remain classically vulnerable.

No. Pluto is a public EVM-compatible testnet. The benchmark treats EternaX's scored core capabilities as testnet-demonstrated evidence, not production-mainnet deployment.

The score reflects the disclosed methodology across post-quantum coverage, cryptographic agility, institutional controls, custody migration, performance, deployment and evidence quality. EternaX receives 4.8/8 for deployment because Pluto is a public testnet. The score is a publisher-assigned research result, not an independent security certification.

Algorand v5.0.0 supports native Falcon-1024 post-quantum accounts on mainnet. That does not make every Algorand surface post-quantum: consensus/VRF migration remains separate roadmap work.

Starknet has meaningful post-quantum building blocks but is not yet end-to-end post-quantum. Its STARK proving layer is PQ-friendly, it has demonstrated an experimental Falcon-512 account on Mainnet, and v0.14.3 moved selected OS/configuration hashing from Pedersen to a BLAKE2s-256-based construction. Falcon remains experimental/unaudited, FIPS 206 is not final, and trie/address plus other classical dependencies still require migration.

No. The Ethereum Foundation has a dedicated multi-layer post-quantum program covering execution, consensus and data, but describes the transition as a coordinated migration over years. Current production consensus still uses classical cryptography.

Because PQ readiness includes confidentiality and recoverability, not only signatures. Ironwood adds quantum recoverability, but Zcash's own ZIPs explicitly state that this does not by itself make Zcash secure against quantum attacks. Project Tachyon targets future post-quantum privacy.

Native post-quantum signatures are important evidence, but the benchmark evaluates institutional readiness across multiple dimensions. A live PQ signature can score strongly on authorization while custody, privacy, performance, migration and institutional controls are assessed separately.

EternaX throughput, finality and PQ-overhead figures are treated as project-reported targets or modelled/testnet claims unless independently reproduced. The benchmark never treats a target as production mainnet evidence.

A = live mainnet/on-chain or official release evidence; B = public testnet, reproducible code or formal technical implementation; C = official roadmap/proposal; D = third-party pilot or secondary technical evidence; E = marketing-only claim. Mixed grades indicate different surfaces have different evidence maturity.

The benchmark includes EternaX, Arc, Tempo, Canton Network, Zcash, Algorand, Starknet, Sui, NEAR, XRP Ledger, Hedera, Ethereum, Solana, Aptos, Stellar, Hyperledger Besu and Bitcoin. They are selected because they illuminate different institutional requirements including payments, tokenization, privacy, custody, performance and cryptographic migration.

The benchmark is an institutional blockchain readiness study with post-quantum security as a critical dimension, not a list of quantum-resistant coins. Arc and Tempo are relevant because they are purpose-built financial infrastructure for stablecoins, payments and settlement; their current cryptographic posture provides an important baseline for migration analysis.

Canton is included because institutional privacy, regulated workflows and cryptographic extensibility are central to market-infrastructure readiness. Its production architecture provides a useful comparison for how cryptographic migration interacts with real institutional operating requirements.

No post-quantum transaction, validator or key-establishment scheme is credited to Arc in this benchmark. Arc is included because its stablecoin-finance, privacy and institutional-settlement architecture provides an important migration baseline.

No PQ signature or KEX is currently credited. Tempo’s TIP-1020 is live on Mainnet and provides a stable verifier interface for secp256k1, P-256 and WebAuthn, which is useful for future agility but is not itself post-quantum. Tempo also documents opt-in privacy for balances/transfers.

No. Digital Asset’s CISO states that Canton currently uses ECC. The planned migration is to add native PQC through Canton’s existing extensible cryptographic API; ML-DSA is one candidate and hybrid schemes are also being considered.

Sui has built ML-DSA-65 account support and an SLH-DSA vault path, with staged activation. The benchmark does not treat Sui as fully post-quantum across consensus, networking and privacy.

NEAR has stable protocol support for ML-DSA-65 transaction and access keys. That is meaningful account-layer progress, but consensus, networking, custody and privacy remain separate cryptographic surfaces.

Not protocol-wide today. Solana has Winternitz-vault usage and Falcon research, and Anza has published Quantumglow, a post-quantum research redesign of Alpenglow consensus. Quantumglow is research-stage rather than deployed, and wallet/account/networking migration remains separate work.

Not as a live Mainnet capability in this benchmark. AIP-137 specifies SLH-DSA-SHA2-128s post-quantum accounts and Aptos Core contains feature-gated support, but the VM rejects the scheme unless the feature is enabled. The implementation path is real; production activation remains a separate milestone.

Not in production today. Ripple targets full PQ readiness by 2028 and has published a phased program including NIST-scheme testing, an ML-DSA AlphaNet proof of concept, validator testing, Devnet work and an early PQ custody-wallet prototype. Current production signing remains secp256k1/Ed25519.

Not today. Hedera currently uses ECDSA secp256k1 and Ed25519 for accounts/transactions and classical TLS. Its published roadmap sequences PQ TLS for nodes and clients, hybrid event signing, and then a new PQ user-key type after FIPS 206 finalization, with ML-DSA as fallback if needed.

No. Classic Stellar accounts still use Ed25519. Soroban contract accounts now provide custom authentication, including passkey/P-256 and arbitrary contract-verified policies, which improves crypto-agility, but no production PQ key type or PQ verifier is credited.

Upstream Besu is not credited with native post-quantum transaction or QBFT validator signatures. Enterprise deployments can add custom controls or overlays, but those should be assessed separately from base Besu.

Post-quantum security describes resistance to known quantum attacks. Crypto-agility describes the operational ability to replace algorithms, parameters and keys when cryptography changes. A system can support a PQ algorithm and still have weak crypto-agility.

It measures whether a network's published cryptography aligns with finalized post-quantum standards, whether key establishment and signatures are both addressed, whether algorithms can be rotated as standards change, and whether implementation/validation evidence exists for institutional procurement. It is not a legal-compliance certification.

No. EO 14412 applies to federal systems and related procurement requirements. Using FIPS 204 or FIPS 205 can improve standards alignment for digital signatures, but EO readiness also involves key establishment, migration planning, inventories/CBOM, implementation validation and the specific system's procurement context.

As of 24 August 2026, FIPS 203 standardizes ML-KEM for key establishment, FIPS 204 standardizes ML-DSA for digital signatures, and FIPS 205 standardizes SLH-DSA for digital signatures. FN-DSA/Falcon is still being standardized as FIPS 206 and is not treated as a finalized FIPS signature in this benchmark.

FIPS 204 and FIPS 205 specify algorithms. FIPS 140-3 and the Cryptographic Module Validation Program concern validation of concrete cryptographic modules. An institution may therefore need both an approved algorithm and an implementation that satisfies the applicable module-validation or procurement requirement.

Measured numbers come from published implementation, testnet or mainnet observations. Derived numbers come from standardized signature/key sizes or protocol limits. Modelled numbers use disclosed assumptions. Modelled payload penalties are explicitly labelled and are never presented as observed chain TPS losses.

EternaX uses standardized hybrid TLS 1.3 rather than proprietary networking cryptography. Its networking profile uses IETF RFC 10024 PQ/T key-establishment groups backed by ML-KEM from NIST FIPS 203, with X25519MLKEM768 as the practical default and SecP256r1MLKEM768 available for FIPS-oriented institutional deployments. Because TLS groups are negotiated and policy-selectable, the networking layer can move to future approved groups without redesigning the chain or applications.

EternaX targets 50,000–200,000 transactions per second with approximately 2% modelled post-quantum throughput overhead, 20–50ms soft finality and 400–520ms hard finality. The design also targets transaction fees below $0.001 and 24/7/365 settlement. These are published EternaX design targets rather than independently measured production-mainnet results.

Yes. Post-quantum consensus capability is demonstrated on the Pluto public testnet and is scored as testnet evidence (B), not as an architecture-only claim.

Yes. Institutional privacy, privacy between participants, selective disclosure and auditable regulatory access are demonstrated on the Pluto public testnet and scored as testnet evidence (B).

Yes at the current testnet evidence level. Pluto demonstrates crypto-agility across authorization, consensus, networking/key establishment, privacy and custody, so these surfaces are scored as testnet evidence (B).

Because ML-DSA and FN-DSA/Falcon rely on structured-lattice assumptions, while SLH-DSA is standardized under FIPS 205 on a different, hash-based foundation. NIST explicitly sought non-structured-lattice signatures to diversify the PQ portfolio. The trade-off is larger signatures and systems cost.