'01 Big Raffle  ·  Draw day

How a draw day runs.

The same six steps every week, at the same times. Every time below was set before the draw, and none of them moves on the day. If a step cannot happen when it should, we stop and reschedule.

The question this page answers

“How do I know it was not rigged?”

We publish the whole ticket list hours before the winning number exists. Then anyone can run the draw again themselves and land on the same name.

12:00 AMThe list is lockedPublished in full, with a short code that changes if a single ticket moves.
4:00 PMA public number appearsFrom a service run by 17 organisations, on the other side of the world from us.
AfterAnyone can redo itSame two files, same winner. A rigged result cannot survive that.

Times are Manila. This describes each weekly draw and the grand draw on 5 December.

The day at a glance

  1. 9:00 PM Buying deadline
  2. 11:59 PM Entries close
  3. 12:00 AM List frozen and published
  4. 12 AM–5 PM Payment checking pauses
  5. 4:00 PM The draw
  6. 5:00 PM Record published
  • a deadline you act on
  • nothing may change
  • something is published you can check
  • the draw itself

Every step

9:00 PMnight before

Buying deadline

The last time we tell people to pay. Mark or Bits still has to open the payment, match it to an order and issue the ticket, so the advertised deadline sits three hours ahead of the cut-off to give them room.

Buyers
11:59 PMnight before

Entries close

Our two payment verifiers stop. Whatever is verified by now is in this draw. Whatever is not moves to the next one, automatically, with nobody deciding anything.

Mark & Bits
12:00 AMdraw day

The list is frozen and published

One click takes every verified ticket, gives the whole list a short code, and puts it online. From this moment the list is fixed. Add or remove a single ticket and the short code changes, the two stop matching, and the file stops being served at all.

The same file names the random number this draw will use, hours before that number exists, and carries one that already existed — so the moment it was written can be checked rather than taken on trust.

See the page that does it
The internal page used to freeze a draw: a dropdown reading Draw 1, the entries-close and draw times filled in automatically from the published schedule, a box for the prize list, and two buttons reading Check first and Freeze and publish.
The page that does it. The draw is picked from a dropdown, the times fill in from the published schedule, and Check first shows what would be frozen before anything is. Two of our treasurers can run it, so no single person is required.
See what gets published
The published ticket list page: a large ticket count, the list fingerprint, the time it was frozen and the time entries closed.
What that produces, a minute later. The count and the short code are worked out by your browser from the downloaded file, so the page reports what the file contains rather than a number we stored. This is the sample list; each real draw gets its own.
Published
12:00 AMto 5:00 PM

Payment checking pauses

For seventeen hours nobody verifies a payment, so nothing can enter or alter the list while the draw is running. People can still buy. Those tickets are checked after 5:00 PM and join the next draw.

See what a buyer is shown
An amber warning above the buy form reading: Buying now? You are in draw 2, not today's. It explains that verification is paused from midnight until 5:00 PM so the list for draw 1 cannot change, and links to that list.
And the buyer is told directly, at the point of paying. The notice changes itself on draw day: it names the draw they are joining, so nobody pays on a draw morning believing they are in that afternoon’s draw.
See it on the public page
The public raffle page with the cut-off explainer open, showing the two deadlines, the draw-day verification pause, and the schedule of draw dates.
The same pause, stated on the public page every buyer sees, alongside the full schedule of cut-offs and draw dates. Every date here is public.
Mark & Bits
4:00 PMthe draw

The draw

The whole thing takes about a minute, and it is the same three moves every week.

1 The number arrives. At 4:00 the round we named at midnight publishes its value. We read it off two separate websites and check they say the same thing.
2 It gets mixed with the list’s short code. That is the code we published at midnight, the one that changes if a single ticket moves. It and the number are scrambled together into one long code.
3 The long code deals the tickets out again. Now the list itself comes in: the code shuffles all of it into a new order, and whoever lands on top wins.

Nobody chooses anything at any point. Give the same two files to a stranger and they land on the same ticket, which is the whole reason we publish them. See those three moves worked through with real tickets ↓

See the console at that moment
The draw console showing the first-place ticket code in large type, the runner-up ranks beneath it, and the final seed and beacon value.
The console at the moment it answers, shown here on the published sample pack. The winning code, then the long code and the exact random number it came from — the two things anybody needs to repeat it.
Watched live by the observers
5:00 PMafter

Checking resumes, the record is published

Verification restarts, into the following draw. The completed record goes online, and this draw's ticket list stays at its own permanent address so the draw can still be checked months later.

Published
The first thing people ask

How is the winner actually picked?

What you need to know first A draw uses two things. The ticket list, locked and published at midnight. And one number, which arrives at 4:00 PM from a service outside the batch.

