Domain

Post-Quantum Threats

A Cryptographically Relevant Quantum Computer (CRQC) breaks ECDSA, BLS, ECDH, Groth16, PLONK/KZG — Ethereum consensus, execution, and application privacy layers all affected. - Harvest Now, Decrypt Later (HNDL) means confidentiality-critical applications face urgency now, even though CRQC is years away. - Hash-based and lattice-based primitives provide migration paths; STARKs are already PQ-safe.

Case Studies

Patterns

Vendors

Custody Data & Oracles Funds & Assets Identity & Compliance Payments Post-Quantum Threats Trading

Shortest-path Patterns

Building blocks for post-quantum threats privacy

Lean Ethereum

Plan a long-range redesign of the Ethereum consensus layer, targeting a single major fork around 2030 that consolidates several research tracks: post-quantum signatures, minimal zkVMs for signature aggregation and proof compression, reduced hardware and stake thresholds for validators, and networking upgrades that support a larger validator set. The goal is a consensus protocol that is stable for decades, resilient against quantum adversaries, and verifiable on minimal devices.

CR: High OS: Yes P: None S: Medium

Stealth Addresses

Enable unlinkable transfers on a transparent chain by deriving a one-time destination address per transaction using a Diffie-Hellman shared secret between sender and receiver keys. Observers see a transfer to a fresh address; only the recipient can detect and spend the funds.

CR: Medium OS: Yes P: Partial S: High

zk-TLS

Export verifiable data or identity attributes from a TLS-protected website into a form that an on-chain contract or a counterparty can check. The user jointly runs a TLS session with a notary; the notary signs a transcript of the session; the user produces a zero-knowledge proof over the signed transcript that discloses only the fields required downstream.

CR: Low OS: Partial P: Partial S: Medium

zk-KYC/ML + ERC-734/735 identity claims

Publish identity claims on-chain that are backed by a zero-knowledge proof of an off-chain KYC or AML check, instead of a flat signature from a whitelisted issuer. The identity contract (ERC-734/735) holds the claims; a verifier contract checks the zero-knowledge proof at claim ingestion or at access time. The on-chain public sees that a qualified check was performed under a specific policy, without learning the subject's personal data.

CR: Low OS: Partial P: Partial S: Medium

Shielding

Enable confidential transfers by shielding balances, sender, and receiver, while still allowing regulators and auditors to verify via selective disclosure (viewing keys, proofs). The logic generalizes beyond ERC-20 to any transferable asset.

CR: Medium OS: Partial P: Full S: Medium

Noir Private Contracts

Give developers a privacy-focused DSL to write smart contracts that blend public logic with confidential private computation in the same contract. Private functions execute client-side and produce zero-knowledge proofs; public functions execute on the sequencer transparently. Private and public state can be composed in a single application.

CR: Medium OS: Yes P: Full S: Medium

Selective disclosure (viewing keys + zero-knowledge proofs)

Provide on-demand, scoped visibility into confidential trades and positions via threshold-controlled viewing keys or zero-knowledge predicate proofs that answer specific regulator questions. The institution keeps plaintext private by default and releases only the minimum information required to satisfy a specific, logged mandate.

CR: Medium OS: Partial P: Full S: Medium

ZK Proof Systems

Give designers a decision framework for choosing a zero-knowledge proof system on Ethereum. A zero-knowledge proof lets one party prove a statement is true without revealing the inputs. The system's commitment scheme (elliptic-curve pairings, discrete log over curves, collision-resistant hashes, or lattices) drives its post-quantum posture; the setup model drives its trust assumption; proof size and prover and verifier cost drive deployment economics.

CR: Medium OS: Yes P: Full S: Medium

Private Set Intersection (DH-based)

Two parties each hold a private set of identifiers and want to learn which elements they share without exposing the rest. This variant uses commutative encryption via elliptic-curve Diffie-Hellman: both parties blind their inputs with secret scalars, and the commutativity of scalar multiplication lets them compare double-blinded values without revealing the originals. The protocol runs bilaterally between the two parties.

CR: High OS: Yes P: Full S: High

MPC Custody and Transaction Control

Provide custody and controlled execution of digital-asset transactions by distributing key shares across a set of signers that jointly produce a valid signature without ever reconstructing the private key. The pattern eliminates single points of key compromise and enforces policy-based approvals before any signature is released.

CR: Low OS: Partial P: None S: Medium

TEE Key Manager

Run an institutional key manager inside an attested hardware-isolated environment. Keys are generated or imported inside the enclave, which enforces a signing policy and produces signatures while keeping private key material isolated from the host and operator. External systems bind the signer public key and policy hash to an approved attested measurement via an attestation verifier; on-chain registries can record this binding for audit.

