How to run a fair draw for your prize competition

What the rules say about winner selection

The DCMS Voluntary Code of Good Practice for Prize Draw Operators asks that prizes are awarded fairly, by an independent person or under their supervision, unless winners are selected by a computer process that produces verifiably random and auditable results. It also says entries should have an equal chance of winning each available prize, whether they came through the paid or the free route, and that operators should give details of the draw mechanism on their website.

The code is voluntary, but it is the clearest public standard for a fair prize draw. See our summary of the DCMS code. Notice the phrase "verifiably random and auditable". That is the bar to aim for.

Put every entry in the same pot

Before you worry about randomness, get the entry list right. A fair method applied to an unfair list is still unfair.

• Include free postal entries and paid entries in one list. The free-entry route must have equal odds. See the free entry route explained.
• Close entries at the advertised time. The DCMS code asks operators not to change the end date or cancel a draw because sales were low.
• Remove only entries that are invalid under your published terms, such as a wrong answer to the skill question or an entrant under 18, and record why.
• Freeze and save the final list, then work out a fingerprint (hash) of it so any later change would show.

Random number generation

The winner is an index into your entry list, picked by a random number. Where that number comes from matters.

• A normal programming function such as a basic random call is not designed for draws. It can be predictable if someone knows the seed.
• A cryptographically secure generator on your own server is much better, but nobody outside your business can prove you did not rerun it until you got the result you wanted.
• An independent source such as random.org. It is a third-party service, so using it removes the suspicion that you picked the number yourself.

Whichever you use, make the mapping from number to winner a public, simple rule. For example, "the winning ticket is the one at position N in the frozen list, ordered by ticket number". Without that, a random number proves little.

Commit-reveal: proving you did not cheat

Commit-reveal is a simple trick that makes a draw provable. You commit to something before the draw, then reveal it afterwards so anyone can check the two match.

1. Commit. Before the draw, publish the fingerprint (hash) of the frozen entry list and of any secret value you will use. A hash is a one-way function: it identifies the data without revealing it, and any change to the data changes the hash.
2. Draw. Get the random number from your chosen source, ideally after the list is frozen, so you cannot tailor the list to the number.
3. Reveal. Publish the full entry list, the secret and the random number. Anyone can recompute the hash, confirm it matches what you published earlier and apply the stated rule to find the winner.

This proves you did not alter the list after seeing the number, and did not choose the number to suit the list. Niche's provably fair draws use commit-reveal with random.org, and the whole process is logged, so you do not need to build it yourself.

Commit-reveal shows the draw was not changed after the commitment. It does not stop you from adding fake entries before the list is frozen. Keep your entry records clean and be ready to show them.

Live draws

A live draw lets entrants watch the result happen. Many operators stream the draw on social media at a set time. Live draws build trust, but they do not replace a verifiable method. A camera cannot show that the random number was fair.

• Announce the date and time in advance and stick to it.
• Show the frozen entry list or its hash, the random source and the winning ticket on screen.
• Have a second person present, ideally independent of the business.
• Save the recording and keep it with your draw records.

Niche has a live draw console that runs the steps in order and shows entrants the commit, the random number and the winner, so you can stream a draw without improvising.

Publishing results

The DCMS code does not require you to publish winners. Rule 8.28.5 of the CAP Code does say you must publish or make available information that shows a valid award took place. After each draw, publish:

• The winning ticket number and the prize.
• The date and time of the draw.
• The committed hash, the revealed data and the random number, so anyone can verify.
• The winner's first name and county, if they have agreed. Check this against your GDPR position and your terms before naming anyone.

Then pay out promptly. The code asks operators to give the winner the advertised prize, or a reasonable cash alternative, promptly. Before release, run your age and identity check.

A fair draw is one part of running a trustworthy business. See how to start a competition website for the rest, and Niche pricing for what is included.

This is general information, not legal advice. Take advice from a solicitor before you launch.

Frequently asked questions