Provably Fair System For Limited Packs

A Limited Pack contains a fixed, pre-published list of specific cards. The supply is finite, the cards are drawn down over time, and the pack closes once it sells out. OpenHype is the first platform to bring a provably fair system to digital trading card pack openings (Oripa Packs), and this document walks through the full lifecycle of that mechanism: what happens before you open a pack, what happens at the moment you open it, and how you can prove afterward that every result was honest.

Core Principles

Every time you open a Limited Pack, the system produces a number called your Roll. That number selects your card from the cards still remaining in the pool. The entire point of “provably fair” is to guarantee that this number is determined by a set of inputs that no party can tamper with after the result is revealed.

We achieve this by combining the following inputs:

A Server Seed, which is locked in before you open by publishing its Public Hash.
A Client Seed, which is fully under your control and can be changed at any time.
A Nonce, a counter that increments with each opening.

On top of these, the pool itself carries its own commitment. Every card and its position is locked before the pack goes on sale through a Merkle Tree, whose Merkle Root is published openly.

These three safeguards (a locked Server Seed, a Client Seed you control, and a locked pool) each rule out a different way a result could be manipulated, and we explain how in the sections that follow. The short version is this: the outcome is mathematically sealed before it happens, and fully auditable after.

The Per-Pack Seed Mechanism

In a Limited Pack, the Server Seed is bound to the pack itself, not to your account. Because each pack holds a fixed list of cards, every draw from that pack shares the same Server Seed, and the Nonce is what keeps each result unique.

Here is how it works in practice:

When a Limited Pack is created, OpenHype generates a Server Seed for it, together with a dedicated Secret Salt, and publishes its Public Hash the moment the pack goes on sale. This is our binding commitment, proving the Server Seed existed and was fixed before anyone drew a single card.
At the same time, the pack's full pool is built into a Merkle Tree, and its Merkle Root is published alongside.
Every opening from that pack uses this one Server Seed.
After each opening, the Nonce increments by exactly +1, so even though the Server Seed stays the same, every result is different.
Each time a card is drawn, the remaining pool shrinks by one. The same Roll value can map to different cards depending on the order in which cards were drawn.
When the pack sells out (every card has been drawn), the Server Seed and its Secret Salt are revealed.

So at any given moment, the active Server Seed keeps the pack's future openings unpredictable to everyone. OpenHype cannot predict them, because you can change your Client Seed at any time. You cannot predict them either, because you do not know the active Server Seed. And once the pack sells out and the Server Seed is revealed, you can audit every opening from that pack and prove each one.

Before You Open: What Is Already Locked and Public

Provably fair comes down to a single idea: every input that shapes your result is public and locked before anyone draws the first card. So when you decide to open a Limited Pack, you face a set of rules and data that were settled in advance and that no one can alter, rather than a black box that gets quietly filled in once results come out.

What you can see before opening falls into two groups. The first group is two cryptographic commitments that seal the only two variables capable of influencing your result: what you Roll, and what is in the pool. The second group is three pieces of public information that give you the ability to independently replay any opening afterward.

Cryptographic commitment one: the Server Seed's Public Hash, which seals the Roll.

This is our commitment that the pack's Server Seed is already fixed and cannot be swapped out later. What we publish is the seed's Public Hash, not the seed itself. The real Server Seed is revealed only when the pack sells out, together with its Secret Salt. Because the Hash is public before you open, we cannot look at how everyone's draws turned out and then go back and pick a seed that favors the platform.

Cryptographic commitment two: the pool's Merkle Root, which seals the pool.

Here, the result depends not only on the number you Roll but also on exactly which cards are in the pool and what positions they sit in. When the pack goes on sale, the entire pool is summarized into a single Merkle Root and published. Its commitment to each card carries the full picture: the card's position in the pool, the pack it belongs to, and its identity:

Because the position (merkle_index) is written into the commitment itself, the entire ordering of the initial pool is locked down as well. The card's identity is double-bound using both a human-readable name (product_title) and a unique system identifier (product_uuid), which means that even if someone tried to swap only a card's display name, or only its underlying identifier, the root value would change immediately and the tampering would be exposed on the spot. Once the Merkle Root is published, we cannot add, remove, or swap any card, nor change the order they sit in.

Public information one: the complete pool list.

Which cards are in the pack, how many of each, and what share the rare cards make up: this fixed list is fully published. This is the heart of a Limited Pack. Before you open, you know exactly what kind of pool you are facing.

Public information two: the drawing algorithm and parameters.

These are the full set of rules covered later in “Step by Step”: HMAC-SHA512, taking the first 15 hexadecimal characters, taking the modulo against the current remaining card count , locating the index, then removing the drawn card so the cards behind it shift forward. The one detail worth keeping in mind is that the modulo base is , which changes with every draw. Because the algorithm is public, you can replay and verify any opening exactly as it happened.

