01
Freeze the lot entries
Before selection starts, the system records the full list of entries for the lot and creates an `entries_snapshot` plus a SHA-256 hash of that snapshot.
How Dream Auction selection is verified
A clear explanation of the audit data, randomness source, and replay steps used to verify the final Dream Auction selection after a lot closes.
Trust and verification
The result is meant to be replayable, not mysterious.
When a Dream Auction lot closes, the system stores the entry snapshot, the randomness proof input, and the final computation details so an administrator can verify that the selected participant matches the stored data.
Important legal notice
No purchase is necessary. No purchase or paid method increases the chance of selection. Each eligible participant can submit one verified participation per lot. No cash alternative. Subject to Official Rules and eligibility restrictions.
How the selection flow works
The system converts a closed lot and an external randomness response into a deterministic selected index that can be checked later.
02
Request independent randomness
The system requests random bytes from ANU Quantum Random Numbers. ANU provides the randomness source only and does not know platform users or choose the participant directly.
03
Build the seed input
The lot ID, entry count, snapshot hash, algorithm version, and random bytes are combined into the seed input used for the final deterministic computation.
04
Compute the selected index
The algorithm applies `sha256-uint32-rejection-sampling`, then computes `selected_index = (accepted_uint32 % participant_count) + 1`. Rejection sampling is used to remove modulo bias so each valid queue position has the same probability.
05
Match the selected entry and save proof
The selected index maps directly to `number_in_queue` in the snapshot. The system then stores the selected index, participant ID, user ID, hashes, and full calculation details in the audit log and proof file.
What a verifier checks
The proof file exists so the result can be independently replayed from stored data instead of being trusted as an opaque outcome.
- Recompute the snapshot hash The verifier rebuilds the hash from the stored `entries_snapshot` and confirms it matches the saved value.
- Rebuild the random bytes from the ANU response The verifier extracts the stored ANU response bytes and checks that the ANU response hash still matches.
- Recreate the seed input The verifier uses the lot ID, entry count, snapshot hash, algorithm version, and ANU random bytes to recreate the seed input.
- Replay rejection sampling The algorithm is rerun and the recomputed selected index must match the saved selected index.
- Confirm the same participant is selected The selected index must point to the same participant ID and user ID stored in the proof output.
Why mismatches are detectable
If the entry snapshot, ANU response, selected index, or selected participant changes, the recomputed proof will no longer match. That makes post-selection tampering visible during verification.