The short version
RustClash is part of the Clash family, alongside Clash.gg and DotaClash. The three run the same fairness engine against different item pools, and RustClash's own fairness page redirects to Clash.gg's rather than publishing a separate document.
That means everything needed to check a RustClash result is already confirmed. Both case opening and battle rounds verify with the tool above, against the same published code we cross-checked for Clash.gg.
We are not going to restate the whole algorithm here, because duplicating it would just give you two pages to keep in sync and one of them would eventually be wrong. The full walkthrough lives in one place:
How the Clash engine works, in detail covers the seeded-generator approach, why the library version matters, the ticket range, and how battles use Random.org.
What is specific to RustClash
Very little, which is the point. Here is the whole difference:
| Clash.gg | RustClash | DotaClash | |
|---|---|---|---|
| Item pool | CS2 skins | Rust skins | Dota 2 items |
| Fairness page | Its own | Redirects to Clash.gg | Redirects to Clash.gg |
| Engine | seedrandom 3.0.5 | Identical | Identical |
| Ticket range | 0 to 99,999 | 0 to 99,999 | 0 to 99,999 |
| Battle seed source | Random.org | Random.org | Random.org |
The items are Rust skins
Not CS2 or Dota items. The fairness math is identical, and only the pool it maps onto differs. That is why a result verified here and a result verified on Clash.gg are the same operation with a different catalogue behind it.
Tickets run 0 to 99,999
An item listed at 1% holds exactly 1,000 tickets, and one at 0.1% holds 100. The arithmetic is unusually easy to follow because the ticket space is a round 100,000 rather than a power of two. Reproducing your ticket proves the number was fixed before you opened, and checking which published block it lands in proves it maps to the item you were given.
Battle seeds come from Random.org
In a battle there is no single player whose seed should decide a shared outcome, so the Clash engine takes its shared input from a third-party randomness service instead. Nobody at the table picks it, including RustClash.
The two modes, and which string each uses
Both verify here, and the difference between them is one line. Using the wrong one is the most common reason a check disagrees.
| Mode | Seed string | Shared input |
|---|---|---|
| Case opening | serverSeed:clientSeed:round | The committed server seed |
| Battle | battleSeed:round+1:slot | Random.org |
The round is not a global counter
In case opening, the round is the index of the roll within your bet rather than a running total across your account. Opening three cases in a single action produces rounds 1, 2 and 3 against the same pair of seeds. If a result will not reproduce, an incorrect round is worth checking before anything else.
Why the library version matters here too
RustClash inherits one unusual property from the Clash engine, and it is worth understanding before you check a result. Most platforms slice a hash, and a hash is the same function in every language, so anyone can reimplement the algorithm from a written specification. The Clash engine instead seeds a JavaScript pseudo-random number generator and reads its first output, which means the answer depends on the exact internal behaviour of one specific library.
That library is seedrandom 3.0.5. A different generator, or even a different version of the same one, produces a number that is no less random and completely wrong. We pin the version deliberately for that reason. It is not a criticism of the fairness: the commitment still works and the seeds are still published. It just means the check carries a dependency that a hash-based check does not.
What a passing check settles
A match proves that specific round came from values committed before you played, and that the result was not altered afterwards.
It says nothing about whether a withdrawal will arrive, how support behaves, or what any case contains. A fairness check answers one narrow question well and none of the others at all, which is why we keep what verification cannot prove as a permanent page.