A technical bet used to make some STARK proofs smaller. Its strongest version was disproved in 2025.
The idea: A STARK verifier can't read the prover's whole table, so it checks, with a few random samples, that the committed data is close to a well-behaved polynomial (FRI). How many samples it needs depends on a math question: how far from well-behaved can cheating data be and still pass? Proven answers need more samples. Conjectured, more optimistic answers allow fewer, making proofs smaller. In 2025 the most optimistic answer was shown to be false, so some parameter choices were safer on paper than in reality.
Why it matters: Some STARK systems now need slightly bigger proofs to stay provably safe.
On the map: strongest form disproved (Nov 2025), many STARKs rely on a weaker, still-unproven form
STARK proofs check that committed data is close to a low-degree polynomial using the FRI protocol[1] (or successors like STIR and WHIR)[2, 3]. Soundness is proven up to a certain distance. To keep proofs small, many deployments chose parameters that relied on stronger, conjectured "proximity gap" bounds[4].
In November 2025 several independent papers (by Diamond and Gruen, by Crites and Stewart, and by Ben-Sasson, Carmon, Haböck, Kopparty and Saraf)[5, 6, 7] disproved the strongest, "up to capacity" form of these conjectures, showing some parameter choices previously treated as safe are not. A weaker form, up to the list-decoding bound, remains unproven.
Projects can move to proven parameters, which roughly doubles proof size, or stay in the still-conjectured region at a cost of a few percent. No deployed system was reported broken. The Ethereum Foundation's Proximity Prize helped drive the work[8].
leanVM's design targets security without relying on any proximity-gap conjecture[9].
If any of these breaks, this breaks too.
If this breaks, these break with it.