How fairness works

1. We pick the products. A limited chest is a fixed list of real, vaulted items. We write the list of item ids down, sorted, and hash it. That hash is the manifestHash. It proves the set of items cannot change after publish.
2. We draw a secret seed. 32 random bytes. We publish only its hash, the seedHash. The seed itself stays secret while the chest is selling.
3. We publish a commitment. One more hash that ties the fairness version, the seed hash and the manifest hash together. This is the fingerprint shown on the chest page and in the table below.
4. The seed shuffles the items. A standard Fisher-Yates shuffle driven by a keystream derived from the seed places each item in a numbered slot. Same seed and same manifest always give the same order, so anyone can reproduce it later.
5. Each purchase takes one slot. Your browser sends a random clientSeed with the order. We hash the secret seed, the purchase number (nonce) and your clientSeed, and use that hash to pick one of the remaining slots. The proof of that pick is stored on your pull and shown on your order.
6. We reveal the seed. When a chest sells out or is retired, the seed is published. From that moment the whole thing is checkable: the commitment, the shuffle and every pick. The verifier does it in your browser. Every pull also has its own proof page, linked from My pulls, with its hashes, a photo of the item and its value history.

Always-available chests are restocked over time, so there is no fixed list to lock in. Instead the randomness is locked in: before the first rip we draw a secret seed and publish its hash. Each rip is rolled from that seed, the rip number and your browser's clientSeed, so we cannot choose or predict your roll.

h         = sha256(`unitedrips-open-v1|${seed}|${nonce}|${clientSeed}`)
roll      = int(h[0..13]) / 16^13            -> value range by the live odds, in published order
pick      = int(h[13..26]) mod itemsInRange  -> the item, items in range sorted by stock order

When a chest uses auto odds, the live odds are calculated at the moment of the rip from the product in the chest, using the published method, and they are the same for every buyer at that moment. Each pull stores the live odds, the roll, the range and the hash, and in a chest with odds modes, the mode you picked (the odds stored are that mode's odds). We publish the seed from time to time and whenever a chest is retired, and then every rip made with it can be checked: the hash must match, and the roll must land in the range you got.

These are copied from the comments at the top of our fairness module. Version string: packrip-fairness-v1. All hashes are SHA-256 over UTF-8 text, printed as lowercase hex.

manifest      = JSON array of item ids, sorted (what is in the chest)
manifestHash  = sha256(manifest)
seed          = 32 random bytes (hex), kept secret until the chest sells out or retires
seedHash      = sha256(seed)
commitment    = sha256(`${version}|${seedHash}|${manifestHash}`)
order         = fisherYates(manifest, keystream(seed))   -> slot index i holds order[i]

nonce         = number of units sold in this chest before this one (0-based)
clientSeed    = entropy supplied by the buyer's browser (or empty string)
remaining     = sorted list of slot indexes still AVAILABLE
pick          = int(sha256(`${seed}|${nonce}|${clientSeed}`)) mod remaining.length
slotIndex     = remaining[pick]

block(counter) = HMAC-SHA256(key = seed, message = String(counter))
each block yields eight 32-bit big-endian unsigned integers (4-byte steps)

nextInt(n):
  limit = floor(2^32 / n) * n
  take v from the stream until v < limit
  return v mod n

fisherYates(arr):
  for i from arr.length - 1 down to 1:
    j = nextInt(i + 1)
    swap arr[i], arr[j]

• The manifest cannot change. Adding, removing or swapping an item after publish would change the manifest hash and break the commitment.
• The order cannot change. The seed determines the shuffle. A different seed would not hash to the published seed hash.
• We cannot steer your slot. Your pick depends on your clientSeed, which we do not see until your order is placed and which is part of the proof. The nonce is the count of units sold before yours, serialized in the database, so we cannot reorder purchases either.
• We cannot predict the next buyer's slot. Because the next buyer's clientSeed is random and unknown to us, we cannot know which slot they will get, so we cannot time our own purchases around good slots.
• Owners and staff are prohibited from purchasing. This is a rule in our terms and an internal policy, not a mathematical guarantee. Anyone with access to the seed could, in principle, know the order; the clientSeed mechanism above is what stops that knowledge from being useful for picking a slot.
• Slot picks are uniform. Every remaining slot has the same chance on every purchase. Our test suite checks this statistically.

Commitments are shown the moment a chest is published. The seed is returned by the verifier once the chest has sold out or been retired.