Are blind box odds fair?

A blind box is fair when two separate things are true, and most stores can only demonstrate the first. The odds have to be real, meaning they describe stock the seller has actually set aside. And each individual draw has to be checkable, meaning a buyer can confirm their result came from those odds rather than being decided some other way.

Chancey derives odds from committed inventory rather than from a number a merchant types in, and commits to every draw before it happens so the result can be replayed afterwards. Neither of those asks the buyer to take the merchant’s word for anything.

On a typical mystery box listing, the drop rates are text. A seller writes “5% chance of the chase item” into a description field, and nothing in the system connects that sentence to what is in the box. There is usually no published record of how many units were in the pool, no way to tell whether the rate changed after the listing went up, and no artifact tying an individual buyer’s result to the stated rate.

This is why buyers of repacks and mystery boxes so often suspect rigging even from honest sellers. The seller has no way to prove the negative. Complaints about pull rates cannot be settled by argument, only by evidence, and in most setups the evidence does not exist.

In Chancey, a merchant does not enter a percentage. They choose real products and variants from their Shopify catalog and commit a number of units of each into a pool. The odds are then a consequence of that pool rather than a claim about it.

If four units of a rare card sit in a seventy-unit pool, the odds of pulling it are exactly four in seventy. Those odds are published on the storefront, and they move as boxes sell, because the pool behind them is real stock rather than a static label. A merchant who wants a rarer chase item has to commit fewer units of it, which is a real inventory decision with a real cost, not a change to a number in a text field.

Deriving odds honestly still leaves the question of whether an individual draw respected them. Chancey answers that with a commit-reveal protocol, the same construction used to make any random outcome auditable. It runs in three stages.

1. Commit. Before any draw, the server generates a secret random value called the server seed and publishes the SHA-256 hash of it. The hash reveals nothing about the seed, but it pins the seed down: any later attempt to substitute a different seed produces a different hash and fails immediately.
2. Lock and draw.When the order is drawn, the seeds are frozen and every unit in the order is decided from them. Each unit gets its own nonce, so units in the same order draw independently. The outcome is computed by taking HMAC-SHA256 over the server seed, the client seed, and that unit’s nonce, converting the first thirteen hex characters of the digest into a number between zero and one, and walking the weighted pool until that number selects an item. No human input enters this step.
3. Reveal. Once every unit in the order has reached a final outcome, the server seed is released. From then on the commitment is read only. Anyone holding the revealed seed, the original hash, the nonce, and the recorded pool can recompute the draw and confirm it produced the prize that was actually shipped.

The ordering is what carries the guarantee. The commitment is published before the draw and the seed is released after it, so a result cannot be chosen once its value is known. Draws are also never recomputed under a public seed, because an outcome derivable in advance is not a draw.

Verification does not require trusting Chancey, and it does not require our software. Given the revealed server seed, the published hash, the client seed, the unit’s nonce, and the recorded pool, the check is:

1. Hash the server seed with SHA-256 and require it to equal the commitment published before the draw. If it does not match, the proof is invalid and nothing else matters.
2. Build the message from the client seed, the nonce, and a counter starting at zero, joined by colons, then compute HMAC-SHA256 over it keyed by the server seed.
3. Read the first thirteen hexadecimal characters of the digest as an integer and divide by 2⁵², giving a number in the range zero to one.
4. Multiply that number by the total weight of the recorded pool, then walk the pool in its recorded order subtracting each weight until the remainder goes below zero. The item you stop on is the selected one.
5. Require the selected item to equal the prize recorded for that unit.

One wrinkle is worth stating because it is where naive implementations go wrong. If a prize sells out between the moment it was offered and the moment the draw is committed to stock, that unit is redrawn with the counter incremented and the sold-out item removed from the pool. Every round of that process is recorded, so a verifier replays each one in order and confirms that each successive pool is exactly the previous pool minus the item that had just been selected. A seller cannot use a redraw to quietly swap a result, because a fabricated round would not match the pool the previous round implies.

A valid proof establishes something specific, and being precise about its scope is part of the point. It shows that the recorded result follows deterministically from inputs the server committed to before the draw, over the pool that was recorded at draw time. That is what rules out choosing outcomes after the fact.

What it does not do on its own is confirm that the recorded pool matched the odds displayed on the storefront at the moment of purchase. Those are separate claims resting on separate evidence: the proof covers the draw, and the published live odds cover the pool. Anyone evaluating a fairness system, ours included, should ask which of the two a given proof actually addresses.

Odds previews are also not part of this protocol. A preview demonstrates what a box can produce; it is not a recorded order draw and is not verifiable, by design.

For anyone selling repacks, pack rips, or mystery boxes built from cards and collectibles, being accused of rigging is not a reputational footnote. It is the thing that ends the business. The accusation is unfalsifiable in most setups, so it spreads, and honest sellers carry the same suspicion as dishonest ones.

Verifiable draws change the shape of that conversation. Instead of asserting that a pull was legitimate, a seller can hand over the proof and let the buyer check it independently. That is a stronger position than any promise, and it is available to every store running Chancey without additional configuration.

More on the mechanics and the market: the rise of gacha commerce, pack ripping for card shops, and the best Shopify mystery box apps.

• Are blind box odds fair?
  It depends entirely on whether anyone can check them. Most published blind box odds are a number the seller typed into a page, with nothing connecting that number to the stock behind the box or to the result any individual buyer got. Odds are only meaningfully fair when they are derived from real committed inventory and when each draw can be replayed afterwards by someone who does not trust the seller.
• What does provably fair mean for a mystery box?
  Provably fair is a commit-reveal protocol. Before any draw happens, the server publishes a cryptographic commitment to a secret it cannot change afterwards. The draw is then computed from that secret using a published formula. Afterwards the secret is released, so anyone can recompute the draw and confirm it produced the recorded result. It proves the result was fixed before the box was opened rather than chosen after.
• Can a merchant rig a blind box draw?
  Not through Chancey. Merchants set which products go into a pool and how many units of each, and those commitments determine the odds. Merchants do not choose individual results, cannot see a result before a buyer does, and cannot alter a recorded draw afterwards. Changing a pool changes the odds for future boxes, and the change is visible on the storefront because odds are published from live inventory.
• How do I verify my blind box pull?
  After the draw is revealed you receive the server seed, the client seed, the nonce for your unit, and the recorded pool that was in play. Recompute the SHA-256 hash of the server seed and check it matches the commitment published before the draw. Then run HMAC-SHA256 over the seeds and nonce, convert the first 13 hex characters to a number between 0 and 1, and walk the weighted pool to find the selected item. It must equal the prize you received.
• Do published odds have to match actual pull rates?
  Over a small number of pulls, no. Randomness clusters, and a 5 percent item will sometimes appear three times in a row and sometimes not appear in two hundred boxes. That is why per-draw verification matters more than comparing your own results to the published percentage. A proof settles whether one specific draw followed the committed inputs, which sampling never can.