CR: Low OS: Partial P: Partial S: Medium

Private Shared State (MPC + ZK / co-SNARKs)

Enable N parties to jointly read and write shared on-chain state (balances, positions, order books, collateral pools) while keeping each party's individual data private from the others and from the infrastructure operator. This variant secret-shares each party's inputs across a distributed prover network; the nodes jointly run an MPC protocol to compute a single zero-knowledge proof of a correct state transition; the proof is posted on-chain for verification.

CR: Medium OS: Yes P: Full S: Medium

Hybrid TEE + ZK settlement

Coordinate private settlement inside a Trusted Execution Environment while anchoring correctness with a zero-knowledge proof verified on-chain. The enclave acts as a neutral synchronization layer between parties who do not trust each other: it matches orders, manages escrow state, and produces a succinct proof of correct execution. External observers see only commitments, proofs, and stealth-address outputs, while the enclave operator sees plaintext under contractual terms.

CR: Medium OS: Partial P: Partial S: Medium

Delegated Proving (co-SNARKs)

Offload zero-knowledge proof generation to a distributed prover network without revealing the witness. The user secret-shares their witness across several proving nodes; the nodes jointly run an MPC protocol to compute a single SNARK proof; no individual node ever reconstructs the full witness. The resulting proof is identical to one produced client-side and is verified on-chain or off-chain with no changes on the verifier side.

CR: Medium OS: Yes P: Full S: Medium

Threshold-encrypted mempool

Prevent miner-extractable-value extraction by encrypting transaction content before mempool submission and releasing the decryption key only after block ordering is committed. A distributed committee holds threshold key shares, so no single party can decrypt prematurely. The result is cryptographic protection against front-running, back-running, and sandwich attacks, without handing trust to any one relay.

CR: High OS: Partial P: Partial S: Medium

vOPRF Nullifiers

Generate deterministic, scope-bound nullifiers using a verifiable oblivious pseudorandom function (vOPRF) whose secret key is held by a threshold committee. The client blinds its input, the committee jointly evaluates the OPRF, and the client unblinds the response to derive a nullifier. The server key prevents offline reconstruction from a leaked client secret; verifiability lets the client detect a malicious committee response.

CR: Medium OS: Partial P: Full S: Medium

Pre-trade Privacy (Encrypted Order Flow)

Prevent front-running and information leakage by routing quotes and orders via encrypted or private submission paths so intent, size, and price stay hidden until inclusion. Settlement then proceeds on a shielded pool or confidential rail so the executed amounts also remain private.

CR: Low OS: Partial P: Partial S: Low

Origin-Locked Cross-Chain Confidential Ledger

Provide confidential balances and transfers for an existing ERC-20 on an origin EVM chain, while keeping the asset locked and settled on the origin chain. Confidentiality logic runs on a separate execution layer that maintains an encrypted ledger and verifies ZK-proven state transitions. Unlike a privacy bridge or a privacy rollup, funds never leave the origin chain.

CR: Medium OS: Partial P: Partial S: High

Safe Proof Delegation

Let a user delegate zero-knowledge proof generation to an external prover (a privacy RPC, a hardware accelerator, or a third-party service) without giving that prover the ability to forge, redirect, or overspend. The user signs a canonical intent digest that binds every material parameter; the prover can produce a valid proof that executes exactly that intent and nothing else.

CR: Low OS: Yes P: Partial S: High

Private Shared State (FHE)

Enable N parties to jointly read and write shared on-chain state (balances, positions, order books, collateral pools) while keeping each party's individual data private from the others and from the infrastructure operator. This variant stores state encrypted on-chain under a shared Fully Homomorphic Encryption key, runs state transitions as homomorphic operations on ciphertexts, and controls reads through a threshold decryption committee.

CR: Medium OS: Partial P: Full S: Medium

Private Client Authentication for Institutional EOAs

Authenticate client externally-owned accounts in a way that satisfies regulatory KYC/AML requirements while preserving on-chain privacy. The institution maintains a Merkle tree of approved client EOAs; clients prove inclusion with a zero-knowledge proof plus a nullifier. Observers see neither the client's identity nor links between the client's other EOAs.

CR: Low OS: Yes P: Full S: High

Stateless Plasma Privacy

Use a stateless Plasma architecture to enable private token transfers where transaction data stays with users client-side, only commitments are posted on-chain, and validity is proven via zero-knowledge proofs. This provides strong transaction-graph privacy with L2 scalability, at the cost of moving data-availability responsibility to users.

CR: Medium OS: Partial P: Full S: Medium

Lean Ethereum

CR: High OS: Yes P: None S: Medium

Native Account Abstraction (EIP-8141)

