Written by Pablo Gómez
Founder & CEO at Metlabs · Reviewed on October 11, 2026
A zk-STARK uses no pairings or elliptic curves: its security rests on a collision-resistant hash function and on proximity tests to Reed-Solomon codes via FRI (Fast Reed-Solomon IOP of Proximity). The computation is expressed as an execution trace plus algebraic constraints (AIR) and committed with Merkle trees of hashes. Proving time is quasi-linear and verification poly-logarithmic, with the trade-off of proofs ranging from tens to hundreds of kilobytes. It was introduced in 2018 by Eli Ben-Sasson, Iddo Bentov, Yinon Horesh and Michael Riabzev (Cryptology ePrint 2018/046), with the FRI support presented at ICALP 2018.
It removes the ceremony risk: there is no toxic waste to guard or destroy. It also offers readiness against quantum computing, since it does not rely on curve assumptions vulnerable to Shor's algorithm. It is the natural choice when transparency and cryptographic durability outweigh the cost of publishing the proof on-chain, a relevant criterion for market infrastructure expected to last decades.
StarkWare built its stack on STARKs: the StarkEx engine, used by dYdX v3, Immutable X and Sorare, and the general-purpose network Starknet, with the Cairo language. Recent variants such as Circle STARKs, over the Mersenne-31 field, aim for greater proving efficiency. Compared with the zk-SNARK, it shares the use for scaling and identity, but drops the trusted setup and grounds its security in the hash function and Merkle trees.
Also known as
- zkSTARK





