How the winner is chosen — the full process, maths and all

This is the exact rule — version 1.0 of the Fair Draw Standard — that picks the winner of every certified draw. It is fixed and identical for every operator: nobody gets a different rule, and nobody (including us) can change it for a draw that's already sealed. What follows is the whole thing, maths included, with a worked example whose numbers you can recheck with any SHA-256 tool. If you find anything that doesn't add up, we want to know.

Step 1 — the entry list is sealed

When entries close, every entry (its ticket number, order reference and entrant name) is run through SHA-256 — a standard fingerprint function used across banking and the web. Change one character of the input and the fingerprint changes completely. The entry fingerprints are then paired up and fingerprinted again, and again, until a single 64-character code remains — the seal (a “Merkle root”). That seal is published before the draw. Adding, removing or editing any single entry afterwards would change the seal, visibly.

Step 2 — a secret ingredient, committed in advance

At the moment of sealing we also generate a random secret — the “salt”, 64 hexadecimal characters. We keep the salt secret for now, but we immediately publish its fingerprint: SHA-256 of the text FDR-SALT-COMMIT| followed by the salt. This is called a commitment, and it does two jobs. It stops anyone on the public blockchain network from checking whether an upcoming block would favour them — without the salt, they can't compute the outcome. And it stops us from changing the salt afterwards — the salt we later reveal must match the fingerprint we committed, or no certificate is issued. Neither we nor the network alone controls the result.

Step 3 — the draw is triggered, once

At the advertised draw time the operator presses the trigger — once. The press is timestamped and recorded. There are no re-rolls: whatever number comes out is the result.

Step 4 — the winning number's raw material comes from outside

The “seed” is the identifying hash of the first block on the public blockchain network's main chain whose timestamp is strictly after the trigger. That block hadn't been created yet when the trigger was pressed — it's produced by a worldwide network that nobody, including us, controls. We then wait ten further blocks before certifying, so the block is settled beyond dispute. Because the rule says “the first main-chain block after the trigger time”, everyone who checks arrives at the same block.

Step 5 — combining the two ingredients

The revealed salt and the seed block hash are joined with a | character and fingerprinted: combined = SHA-256(salt | seed block hash). Worked example — with salt aaaa…a (64 a's) and seed block hash bbbb…b (64 b's): the commitment is 4fa8d272a5ecec06922e5fb1fed28ffe3e9e81286b993c7d51502889b67fc98f and the combined hash is dfb484fa87938837327c83b4a7e3483a33a3dcd868655a1495e63b0886ae0b76. Don't take our word for it — paste those inputs into any SHA-256 tool and check.

Step 6 — turning the hash into a ticket number, with no bias

Take the first 12 hexadecimal characters of the combined hash: dfb484fa8793. That's a 48-bit number — in decimal, 245,966,418,118,547 (possible values run from 0 to 281,474,976,710,655). Suppose the draw has 8,449 tickets. The naive approach — just divide and take the remainder — would make the lowest tickets very slightly more likely, because 8,449 doesn't divide the 48-bit range exactly. So the rule first computes a cut-off: the largest multiple of 8,449 that fits in the range. Any 12-character slice at or above the cut-off is rejected and the next 12 characters are used instead. This is called rejection sampling, and it makes every ticket exactly equally likely.

Our slice is below the cut-off, so it stands: 245,966,418,118,547 divided by 8,449 is 29,111,897,043 remainder 2,240 — and the winner is ticket 2,240 + 1 = 2,241. The division is checkable by hand: 29,111,897,043 × 8,449 + 2,240 = 245,966,418,118,547. Every certified draw's certificate shows this working — the slice, the decimal, the quotient, the remainder — for its own numbers.

Two edge cases, both handled deterministically: a hash yields five 12-character slices, so if a slice is rejected the next is tried; and in the astronomically unlikely event all five are rejected, the hash is extended by fingerprinting SHA-256(FDR-EXTEND| followed by the hash) and the scan continues. Same inputs, same winner, for everyone, always.

Step 7 — everything is published

The certificate shows every figure above for the real draw: the seal, the committed and revealed salt, the seed block (with a link to the public network's own records), the combined hash, and the full division. The sealed entry list is public, and “find my tickets” receipts are mathematical proofs against the seal — not our say-so.

Why this can't be quietly fixed

To fix a draw you would need to change the sealed list (breaks the published seal), swap the salt (breaks the published commitment), influence which block the network produces (you'd need to control a worldwide network AND know the secret salt), or lie about the maths (anyone can redo it). That's the point of the design: fairness you can check, not fairness you're asked to believe.