Make every Ethereum account natively programmable by replacing the hardcoded ECDSA `ecrecover` check with user-defined validation logic at the protocol level. Transactions are processed through the regular mempool using transaction frames that separate validation from execution. The design removes bundler and relayer dependencies, enables native gas sponsorship, and unlocks privacy patterns that currently require trusted off-protocol infrastructure.

CR: High OS: Yes P: Partial S: High

ZK Proof Systems

CR: Medium OS: Yes P: Full S: Medium

Permissionless Spend Auth

Separate note ownership from spend authorization in a shielded pool, and use a recursive inner-outer circuit architecture so that multiple auth methods can coexist without fragmenting the anonymity set. Users can rotate or add auth methods without moving funds, and observers cannot tell which method authorized a given spend.

CR: High OS: Yes P: Full S: High

PQ Threat Landscape

Quantum computers threaten cryptography through two algorithms. Shor's algorithm provides exponential speedup against problems based on the structure of algebraic groups (discrete logarithms, integer factorization). Grover's algorithm provides quadratic speedup against unstructured search, effectively halving the security level of symmetric primitives and hash functions.

Quantum Algorithms

Algorithm	Speedup	Target	Effect
Shor	Exponential	Discrete logarithms, integer factorization	Fully breaks the underlying hardness assumption
Grover	Quadratic	Unstructured search (symmetric keys, hash preimages)	Halves effective security bits (e.g., 256-bit → 128-bit)
Brassard-Hoyer-Tapp (BHT)	Moderate	Collision finding in hash functions	Reduces collision resistance (e.g., 256-bit hash → ~170-bit)

Broken Hardness Assumptions (via Shor)

All assumptions that derive security from discrete-log or factorization structure are fully broken by Shor's algorithm.

Hardness Assumption	Quantum Route	Affected Schemes	Ethereum Impact
Elliptic-Curve Discrete Log Problem (ECDLP)	Shor (direct)	ECDSA, EdDSA, ECDH, Schnorr	Transaction signing (secp256k1), stealth address derivation
Discrete Log over finite fields	Shor (direct)	DSA, Diffie-Hellman	Legacy key exchange
Computational / Decisional Diffie-Hellman (CDH / DDH)	via ECDLP	Diffie-Hellman key exchange, ElGamal, Oblivious PRF	TLS, on-chain encryption, viewing keys
Pairing assumptions (Bilinear DH, q-Strong DH, SXDH)	via ECDLP	BLS signatures, Groth16, PLONK/KZG commitments	Consensus (BLS), zero-knowledge proof systems, blob commitments
Integer factorization / Strong RSA	Shor (direct)	RSA, RSA accumulators	Accumulators, RSA-based Verifiable Delay Functions

Weakened Primitives (via Grover / BHT)

These primitives are not broken but require increased parameter sizes to maintain target security levels.

Primitive Category	Security Property	Quantum Effect	Mitigation	Post-Quantum Security
Hash functions (SHA-256, Keccak)	Preimage resistance	Grover: halves bits	Use 256-bit hashes for 128-bit PQ security	Sufficient at current sizes
Hash functions (SHA-256, Keccak)	Collision resistance	BHT: reduces by ~1/3	256-bit hash retains ~170-bit collision security	Sufficient at current sizes
Symmetric encryption (AES)	Key security	Grover: halves bits	AES-256 for 128-bit PQ security (AES-128 drops to ~64-bit)	Use AES-256
Message Authentication Codes, Pseudorandom Functions, Key Derivation Functions (HMAC, HKDF)	Key security	Grover: halves bits	Double key sizes	Use 256-bit keys

PQ-Safe Foundations

Assumptions and schemes with no known quantum speedup. These form the basis for post-quantum migration.

Assumption Family	Hardness Problem	Representative Schemes	NIST Status	Notes
Lattice-based	Learning With Errors (LWE), Ring-LWE, Short Integer Solution (SIS)	ML-KEM (Kyber), ML-DSA (Dilithium)	Standardized (FIPS 203, 204)	Primary PQ replacement for key exchange and signatures
Hash-based signatures	One-time signatures + Merkle trees	XMSS, SPHINCS+ (SLH-DSA)	Standardized (FIPS 205)	Stateful (XMSS) or stateless (SPHINCS+); conservative — depends on hash security assumptions
Hash + FRI (STARKs)	Hash collision resistance	STARK proof systems	N/A	Already deployed in Ethereum L2s; PQ-safe by construction

Ethereum Layer Analysis