Public information three: your Client Seed.

Before you open, the fairness panel already shows your active Client Seed, and you can change it at any time. This is your personal key: since the Server Seed is already locked by its Public Hash, there is no way for us to reverse-engineer a seed targeted at your specific Client Seed.

In short: the two commitments seal the Roll and the pool, the only two variables that can influence your result, and the three pieces of public information give you the ability to replay any opening on your own.

Glossary

Server Seed — A secret string generated by OpenHype and assigned to a Limited Pack. It stays hidden while active, but its Public Hash is published in advance. When the pack sells out, the Server Seed itself is fully revealed.

Client Seed — A string you own and can rewrite at any time. Changing it produces an entirely different sequence of results from that moment on, which is your proof that we cannot design a Server Seed around your specific Client Seed.

Nonce — A counter tied to the current pack's Server Seed. It increments by 1 with each opening, allowing the same Server Seed and Client Seed to generate non-repeating Rolls.

Secret Salt — A string dedicated to each Server Seed, used to protect that Server Seed from being cracked by users and to generate that Server Seed's Public Hash. Every Server Seed has its own dedicated Salt, revealed together with the Server Seed when the pack sells out.

Public Hash — A string of the form hash(server seed + salt) that is always visible to users, used to guarantee the Server Seed has not been changed. It is computed as:

Roll — The verifiable random number used to select your card from the remaining pool.

Merkle Tree / Merkle Root — A cryptographic structure that summarizes every “(position, card)” combination in the pool into a single root fingerprint. The Merkle Root is published when the pack goes on sale, making it impossible for the platform to add, remove, or swap any card afterward without changing the root value.

Pool — The fixed, pre-published list of cards in a pack. Each time a card is drawn, the remaining pool shrinks accordingly.

Step by Step: How an Opening Is Generated

When you open a Limited Pack, here is what happens behind the scenes, with nothing hidden:

Step 1: Build the intermediate key.

Compute HMAC-SHA512, where the message is the Server Seed and the key is your Client Seed joined to the current Nonce with a hyphen, in the format clientSeed-nonce:

The output is a long hexadecimal string.

Step 2: Truncate.

Take the first 15 hexadecimal characters of , written as .

Step 3: Convert and take the modulo.

Convert those 15 hexadecimal characters into a decimal integer, then take the modulo against , the number of cards currently remaining in the pool. The modulo base shrinks with every draw.

Step 4: Locate the index.

The result is an index position within the remaining pool:

Step 5: Assign and remove the card.

The card at that index is assigned to you and removed from the remaining pool. Here is a key point: the index does not point to one fixed card. It points to a position in the ordered list that is the current remaining pool. That list is always changing. Each time a card is drawn, it loses one element and the cards behind it shift forward. So the mapping from number to card depends on the live state of the pool at the moment you open, and because the pool shrinks, the same value can map to different cards depending on the draw order. (The reasoning behind this is covered in the next section, “Why Draw Order Affects the Result.”)

Step 6: Increment.

The Nonce increments by 1, ready for your next opening.

Every step is deterministic. The same inputs and the same pool state always produce the same Roll and the same card assignment, which is exactly why independent verification is possible.

Why Incrementing the Nonce Preserves Randomness

It is natural to wonder how changing just one number in the Nonce can produce a genuinely random new result. The answer is the avalanche effect, a core property of cryptographic hash functions: change even a single character of the input, and the output is completely scrambled, with no traceable relationship to the change you made.

Two inputs that differ only in their final digit, clientSeed-1 and clientSeed-2, produce results that look entirely unrelated. There is no pattern to follow and no trend to exploit, which is exactly why a single pack-level Server Seed can drive a large number of Rolls that are both unpredictable and provable.

Why Draw Order Affects the Result (Order Sensitivity)

In a Limited Pack, the result of an opening is determined by both the Roll and the order of openings, and neither can be left out. This is worth explaining on its own, and there are two independent mechanisms that work at the same time.

Mechanism one: the modulo base changes.

The in Step 4 is the current remaining card count. As the pool goes from 5 cards to 4 to 3, becomes 5, then 4, then 3. Even if is identical, taking the modulo against different values of gives different remainders, so the index it lands on is already different.

Mechanism two: even if the index is the same, the card at that position has changed.

More subtly, even if two openings happen to compute the same index value, the card sitting at that index can be different, because the cards drawn earlier were different and the remaining list has shifted as a result.

Here is an example. Suppose the initial pool has 5 cards, positions 0 through 4 holding [A, B, C, D, E].

Case X: Suppose D (originally at index 3) was drawn earlier. The remaining pool becomes [A, B, C, E] (indices 0,1,2,3). Now an opening computes , landing on index 2, which gives C.
Case Y: Suppose A (originally at index 0) was drawn earlier instead. The remaining pool becomes [B, C, D, E] (indices 0,1,2,3). This same opening also computes , landing on index 2, but this time it gives D.

