Quantum HubTransparent
The construction requires no trusted setup. There are no secret initialization parameters whose compromise would let an adversary forge proofs; verifier inputs are public. This is a property of the proof construction.
Foundations
Foundations
Post-quantum security was not added to STARKs. It shaped them from the start.
StarkWare's founders published the STARK proof system in 2018, building it on cryptographic hash functions rather than elliptic curves. At the time that choice carried a performance cost and no competitive advantage. It was made because the security properties were the right ones.
Starknet, launched years later, inherited those properties by design. The performance cost has since been engineered away. The security choice has never needed revisiting.
The proof system
What the proof system and the account model put in place
Three structural properties. Architecture covers how they work in practice.
- Transparency
- No trusted setupThe STARK proof system does not require secret setup parameters or a ceremony whose participants must be trusted to discard them. That removes one long-lived assumption from the security model.
- Sources
- Hash-based proving compilation
- No elliptic-curve hardness assumption in the proving layerThe proof system uses hash-based Merkle commitments and Fiat-Shamir to compile its protocol, rather than relying on elliptic-curve hardness in the proving layer. That avoids the assumption targeted by Shor's algorithm there.
- Sources
- Native account abstraction
- Programmable validation for a new account implementationStarknet account contracts can define validation logic, so a new account implementation can adopt a post-quantum signature verifier without changing the proving construction.
Crypto agility
Why the work is happening now
NIST published FIPS 203, FIPS 204 and FIPS 205 in August 2024, standardizing ML-KEM, ML-DSA and SLH-DSA. NIST IR 8547 is separate draft transition guidance, useful for planning but not a deadline set by those publications and not a determinant of Starknet's schedule.
No date for a cryptographically relevant quantum computer is known. Migration work is therefore sequenced as engineering rather than timed against a forecast, and its status is tracked publicly per component rather than asserted as a whole.
Early migration is an engineering project you schedule; late migration is a coordination problem you inherit.Read the threat and standards context
The record
The record
Dated public events, ordered by date rather than by significance. Component-level status lives in Migration.
2018
The STARK proof system is published
StarkWare's founders publish the STARK proof system: no trusted setup, no elliptic-curve hardness assumption in the proving layer.
June 2020
StarkEx becomes the first STARK‑based scaling solution in production on Ethereum Mainnet.
13 Aug 2024
NIST publishes the first FIPS post‑quantum standards
NIST publishes FIPS 203, 204 and 205, standardizing ML-KEM, ML-DSA and SLH-DSA.
12 Nov 2024
NIST IR 8547 is published as draft guidance
NIST IR 8547 published as Initial Public Draft transition guidance.
November 2025
S‑two becomes Starknet's production prover.
S-two, StarkWare's hash-based next-generation STARK prover, goes live on Starknet Mainnet.
February 2026
BIP‑360 reaches the Bitcoin proposal repository
BIP-360 (Pay-to-Merkle-Root) merged into the Bitcoin Improvement Proposal repository.
July 2026
BLAKE2s replaces Pedersen for the Starknet OS program and config hashes.
Starknet v0.14.3 replaces Pedersen with a BLAKE2s-256-based hash construction for the live OS program and configuration hashes.
The 2018 paper
Scalable, transparent, and post-quantum secure computational integrity
Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, Michael Riabzev · Cryptology ePrint Archive, Paper 2018/046 · 2018
What the proof system assumes
A proof system's security rests on a hardness assumption: a mathematical problem believed too difficult to solve. Most zero-knowledge systems in production, including Groth16 and PLONK with KZG commitments, assume the hardness of problems on elliptic curves. Shor's algorithm, run on a sufficiently large quantum computer, solves exactly those problems, which is why elliptic-curve cryptography appears on post-quantum deprecation lists.
STARKs assume only that cryptographic hash functions are collision-resistant. No known quantum algorithm meaningfully breaks that assumption. The strongest generic quantum attack, Grover's algorithm, affects preimage and unstructured-search margins and is addressed by sizing security parameters accordingly, the approach also taken in hash-based post-quantum designs such as NIST's SLH-DSA.
This is not a patch or a parameter choice. It is the foundation of the proof system, and it is a property of the proving layer rather than a claim about every cryptographic component in Starknet.
Read the threat and standards contextScalable
The construction was designed for succinct verification of large computations. Its practical production record is separate evidence from the cryptographic assumptions that support the proof system.
Hash-based compilation
Merkle commitments and Fiat-Shamir place cryptographic assumptions in hash functions rather than elliptic-curve hardness in the proving layer. The resulting security boundary still depends on selected hashes, parameters, protocol details, and implementation.
What the property does not cover
The paper describes a proof system. Starknet’s native account abstraction gives a new account implementation programmable validation, but existing accounts, wallets, custody, keys, and adoption require separate migration work. Migration tracks the other surfaces.