How to Verify a CS2 Case Opening: Server Seed, Client Seed, and Nonce Walkthrough

The server seed is a long random value the site generates for your account. While it is active you never see it in plain text — you see its SHA-256 hash instead, displayed before you play a single round. That hash is the commitment. SHA-256 is a one-way function: the site cannot quietly swap in a different seed later, because a different seed produces a different hash, and you would catch the mismatch the moment you compared them.

The client seed is yours. You can set it to anything you like and change it at any time. Its job is to make sure the site does not control all the inputs: whatever server seed was committed, your client seed gets mixed into every case opening you play, and the site had to commit before knowing what you would choose.

The nonce is the simplest of the three — a counter that increases by one with every round you play under the current seed pair. It makes each result unique (same seeds, different nonce, different outcome) and it keeps the sequence auditable: round 57 is round 57, and nothing can be silently reordered or skipped in between.

Each case opening is derived with HMAC-SHA256, a standard keyed-hash construction. The server seed, your client seed, and the nonce are combined into one HMAC-SHA256 computation, and the resulting hash is converted into a number — the roll that decides which item the case pays out. CaseRush documents the exact recipe on the /provably-fair page itself: the first 8 hex characters of the HMAC become a number between 0 and 1, and for cases that roll maps to a ticket from 1 to 10,000, where every item in the case owns a range of tickets sized by its drop chance. The key property is determinism: the same inputs always produce the same output, which is exactly why anyone can recompute a result after the fact and check it.

CaseRush's v2 scheme adds domain separation: the game type and round ID (gameType:roundId) are part of what gets hashed. That means a hash computed for one game or one round cannot be reused or misattributed to another — a roulette result cannot double as a case result, and round 400 cannot masquerade as round 401.

Shared games like crash and roulette work a little differently, because one round produces a single result for everyone in it. Those rounds are seeded per round rather than from any one player's seed pair, and v3 of the scheme adds external entropy on top: the hash of a future EOS blockchain block, committed before that block exists. Neither the site nor any player can know that block hash at commitment time, so it acts as an input nobody gets to choose. In player-versus-player games, joining players' client seeds are mixed in as well, so every participant contributes an input the others could not have predicted.

Everything lives at /provably-fair on CaseRush. The habit worth building is simple: look at the page before you play, because the server seed hash you see there is the anchor every later check hangs off.

One thing that trips people up: the current server seed is hidden by design. If you could read it while it was active, you could compute your own upcoming rolls in advance. It only gets revealed after it is retired — which is what rotation is for.

When you want to audit, rotate your server seed from the same page. Rotation retires the current server seed, reveals it in plain text, and generates a fresh one for future rounds — your client seed carries forward unchanged. From that moment, every round you played under the old seed is fully checkable.

CaseRush runs the first check for you: revealed server seeds are automatically hashed and compared against the hash that was committed before you played. A match confirms the seed you just saw is the same one that was locked in from the start — it was not swapped after your results were known.

For individual rounds, use the manual verifier on the same page. Select the game type, enter the round ID, and the tool recomputes the roll from the revealed seeds. Compare the recomputed result with what you were shown in the game — they should be identical. And you are not limited to the site's own tool: the /provably-fair page prints the exact HMAC input format and the roll derivation, so any environment with a standard HMAC-SHA256 implementation can reproduce the same numbers from the same inputs.

Passing verification proves one specific thing: your outcomes were determined by a seed pair that was committed before you played, and nothing was altered afterward. Tampering after the commitment is detectable, because it would break either the hash check or the recomputed rolls. That is a real, meaningful guarantee — it is the difference between a black box and an auditable system.

What it does not prove is that the odds are generous. A case with a brutal drop table can pass every seed check perfectly; provably fair means you lose fairly too. The drop rates are a separate question with a separate answer: CaseRush publishes the full item odds for every active case on that case's odds page — each case at /cases links to a complete drop-chance table alongside the case price — plus a general explainer of how to read them.

So do both halves. Verify a few rounds to confirm the mechanism holds, then read the odds table before you decide whether a case is worth opening. And keep the framing honest with yourself: every case has a margin built into its drop table, so treat openings as entertainment spend with a budget you set in advance, not as a way to come out ahead.