People worry that we pick someone we like. That is fair. If we read out a name, you are taking our word for it. A livestream settles it no better: someone once rigged a giveaway on camera by showing a fake result from a well-known number-picker site, and the people watching could not tell.

So we took the choice out of our hands. Those two things decide the winner between them, and you can check that for yourself: there is a button further down this page that runs the whole draw on your phone and shows you who won.

The whole draw, on one picture
THE TICKET LIST locked at midnight its short code the list itself short code THE NUMBER arrives at 4:00 ONE LONG CODE 87ae2a62…0028 A RUN OF NUMBERS 27, 38, 4, 9, 34… THEY SHUFFLE THE LIST one swap per number WHOEVER IS ON TOP wins the list is used twice, for two different jobs

Follow the two lines out of the top box. Its short code goes left, into the mixing. The list itself goes right, all the way down, because it is the thing being shuffled. Those are two different jobs, and it is the part people usually miss.

1
Two things go in One we lock the night before. One that arrives from outside on the day.
The frozen list Every ticket in this draw, in the order they were issued. Published at midnight with its own short code, so any change to it shows.
The random number The value the public service puts out at 4:00, for the round we named at midnight. It comes from strangers who have never heard of our raffle.
2
They become one long code The short code of the list, and the number. Those two get scrambled together into one long code. Feed in the same two and you always get the same result back; change either by a single character and it changes completely.
One code, worked out from both
the real sample files 87ae2a6260a7b7ef6e039327d31c1006250038dcc272c14387441782a0430028
the same files, one character of the random number changed 52199360ee49b65a0d4ad3b13fffc73ac7f53ce0d138edd49b83fa3ce6047afe
Real values, which you can reproduce yourself. You cannot nudge this code towards a friend. Either you have the exact files, or you get a completely different answer.
3
The code becomes a list of numbers, and those numbers move the tickets The long code unpacks into an endless run of numbers. You read them one at a time, and each one says which two tickets to swap. Nobody's hands are anywhere near it.

It is a hat draw. All 1,003 tickets go in a hat. Pull one out for first place, pull the next from whatever is still in there, and keep going. Nothing goes back in.

A hat filled with identical folded tickets. One ticket is in the air just above the opening, and three already-drawn tickets lie flat beside the hat.

Every ticket still in the hat has the same chance of being the one you pull — that is what makes it fair. The method is not new; it was written down in 1938, for people doing it by hand. The code lays the tickets in a row and swaps them into place instead. Here it is on six.

Watch it happen on six tickets
start The tickets in the order they were bought.
ABCDEF
step 1 Start at the last place, position 6, holding F. The number can land anywhere from 1 to 6. It says 4, so F and D trade places.
ABCFED
step 2 Back one, to position 5, holding E. Now the number can only land from 1 to 5. It says 5, which is where E already is, so E stays.
ABCFED
step 3 Position 4, holding F. The number can land from 1 to 4. It says 1, so F and A trade places.
FBCAED
step 4 Position 3, holding C. The number can land from 1 to 3. It says 1, so C and F trade places.
CBFAED
step 5 Position 2, holding B. Only 1 or 2 left to land on. It says 2, so B stays. Done.
CBFAED
winner C ended up first, so C wins. Nobody chose C — it started third and the numbers moved it there. With 1,003 tickets it is the same thing, 1,002 times over.
why Twice, nothing moved. That has to be possible. A ticket needs the same chance of staying put as of being moved — take that away and tickets bought early would finish near the top more often than the rest.
Where those numbers come from
Step one: the long code becomes ordinary numbers

Scramble the long code together with a counter — 0, then 1, then 2 — and each time you get 32 fresh numbers. That is the endless page. Ours begins:

105   242   168   167   148   13   241   32 …
Step two: turn each one into a ticket position

Those run 0 to 255, but with 40 tickets we only want 1 to 40. So we cut each one down to a number between 0 and 63, and throw away anything that lands over 39:

105→ 26keep   swap with position 27
242→ 60too big, throw away
168→ 42too big, throw away
167→ 41too big, throw away
148→ 37keep   swap with position 38
13→ 3keep   swap with position 4

Throwing them away is what keeps it fair. 40 goes into 256 six times with 16 left over, and those 16 leftovers would hand the first 16 tickets an extra chance. Dropping them instead costs a fraction of a second and leaves every position exactly as likely as every other.

Imagine a book filled with millions of random digits, the same in every copy. The long code tells you which page to open. Everybody who opens that page reads the same digits in the same order. Open a different page and you get completely different digits.

Our page starts: 69  242  168  167  148  13  241  32 …

Now you shuffle exactly the way you would shuffle cards, except that instead of picking at random with your hand, you read the next number off the page.

