Provably fair,
in plain sight.
The assignment is not a promise to “be random.” It is a reproducible calculation whose inputs are committed in the correct order. This page exposes those inputs as the release progresses.
live
Manifest committed
Every public package term is canonicalized, salted, hashed, and combined into the manifest root before sales.
Stripe payments settle
Only successful payments qualify. Failed, duplicated, or refunded checkouts never enter the roster.
Roster closes
At the fixed close or sellout, purchase IDs are ordered by paid timestamp and ID, then committed as a Merkle root.
Future beacon selected
Only after the roster root is stored do we select a future drand Quicknet round. Neither Journey nor a buyer can know it in advance.
Batch permutation runs
The two roots, beacon, release ID, and algorithm version seed a deterministic unbiased Fisher–Yates permutation.
Seals open
Each package commitment opens with the exact package terms and nonce. Any post-lock edit produces a different hash.
Release receipt
sealed-draw-v1 · SHA-256 · rejection-sampled Fisher–Yates99a20ec19d303a986c7f2767fb311d20c36cf176ebd45c8819b118cb0710d892Pending — the purchase roster is still openPending — selected only after roster lockPending future public randomnessPending signed beaconPendingPending roster and beaconManifest seals
One batch, one future draw.
No package leaves the pool during sales, and no “remaining Grail count” changes. Every eligible purchase is frozen before randomness exists.