Verification
How verification works.
After you open a pack, you can replay it yourself on /verify by pasting your seeds. We use a standard commit-reveal protocol with HMAC-SHA256 — same building blocks used in well-known pack-opening verifiers.
Step 1
We commit
We generate a random 32-byte server_seed and show you its SHA-256 hash. The seed is stored server-side and never modified between commit and reveal.
Step 2
You seed
You can provide your own client_seed or accept an auto-generated one. Either way, you're locking in an input before the pack opens.
Step 3
We rip
For each slot, we compute HMAC-SHA256(server_seed, client_seed:nonce:slot_index) and map it to a card using the set's slot weights.
Step 4
You verify
We publish server_seed once your rip completes. Paste seeds into /verify — you'll get the same cards back. If we ever changed the seed, the hash wouldn't match.
What this gives you, and what it doesn’t
Two specific properties — independently checkable.
The result wasn't swapped after the fact. Commit-reveal with a published hash means the seed couldn’t be changed between commit and reveal without breaking the hash.
The pull was deterministic from the seeds. The HMAC chain is fully replayable — anyone with the seeds reproduces the same per-slot uniform value, and therefore the same card.
What this is not: a regulator-issued fairness certification. This page is only about reproducing your own pull from the seeds we publish to your session — nothing more.