DCMS Prize Draw Code · Clause 2.2

How to run a “verifiably random and auditable” prize draw

The Voluntary Code of Good Practice for Prize Draw Operators gives you three ways to evidence that a draw is fair. One of them needs no independent person at every draw — if you can show the result is auditable. Here’s what that word actually requires, and how to meet it.

A plain-English guide for prize-draw and competition operators. Not legal advice.

What clause 2.2 actually says

The Code asks that prizes are awarded fairly, by an independent person or — and this is the part most operators miss —

“…unless winners are selected by a computer process that produces verifiably random and auditable results…” Voluntary Code of Good Practice for Prize Draw Operators, clause 2.2 (DCMS, Open Government Licence v3.0)

The same clause adds: “Operators should provide details of the mechanism used for draws on their website.” So clause 2.2 is really two obligations: pick winners by a process that is verifiably random and auditable, and publish how it works.

The three routes — and why one is cheaper

An independent person (or one supervising the draw) — recurring cost and scheduling at every single draw.
A computer process that produces verifiably random and auditable results — set up once, no per-draw human.
A certified physical drawing machine — capital cost; certification.

For a platform running weekly or instant-win draws at volume, route 2 is the only one that scales without adding cost to every draw. But it only counts if you can stand behind both words: random and auditable.

“Random” is easy to claim. “Auditable” is the bar.

Almost any operator can write “winners are selected by a random computer process” on their site. That sentence satisfies random on paper. It does nothing for auditable — because auditable means something specific: someone other than you can check the result and confirm it for themselves. A claim you can’t reproduce isn’t auditable; it’s just a claim.

The practical test: could a journalist, a disgruntled entrant, or a regulator take your published draw and independently arrive at the same winner — without trusting you, and without asking your permission? If yes, it’s auditable. If the only proof is “our system did it,” it isn’t.

A checklist for a verifiably random and auditable draw

Commit the secret before the draw. Publish a hash of the draw’s seed before selection, so it can’t be swapped afterwards.
Use randomness that didn’t exist at commit time. Draw the entropy from a public source (e.g. a public randomness beacon) whose value is unknown when you commit — so no one, including you, could have pre-picked a favourable result.
Fix the inputs up front. Publish and timestamp the prize list and the closing terms before tickets sell. This also covers clause 2.5 (no changing the end date, no cancelling for low sales, no down-valuing the prize) — because any later change is publicly visible.
Make the selection reproducible. Anyone with the published inputs can re-run the selection and get the same winner. Independent reference code in more than one language is the gold standard.
Publish the mechanism. A page describing exactly how the draw is computed satisfies the “details of the mechanism” requirement in 2.2 and your transparency obligation in 3.4.

Meet all five and “auditable” stops being a word on a terms page and becomes a fact anyone can check.

You can build this yourself

None of the above is proprietary. UVS (the Uncloned Verification Standard) is an open specification for exactly this kind of draw — a seed committed and timestamped before sales, the winner fixed by the public drand randomness beacon, and the whole result recomputable by anyone. The spec and four independent reference verifiers (JavaScript, Python, Java, C++) are open source under the MIT licence, so the verification doesn’t depend on trusting any one vendor — including us.

If you’d rather not run the cryptography and timestamping yourself, there’s a hosted layer that does the commit, the ×2 independent RFC-3161 timestamps, and the public draw record — and gives your entrants a one-click “recompute it yourself” page. Either way, the result is the same: a draw your entrants can check, not one they have to trust.

Try a live draw See a finished, recomputable draw Read the open spec (MIT)

What this proves — and what it doesn’t

An auditable draw proves the published winner follows from the published entries and the public randomness. It is honest about its limit: it does not vouch for the entry list itself — whether every entry is a real, paid participant is still on the operator (your billing and records). Clause 2.2 is about the integrity of the selection; that’s exactly what a recomputable draw secures.