In both cases, is the same, the remainder is the same, and the index landed on is the same (both are 2). But because the card removed earlier was different, the remaining list shifted differently, so the card at that index changed from C to D.

This is precisely one of the reasons the result cannot be manipulated in advance. You cannot predict which card a given Roll will turn into without the live pool state, and the platform cannot use a fixed Roll to “designate” a rare card, because which card a Roll lands on depends on the pool state accumulated from everyone's draws before it. And this entire chain of state changes can be replayed and fully verified afterward using the revealed Server Seed, your Client Seed, each Nonce, and the Merkle Root published at sale time.

Why the Secret Salt Makes Cheating Impossible

The Secret Salt is a critical part of the mechanism, and it protects in two directions at once. Note that every Server Seed has its own dedicated Salt, so revealing one Server Seed's Salt never weakens the protection on any other Server Seed.

First, it stops you from cracking the Public Hash.

If the Public Hash were simply hash(server seed), then in theory someone could reverse it through precomputation or brute force to recover the Server Seed and calculate all future Rolls in advance. But because we use the Secret Salt as the HMAC key, and that Salt stays secret while the pack is active, no one can recompute the Public Hash to test a guess about the Server Seed without knowing the Salt. The Public Hash is therefore a true one-way lock.

Second, it cannot be used by us to cheat either.

You might ask: since the Salt is in our private keeping, could we change the Salt afterward to cover up a tampered Server Seed? The answer is no. Suppose we wanted to secretly swap the Server Seed for a that favors the platform after you open. Because the Public Hash was already published and fixed before you opened, for that forged seed to pass verification we would have to find some such that:

This is essentially a preimage attack: recovering the key when both the output and the message are fixed. For SHA-256, this is computationally infeasible, requiring an astronomical amount of computing power. So even with the Salt under our control, we cannot use it to make a tampered Server Seed match the Public Hash we committed to in advance. Once the commitment is published, it is sealed.

Why the Merkle Root Makes the Pool Tamper-Proof

If the Secret Salt guarantees that the Roll has not been manipulated, the Merkle Root guarantees that the pool has not been manipulated.

As described above, the Merkle Root published at sale time commits to every card in the pool and its position. The key effect is this: even if the drawing algorithm is executed perfectly correctly, we cannot cheat by secretly modifying the pool. Any change to a card's content, quantity, or position would make the recomputed Merkle Root fail to match the published value, and the tampering would be detected immediately.

Together, the two commitments place the entire drawing chain under audit, from the random number that generates a Roll to the actual card you end up with.

How to Verify Your Openings

The Provably Fair panel in your account gives you everything you need:

The Public Hash of the pack's current active Server Seed.
The Merkle Root published when the pack went on sale.
Your Client Seed, which you can edit at any time.
The pack's revealed Server Seed (revealed after sellout, along with its dedicated Secret Salt).
A Roll ID for each opening, revealing the exact inputs and calculation behind that result.

For every card you draw from a Limited Pack, you can use the provably fair mechanism to check how that card was drawn.

Verifying the revealed Server Seed:

After the pack sells out and the Server Seed is revealed, you can use any standard HMAC tool to recompute its Public Hash yourself: message = the revealed Server Seed, key = that Server Seed's dedicated Secret Salt, algorithm = SHA-256. If the result matches the Public Hash we published before you opened, it proves the Server Seed was never changed.

Verifying a specific Roll:

Using the revealed Server Seed, your Client Seed, and that opening's Nonce, run through Steps 1 to 4 above again. The Roll you reproduce must match exactly the one you received at the time.

Verifying card positions:

You can replay the entire draw history against the published Merkle Root, confirming the index each Roll located, the card sitting on it, and that the card genuinely belongs to its corresponding position in the original pool. If any one of these fails to match, fairness has been broken, and you hold the cryptographic proof of it.

When and How the Server Seed Is Revealed

A Limited Pack's Server Seed is fully revealed the moment the pack sells out (every card has been drawn), along with its dedicated Secret Salt. From then on, every opening from that pack can be verified from start to finish.

Why the reveal waits until sellout.

A Limited Pack's Server Seed serves every draw from that pack. If the seed were revealed early, players drawing later could predict which cards are still in the pool and what positions they hold, which would break fairness for them. Holding the seed until the pool is empty keeps information equal for all participants. The reveal boundary for a Limited Pack is sellout, the point at which the pool has been fully drawn.

Our Commitment to Transparency

We believe a guarantee only counts when you can see it with your own eyes and check it with your own hands. That is why everything shaping your result is public: every reward tier, every card's position in the pool, the Merkle Root published when the pack goes on sale, and the Server Seed and its Salt revealed after sellout. No part of how a card is drawn is hidden inside an opaque box, and you can use the provably fair mechanism to verify any opening at any time, not only when something looks wrong, but whenever you want to.