How Rips Work

Provably fair

Live Tier packs commit to a sealed server seed before the rip. Anyone can re-derive the outcome afterwards and check our work.

"Trust us" is not a fairness guarantee. Every digital pack we sell publishes enough information that you — or anyone, including someone with no account — can re-derive the outcome and confirm we did not change it after the fact.

The short version

Our half is locked in before you buy. For every pack we pick a secret random value and show you a sealed copy of it — the pack code under Fairness, and in small print when you confirm a purchase.
Your half comes from you. Your browser makes your code at random (you can type your own). Every card is drawn from both halves together, so nobody — us included — can steer what you pull.
We unseal ours after the rip. Once your pack is opened we publish the secret value. Anyone can check it matches the pack code you were shown, and re-run the draw to get exactly the same pulls.
You don't need to do anything. The defaults are fair. Checking is there for anyone who wants to.

For most collectors, that's all you need to know. The rest of this page is the detail behind it, for anyone who wants to verify a rip themselves.

Terms used below. The pack code is the fingerprint: the SHA-256 hash of our server seed. Your code is the client seed.

The idea

Before you buy, the server generates a random server seed and shows you only its SHA-256 hash — the fingerprint in the Fairness panel under More Info. That hash is the commitment: it pins the seed down without revealing it, and it is issued to you before you have told us anything else.

Then your browser draws a client seed of its own, after the fingerprint has arrived. You can keep it or type any seed you like. Every card in the pack is drawn from both seeds together, so the outcome depends on a value we fixed before we knew yours, and on a value you chose after we could no longer change ours. Buying several packs in one purchase changes nothing: you get one fingerprint per pack — five packs, five fingerprints — every one of them fixed before your seed exists, and every one published with its pack. Buying from the pack picker, all of them are on screen in the Fairness panel before you confirm; Purchase Again reuses the same order without showing them, so open the picker if you want to record a fingerprint before you buy.

The server seed itself is withheld until the pack is opened — deliberately. Publishing it early would let anyone holding it, a buyer or an assigned streamer, compute the contents before the rip.

After the reveal we publish the seed. Because a SHA-256 hash cannot be worked backwards or collided in practice, a seed matching the fingerprint you were shown earlier can only be the seed we were already committed to. We could not have looked at the outcome — or at your seed — and picked a different one.

What we commit to

The fingerprint is not the only thing pinned down before the roll. Each card slot's outcome is a function of the seeds plus four published inputs, and all of them are recorded on the pull with a fingerprint of their own:

Input	What it decides	How it is committed
The slot's tier table	which rarity rung the first roll lands on	hashed in the exact stored order
The rung's candidate set	which slab the second roll selects	versioned, hashed in the exact stored order
The rung's target value	how the candidates are weighted	recorded on the pull
Any slabs excluded on a retry	the final candidate list	recorded on the pull

The order matters because the rolls walk these lists top to bottom. A fingerprint that ignored order would let a list be shuffled without changing its fingerprint, so ours do not.

If a pack cannot be completed

If a slot rolls a rung that holds no slab we can give you, the purchase does not complete and you are not charged. We never substitute a cheaper card. Every such event is written to a public ledger with its seed revealed, so that anyone can confirm the roll really did land where we say it did, and can see how often it happens for each pack:

GET /api/packs/voids?template_id={id}&days=30

A pack that was rolled but never completed is a pack we did not want to sell, or could not. Publishing the seed removes the difference.

Getting the data

Anyone can fetch it, no account and no authentication:

GET /api/packs/verify/{packId}

The response contains:

Field	What it is
`commitment.server_seed_hash`	The fingerprint we committed to before the roll, as recorded on every pull
`commitment.issued_server_seed_hash`	The fingerprint as it was issued on the commitment record — it must equal `server_seed_hash`
`commitment.issued_before_purchase_request`	`true` — you were holding this pack's fingerprint before your seed was sent. `false` appears only on packs bought before we pre-issued a fingerprint per pack: an additional pack in a multi-pack purchase, committed just before its roll. `null` for packs from before commitments existed
`commitment.client_seed`	Your seed, mixed into every message
`commitment.server_seed`	The seed itself — `null` until the pack is opened
`commitment.commitment_id`	The commitment the pack was rolled under
`commitment.issued_at`	When the fingerprint was issued to the buyer
`commitment.purchased_at`	When the pack was paid for — always after `issued_at`
`pulls[]`	One entry per card slot: its `nonce`, `slot_index`, the recorded `roll_tier` and `roll_card`, the tier it landed on, the `tier_table_hash`, and `excluded_inventory_ids` — the slabs removed from the candidate set before the pick
`buckets`	For each slot, the candidate set the card was drawn from, with a `content_hash`, its members and their values
`how_to_verify`	The steps below, returned alongside the data

Checking it yourself

Check the commitment. Compute SHA-256(server_seed) and confirm it equals the server_seed_hash published before the rip — the fingerprint you saw before buying.
Check the fingerprint on record. issued_server_seed_hash — the fingerprint as it was issued — must equal the server_seed_hash recorded on the pull, and both must equal SHA-256(server_seed).
Check the timing. issued_at must precede purchased_at, and issued_before_purchase_request must be true — this pack's fingerprint was in your hands before your seed was sent to us. Since we began pre-issuing a fingerprint per pack, that is true of every pack of a multi-pack purchase, so check it on each of them rather than taking one pack's word for the others. (On a pack bought before that change the field reads false; for those, check the fingerprint against the revealed seed rather than against your seed's timing.)
Rebuild each slot's digest. For each pull, compute HMAC-SHA256(server_seed, message) where the message is exactly {client_seed}:{nonce}:{slot_index}.
Read the two rolls. Take hex characters 0–12 of that digest as roll_tier and characters 13–25 as roll_card, each parsed as an integer and divided by 2^52. They should match the recorded values.
Find the tier. Walk the slot's published tier table with roll_tier to get the rarity rung it landed on.
Build the candidate list. Take the bucket's members in the order given and remove every id in the pull's excluded_inventory_ids — cards already awarded to an earlier slot of the same pack, and any slab another buyer claimed a moment earlier — before weighting.
Re-solve the weighting. Derive alpha yourself from the candidates' values and the tier's target value. You do not have to trust the alpha we recorded.
Find the card. Weight each candidate by value^(-alpha), normalise, and select with roll_card. That is your slab.

If every step reproduces, the outcome was fixed before the rip and drawn from the candidate set we published.

Why the numbers are built this way

Two details are there to remove bias rather than to look impressive:

13 hex characters, not a modulus. Thirteen hex characters is 52 bits — exactly the mantissa of a double — so every drawn value is representable exactly. Dividing by 2^52 rather than taking a remainder avoids modulo bias, where some outcomes come up slightly more often than others purely because the range does not divide evenly.

One digest, two slices. The tier roll and the card roll are independent slices of a single HMAC. That keeps verification to one hash per slot instead of two, without the two rolls being correlated.

What this does and does not prove

It does prove that the outcome of your pack was fixed before it was opened, that we committed to our half of it before you bought and before we knew your seed, that it came from the published candidate set, and that the roll matches the published chances. One caveat is yours to hold, not ours: if you type a seed of your own and reuse the same one on a later purchase, we have seen it before that purchase's fingerprints were made. Let the browser draw a fresh seed — it does that for you after every purchase — or type a new one each time, and the ordering holds.

It does not prove that the chances themselves are generous, or that a card's displayed market value is correct — those are separate questions, covered in how we set the chances and the vault.