That is the whole method. Every swap is decided by the next number on the page, and the page was decided by the frozen list and the number from outside. Anyone with the same two files opens the same page, makes the same swaps, and lands on the same winner.

One detail worth having: when the page hands over a number that is too big for the tickets left, we throw it away and read the next one, rather than folding it back into range. Folding it back is what would make the low-numbered tickets win slightly more often.

4
Whatever lands on top wins First prize to first place, second to second, for as many prizes as the draw has.
Position 1 BF-H33Z-YT2G   takes prize one

Every ticket is equally likely to be the one on top. Buying early puts you higher in the frozen list, and nowhere else. The list is locked before the random number exists, so no position can be aimed at, and the shuffle treats every position alike.

And this is the part that settles it. Anyone can download the two published files and run the draw again themselves. For a rigged result to hold, those files would have to produce the winner we announced. They would produce a different one, in front of everybody.

The public check page with the genuine sample files loaded, showing a green tick and the words Recomputed, the result above came from your files.
The real files. The page recomputes the draw and lands on the same winner.
The same page with one ticket removed from the list, showing a red pool mismatch error with the fingerprint the file should have had and the one it actually has.
One ticket removed. The short code stops matching and the check refuses, showing both.

Real output from the sample files, which stay up all season on the check page. You can try this now, without waiting for a draw.

The one that sounds impossible to answer

But is it actually random?

What you need to know first The winner is decided by shuffling the frozen ticket list, using a number that arrives from outside on the day. So the fair question is whether the shuffle gives everyone the same chance, or whether some tickets come out on top more often than they should.

One honest thing first. Nobody can prove a single number is random. Any number looks like any other one. So instead of claiming that, we test the things that can be tested, and publish what came back.

Do not take our word for any of this

Us telling you our own tests passed would prove nothing. So press the button and your own device will download our published files, work everything out, and check our answer against what we wrote down beforehand.

Try it yourself

This is the real draw, running on your phone. Nothing is sent anywhere. Press the button and see who wins.

This comes from outside, at 4:00 on the day. Strangers make it.
Why we throw some numbers away

Imagine sharing 256 sweets between 40 children. Everyone gets six, and sixteen sweets are left over.

Hand those sixteen spares to the first sixteen children and they end up ahead of everybody else. That is what the easy way of picking tickets does:

Ticket 7one of the first sixteen seven chances
Ticket 30one of the other twenty-four six chances

Across all forty tickets:

the easy way — the taller ones get picked more often, every draw, all season
what we use — all forty the same height, all season

So we put the spares back. When one of those leftover numbers turns up we ignore it and read the next one. Everyone gets six. Nobody gets extra.

You would never catch it by eye. Here are twelve picks from each way:

the easy way
26   3   9   8   29   14   2   33   30   38   14   15
what we use
27   38   4   9   34   2   9   28   17   3   31   32

Both look like nonsense, and that is the trouble. The unfairness never shows in the numbers you can see. It shows up over hundreds of draws, and by then somebody has already won.

The next thing people ask

Where does the number come from?

What you need to know first At midnight we lock and publish every ticket in the draw. The list alone decides nothing. Something has to pick from it, and that something must be outside our control.

The draw needs a number, and it has to come from somewhere outside this batch. A computer here could make one up, but then we made it, and you would be back to taking our word for it.

So we take one from outside, from a service that has published a fresh number every few seconds since 2019, for anyone in the world who needs one. It runs for its own reasons, on the other side of the world, for anyone who needs a number.

First, what the public number service is
Its name
drandRun by the League of Entropy, a group set up in 2019 specifically so that anyone needing public randomness has somewhere impartial to get it.
Who runs it
17 organisationsCloudflare, the Ethereum Foundation, Kudelski Security, Protocol Labs, EPFL, University College London and the University of Chile among them. Different countries, different owners, no shared boss.
How often
Every 3 secondsIn public, since 2019. The round a draw uses is the one that lands at 4:00 PM that day.
Who can bend it
None of themThe key is split into 17 pieces, one each. It takes a group of them working together to make a single round.
How 17 strangers make one number together

The key is split before anything runs. When the network was set up, the members jointly generated one key and split it, so each member ends up holding a fragment and nobody, at any point, holds the whole thing. There is no master copy sitting somewhere.

Each round is signed by many. Every three seconds the members each sign the next round number with their fragment. Enough fragments combine into a single signature, and that signature is hashed into the random value. A minority of members going offline, or going bad, changes nothing.

Each round has exactly one right answer. A member who tried a different value would have it rejected by everyone else, so the only thing they can do is help produce the real one. The number can be produced, or the round can be missed. Those are the only two outcomes.

Anyone can check a value is genuine. The network published its collective public key years ago. Any round’s value can be verified against it, which is why we can read the number from two independent websites and know we are looking at the real one rather than something either site invented.

