Commit Reveal Draw

The bug this exists to prevent

The obvious raffle is array[Math.floor(Math.random() array.length)]. It is actually* random and it is worthless, because it is unverifiable. Nobody outside your process can distinguish it from picking your friend, and you cannot prove otherwise after the fact — including to yourself, if the question ever comes up.

The standard fix is commit-reveal: publish hash(seed) before entries close, publish seed after, and anyone can verify the seed matches. That is necessary and not sufficient — you still chose the seed, so you can grind seeds until one produces the winner you want.

Mixing in a public randomness beacon (drand) closes it. The beacon publishes randomness at a fixed round on a schedule you do not control, so a seed committed before that round cannot have been chosen for its outcome.

Three ways the arithmetic goes wrong

### 1. Concatenation without a separator is a collision

The draw material canonicalises its inputs with an explicit 0x1F field separator. Without one, buyerId="ab" + orderId="cd" and buyerId="a" + orderId="bcd" produce the same bytes — two different purchases with an identical draw. There is a test pinning the exact canonical form, because this is the kind of thing a later refactor "simplifies."

### 2. Modulo is biased, and nobody notices

material % remainingCount is not uniform unless the count divides the range. For small fields the bias is invisible; over thousands of draws it consistently favours low indices. Index selection here rejects the biased tail rather than folding it, and the property test asserts the index is always within range across generated inputs.

### 3. Every input must actually change the outcome

There are separate tests that the material changes when the nonce changes, when the receipt changes, when the drand round or randomness changes, and when the server seed changes. That sounds obvious and is exactly what silently breaks: drop one field from the hash input during a refactor and the draw still works, still looks random, and is now insensitive to the thing that made it fair.

What this does NOT do

No beacon fetching — you supply the drand round and randomness. No entry list management, no prize allocation, no publishing of the commitment. No storage.

It does not make your draw legal. Verifiable fairness is a technical property; whether you may run a lottery is a question for a lawyer in your jurisdiction.

Verified

13 tests including property-based tests via fast-check: determinism for identical inputs, sensitivity to each input independently, the canonical separator fixture, and index selection always landing within range.

Not covered: no test verifies a real drand beacon response, and there is no test of the commit-publish-reveal timeline — that the commitment was published before the round it mixes in is an operational discipline this code cannot enforce.