LuckPicker

Running a Giveaway With 5,000 Entries

At this size the draw is trivial and the entrant list is the entire problem.

Past a few thousand entries you can no longer eyeball the list, so every fairness failure moves upstream of the draw — duplicates, bots and late entries decide the winner long before the picker does.

At five thousand entries the draw itself is trivial — paste, press, done. Everything that can actually go wrong has moved upstream into the list, and none of it is visible once the list is pasted.

The work is list hygiene, a fixed closing time, and a result somebody can check afterwards. In that order.

Duplicates decide the winner before the draw does

A list with duplicates is a weighted draw that you did not intend. Someone appearing three times has three times the chance, and at this scale you cannot see it happening — a five-thousand-line list scrolls past faster than anyone reads.

Whether duplicates should be removed depends entirely on your rules. If the promotion said one entry per person, they are errors and must go. If it said an entry per share, they are legitimate tickets and removing them is the unfairness.

Either way the decision has to be made and stated before the draw, because deciding afterwards means deciding with the outcome partly visible. Deduplicate case-insensitively and with whitespace trimmed, and be aware that this still misses the same person entering under two handles.

  • State the entries-per-person rule before entries open.
  • Deduplicate case-insensitively, with leading and trailing whitespace stripped.
  • Accept that two handles belonging to one person are undetectable.
  • Report the before and after counts publicly — 5,143 entries, 4,802 after deduplication.

Bots and the entries you did not want

Any giveaway large enough to be worth entering attracts automated entries. They are usually detectable in aggregate rather than individually: accounts created the same week, near-identical entry text, entries arriving in tight clusters at machine speed.

The honest position is that you will not catch all of them and should not pretend otherwise. What you can do is state a rule — accounts must predate the giveaway, entries must be from accounts with some history — and apply it uniformly before the draw rather than to the winner afterwards.

Applying a rule only to the winner is the failure mode that generates real complaints, because it is indistinguishable from redrawing until you like the result. If the rule is worth having, it applies to the whole list.

The closing time has to be a moment, not a day

"Closes Friday" is not a closing time. It is a source of dispute with entrants in other time zones, and it leaves you deciding whether a Friday-evening entry counts while looking at the list.

State a date, a time and a time zone. Freeze the list at that moment, publish the frozen count, and draw from that. Entries arriving afterwards are not eligible, which is much easier to say when you said it in advance.

Publish the list itself where practical. At five thousand entries a full list is unwieldy, and publishing a count plus a hash of the list gives the same verification property in one line — anyone who has the list can confirm it matches.

A publishable closing record

  • Closed: 2026-09-05 18:00 UTC.
  • Entries received: 5,143. After deduplication: 4,802.
  • Seed committed before entries opened: hash published in the announcement post.
  • Winner: line 3,187 of the frozen list.

Making the result checkable

At this scale somebody will ask, and "I used a random picker" is not an answer. The cheapest strong answer is a seeded draw with the seed committed in advance: publish a hash of the seed before entries open, publish the seed and the frozen list afterwards, and anyone can reproduce the result.

Committing before entries open rather than after they close matters. A seed chosen with the entrant list visible could have been searched for, and the hash is what removes that possibility.

The whole protocol is two extra posts and it converts every future accusation into a two-step verification anybody can perform. For a prize of real value that is a good trade.

Frequently asked questions

Should I remove duplicate entries?

It depends on your stated rules. One entry per person makes them errors; one entry per share makes them legitimate tickets. Decide before the draw.

How do I deduplicate reliably?

Case-insensitively with whitespace trimmed. Be aware that one person using two handles is undetectable by any method.

What do I do about bot entries?

State a rule in advance — account age, some history — and apply it to the whole list before the draw. Applying it only to the winner reads as a redraw.

Why does the closing time need a time zone?

Because 'closes Friday' leaves you deciding whether a Friday-evening entry counts while looking at the list, which is a decision made with the outcome partly visible.

Do I have to publish all five thousand names?

No. Publishing the count plus a hash of the list gives the same verification property, and anyone holding the list can confirm it matches.

Is a screen recording enough evidence?

It shows a draw happened, not that it was the first one. A committed seed is stronger and takes less effort.

When should I commit the seed?

Before entries open. Committing after they close still allows a search for a favourable seed among the entrants you can see.

What if the winner does not respond?

Have the rule published before the draw — a deadline and what happens after it. Deciding afterwards looks like changing the winner.

Tools for this job

Background reading

← All use cases