None of this is ours. It runs whether or not we hold a raffle, it was running long before we planned one, and it will keep running afterwards. We name a round and wait.

But a new one comes out every three seconds. Could you not just keep trying?

That is the right thing to worry about. If we grabbed whichever number happened to be current, we could run the draw, look at who won, wait three seconds, run it again, and keep going until we liked the answer.

The same draw, run three seconds later
  • 4:00:00→BF-X1M8-P506 wins
  • 4:00:03→BF-H33Z-YT2G wins

Real codes. We ran the engine over the sample list and changed one character of the random number. Both runs check out, so from outside you could not tell which one we were supposed to use.

Where our file sits in it — draw 1 as the worked example
Before midnight · already published Round 31,853,683 6a8b2e2cfb7cebf6… A number the world could already see. We copy it into our file. This one takes no part in the draw.
↓   the service publishes a new number every 3 seconds — about 19,000 of them between these two rows
4:00 PM · did not exist yet Round 31,901,812 unknown to everyone, including us, at that moment We write down only its number at midnight. Its value appears at 4:00, and that value is the one that goes into the draw.

Our file names both, so it had to be written after the first appeared and before the second did. That pins it inside a window neither we nor anyone else can widen, and it does so without anyone trusting our clock or our word.

So we name which one, in advance. Sixteen hours before the draw we publish the exact round we will use, while its value still does not exist. There is no shopping around: one number is named, and everyone works out the same winner when it appears.

The last thing people ask

How do you know the list did not change?

What you need to know first At midnight, before the winning number exists, we publish the full list of tickets in the draw. Everything rests on that list not changing afterwards, so it needs to be checkable rather than promised.

At midnight the whole ticket list gets turned into one short code. (The technical word for it is a fingerprint, and that is all it is.) Publish the code in the morning, and anyone can make it again from the list in the afternoon. If the two match, it is the same list.

40 tickets cc6a5a29e2cb0748…
one ticket taken out 31aa2abe05264da4…
one ticket slipped in 4a84e189b6140698…

Real values from the published sample list. Touching one row out of forty changes every character, and there is no way to work backwards from a code to a list that produces it. So a list that still matches its morning code is the list that was frozen.

Whatever goes in, 64 characters come out
The single letter a 1 byte ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb
Our 40-ticket sample list 497 bytes cc6a5a29e2cb0748122d11ddd041d970a9bbf6baf92f24d6ebae4a32368a366f
A 100-megabyte file 100,000,000 bytes a993f8c574e0fea8c1cdcbcd9408d9e2e107ee6e4d120edcfa11decd53fa0cae

Real values you can reproduce. The code is always the same length, it always comes out the same for the same input, and it runs one way: from a code alone there is no route back to the list that made it. So publishing the code in the morning gives away no part of the list, and still catches one that changed.

If you want the actual maths

The code is a SHA-256 hash. It is a published public standard, written down by the US National Institute of Standards and Technology as FIPS 180-4, and it is the same function that protects the padlock in your browser, checks that software downloads are genuine, and gives every change in Git its name.

Mechanically: the file is chopped into 512-bit blocks. A 256-bit running value starts from a fixed constant and each block is stirred into it over 64 rounds of additions, bit rotations and exclusive-ors, using constants taken from the cube roots of the first 64 prime numbers. What falls out at the end is 256 bits, which we print as 64 hexadecimal characters.

It runs one way because the stirring throws information away: a 100-megabyte file and a single letter both leave 256 bits behind, so most of the input cannot still be in there. Reversing it would mean searching roughly 2256 possibilities. Written out, that is a 78-digit number, in the same territory as the count of atoms in the observable universe. Nobody has ever found two different files with the same SHA-256, and people have been trying since 2001.

Run it yourself. Download the list, then on a Mac or Linux machine type shasum -a 256 pool-01.csv, or on Windows certutil -hashfile pool-01.csv SHA256. Compare what it prints with the code we published that morning. You are not taking our word for the method either: it is the same command, on the same standard, that the rest of the internet uses.

The site checks this for you. If the two ever disagreed, the ticket list would stop being served at all rather than serve a different one.

Who does what

Mark Palo & Bits Tolosa Verify payments up to 11:59 PM, then stop until 5:00 PM. They are the only two with access to the bank account, and neither has access to the database.
Toffer Lorenzana Drives the draw console on the day. He can freeze the list from the same admin page Mark and Bits can, and he cannot change the result once the list is published.
College AB ’86 Sent the list link and its short code the moment the list is frozen, and replies quoting that code back. Their reply carries its own time stamp, so a second batch holds its own record of the midnight list. They also watch the draw and sign the minutes.
The random number Comes from a public service outside the batch, publishing a fresh value every three seconds. Nobody here can influence it or know it early.