Layer	Today (Broken)	Migration Path	Target End State
Consensus	BLS (pairings, Dlog)	Replace fixed BLS with programmable verification; use hash-based sigs or STARK aggregation (see Lean Ethereum, Lean Roadmap)	Validators submit proofs, not signatures
Execution	ECDSA (secp256k1)	Account abstraction (EIP-8141-style); modular validation (custom sig / ZK checks)	Account = verification logic
Application	Groth16, PLONK, KZG, ECDH	Replace pairings & Dlog: STARKs, hash commitments, PQ KEMs	Hash/STARK-first stack

Application-Layer Breakages

HNDL makes privacy migration more urgent than authentication: harvested ciphertexts can never be re-encrypted, while signature forgery is at least partially remediable through emergency coordination. New designs should use PQ key exchange for any confidentiality surface that persists beyond a single session.

Ethereum inherits PQ transport encryption for some surfaces (Go 1.24 ships hybrid PQ TLS by default for HTTPS/JSON-RPC). What it cannot inherit is application-layer privacy: on-chain ciphertexts, ECDH-based key derivation, stealth address generation, ZK-proven encryption, and access pattern hiding are blockchain-specific problems with no industry equivalent.

Anonymity and Unlinkability

Surface	Broken Primitive	Solution Path	Status	Pattern
Stealth Addresses	ECDH key exchange	ML-KEM + OMR sidecar (33x ciphertext bloat; Module-LWE protocol ~66.8% faster scan)	Active research	Stealth Addresses
zkTLS	MPC/2PC on ECDH handshake	Co-design MPC with ML-KEM algebraic structure; TLS 1.3 support prerequisite	Unsolved	zk-TLS
zkID (export)	EC-based signatures	Poseidon-internal hash-based PQ sigs + STARK verification on device	Tractable	ZK KYC/ML ID
zkID (import)	NIST PQ sig arithmetization	131x gap vs Groth16; EIP-8051/8052 precompiles for direct verification	Open research	ZK KYC/ML ID

Confidentiality

Surface	Broken Primitive	Solution Path	Status	Pattern
Note discovery / viewing keys	EC-based key derivation	ML-KEM (outside ZK circuit) + OMR	Tractable	Shielding, Noir Private Contracts
Proven-correct encryption to auditor	ElGamal (EC scalar mul)	Lattice PKE outside circuit + Poseidon symmetric encryption inside circuit (detect-and-flag model)	Partial	Regulatory Disclosure
Protocol-enforced decryptability	Proving lattice PKE in-circuit	Field mismatch (q=3,329 vs BN254); simpler than full ML-KEM but still expensive	Unsolved	—

Dependencies

Client-side GPU proving: PQ privacy requires on-device ZK proofs. NTT-based PQ primitives align well with GPU architecture (client-side-gpu-everyday-ef-privacy).
STARK migration: SNARKs (Groth16, PLONK/KZG) broken; STARKs (hash + FRI) survive. See ZK Proof Systems.

Affected Patterns

Pattern	PQ-Broken Primitive	HNDL Risk	Mitigation Path
Stealth Addresses	ECDH (shared secret)	High	ML-KEM + OMR sidecar
PSI-DH	DDH / commutative encryption	Medium	Lattice-based PSI
MPC Custody	Threshold ECDSA/EdDSA	Low	ML-DSA / hash-based threshold
TEE Key Manager	ECDSA/BLS signing	Low	PQ signing in TEE
Noir Private Contracts	Barretenberg (PLONK)	High	Hash-based commitments / STARKs
Private Shared State (co-SNARK)	Groth16	Medium	co-STARK alternatives
TEE+ZK Settlement	Groth16/PLONK	Medium	STARKs
co-SNARK	co-SNARK (Groth16-based)	Medium	co-STARK
Threshold Encrypted Mempool	Pairing-based threshold encryption	Medium	Lattice-based threshold encryption
Shielding	ZK proofs (impl-dependent)	High	STARK-based shielded pools
vOPRF Nullifiers	EC-based OPRF (DDH)	Low	Lattice-based OPRF
Pretrade Privacy	Threshold encryption	Medium	Lattice-based threshold
zk-TLS	MPC on ECDH key exchange	Medium	MPC/2PC over ML-KEM (unsolved)
ZK KYC/ML ID	Underlying proof system	Medium	STARK-based proving
ZK Proof Systems	Groth16, PLONK/KZG (pairing/Dlog)	Medium	PLONK/IPA, STARKs, folding schemes
Origin-Locked Confidential Ledger	ElGamal (EC-based)	High	Lattice-based PKE
Safe Proof Delegation	Recursive ZK (if EC-based)	Medium	STARK-based recursion
PQ-safe patterns (no mitigation needed):

Private Shared State (FHE) — lattice-based
Private MTP Auth — Merkle trees, hash-based
Plasma Stateless Privacy — hash-based ZK