Verifiable randomness for fair draws: commit-reveal vs VRF, explained

Any time software picks winners at random — a raffle, a lottery, an NFT mint order, a giveaway — the people affected face the same problem: they cannot see the random number, so they have no reason to believe it was not rigged in the organizer's favor. 'Trust us, it was random' is not verifiable, and history gives people good reason to be skeptical. The purpose of verifiable randomness is to replace that trust with proof: a draw whose fairness anyone can check afterward, without being able to predict or manipulate it beforehand. Two techniques dominate, and they solve the problem in different ways with different trade-offs.

The first is commit-reveal. It works in two phases. Before the draw, the organizer generates a secret random value and publishes only a cryptographic hash of it — the 'commitment.' Because a hash cannot be reversed, this locks in the value without revealing it: the organizer cannot change their secret later without the hash no longer matching, and no one else can predict it. Often participants contribute their own randomness too, mixed in so the organizer alone does not control the outcome. After entries close, the organizer reveals the secret; anyone can hash it, confirm it matches the earlier commitment, and recompute the winner from the combined randomness. The strength of commit-reveal is that it is simple and needs no special infrastructure. Its weakness is the 'reveal' step: a dishonest organizer who dislikes the outcome can refuse to reveal, aborting the draw. Good designs defend against this with deadlines and penalties, but the abort risk is inherent to the pattern.

The second is a verifiable random function, or VRF. A VRF is a cryptographic construction that takes an input and a private key and produces two things: a random-looking output and a proof. The proof lets anyone holding the corresponding public key verify that the output was correctly derived from the input — that it is genuinely the function's result and was not cherry-picked — while no one without the private key could have predicted it. Applied to a draw, a VRF produces a random result that comes with its own proof of correctness, so there is no separate reveal step that can be withheld: the output and the evidence arrive together. This removes the abort problem and is why on-chain systems that need randomness on demand often rely on VRFs. The trade-off is more cryptographic machinery and, in practice, dependence on whoever holds the VRF key behaving correctly or being decentralized.

The honest framing is that both make a draw auditable rather than asking for faith, and the right choice depends on the threat you care about. Commit-reveal is transparent and infrastructure-free but vulnerable to a sulking organizer who aborts; a VRF removes the abort but adds machinery and a key to trust. In either case, binding the result — the commitment, the reveal, or the VRF proof — with a signature that stays verifiable over time strengthens the audit trail; a post-quantum signature (Dilithium-2, NIST FIPS 204) keeps it checkable for the long haul, resistant to known classical and quantum attacks per NIST, not unbreakable. And a caveat worth stating plainly: verifiable randomness proves the draw was fair and unmanipulated; it does not prove the entrant list was complete or honest, which is a separate control. But for the specific, common question — 'was this winner picked fairly, or was it rigged?' — these techniques turn an unanswerable act of faith into something anyone can check for themselves.