A verifiable delay function, or VDF, has three properties that have to hold at once. It is sequential: computing the output requires a set number of steps that must run one after another, and throwing more processor cores at it does not help. It is efficiently verifiable: once someone produces the output and a short proof, everyone else can confirm it almost instantly. And it is unique: for a given input there is one valid output, so a prover cannot shop around for a convenient answer.
The combination is what makes it useful. Plenty of things are slow to compute. The rare and valuable part is being slow in a way that cannot be parallelized away, while staying cheap to check. That is the gap a VDF fills.
Why "you cannot parallelize it" is the whole point
A normal proof of work, like the kind behind mining, is slow but embarrassingly parallel. If you want it done faster, buy more machines and split the search. That is fine for its purpose, but it means wall-clock time depends on how much hardware you can afford. A VDF removes that lever. The computation is inherently serial, so the elapsed time is roughly the same for a hobbyist and for a data center. Time becomes a thing you can actually rely on rather than a thing you can buy your way past.
Proof of work measures total effort and is parallelizable. A VDF measures elapsed sequential time and is not. One answers "how much work was burned." The other answers "how much wall-clock time genuinely passed since the input was fixed."
The construction: repeated squaring
The leading VDF designs, from Wesolowski and from Pietrzak, both rest on the same hard task: repeated squaring in a group whose order is unknown. You take an input x and compute y = x^(2^T), which means squaring x, then squaring the result, and so on, T times in a row. If you do not know the group's order, there is no known shortcut. You have to perform all T squarings in sequence, and T is the dial that sets the delay.
Verification is where the cleverness lives. Redoing all T squarings to check the answer would defeat the purpose. Instead the prover supplies a compact proof, and the verifier checks it with a handful of group operations. The two main schemes differ in proof size and how the proof is generated, but both let a verifier confirm in milliseconds what took the prover minutes or hours.
The group-of-unknown-order requirement
That "unknown order" condition is load-bearing. If you know the order of the group, you can compute 2^T modulo that order first and collapse the whole chain into a single exponentiation, erasing the delay. Two settings provide groups where the order is hard to learn. One is an RSA group, where the order depends on the secret factorization of the modulus, which means a trusted setup or a special unfactored modulus is required so nobody holds the trapdoor. The other is the class group of an imaginary quadratic field, which has no known efficient way to compute its order and therefore needs no trusted setup at all. The trade-off is the same shape as elsewhere in cryptography: avoid the trusted setup, pay in implementation complexity.
What VDFs are for
Randomness nobody can bias
The headline use is unbiasable public randomness. A common way to generate a shared random value is commit-and-reveal: everyone commits to a secret, then reveals it, and the values are combined. The flaw is the last revealer, who sees everyone else's contribution before deciding whether to reveal their own, and can withhold to nudge the result. Feed the combined value through a VDF whose delay is longer than the reveal window, and the last participant cannot compute the final output in time to know whether they would like it. The ability to manipulate the result by waiting disappears. This is a cleaner guarantee than a plain random number generator can offer when multiple distrusting parties are involved.
Decentralized timekeeping and leader selection
Because a VDF certifies that real sequential time elapsed, it can act as a rough decentralized clock and feed fair leader-election or lottery schemes in distributed systems. It has been used in blockchain consensus designs that pair proof of space with proof of elapsed time, where dedicated solvers race the squaring chain to establish ordering.
VDF, VRF, and time-lock puzzles are not the same thing
These get conflated constantly. They solve different problems.
| Primitive | What it gives you |
|---|---|
| VDF | A unique output that provably took a set amount of sequential time, verifiable fast by anyone. No secret key needed to compute it. |
| VRF | A keyed pseudorandom output plus a proof of correctness. About unpredictability tied to a key holder, not about elapsed time. |
| Time-lock puzzle | A secret that can only be opened after a delay. The creator holds a trapdoor to make it; the result is not generally unique or quickly verifiable by others. |
The cleanest way to remember it: a VRF is about who and unpredictable, a time-lock puzzle is about later and secret, and a VDF is about how long and public.
The limits
A VDF assumes an attacker cannot build hardware dramatically faster than yours at the single sequential operation. The delay is measured in your slowest honest participant's speed, and a custom chip can shrink it.
The security depends on knowing the fastest possible speed for one squaring step, because the delay you get is set by the best available hardware, not the average. An adversary with a purpose-built circuit that squares faster than everyone else effectively shortens the delay for themselves. Practical deployments account for this by assuming the fastest realistic hardware and sizing T against it, which is why serious uses often run dedicated, optimized solvers rather than commodity machines. As with every primitive we cover, the value is real and the boundary is specific, and a tool is only as good as the threat model it is matched to.