Fairness you can recompute: how we built a CS2 case platform
Odds for every item before you pay, a seed fixed in advance and an upgrade whose formula the player can see. A look at the mechanics of Gocase.gg and the decisions that made them verifiable.
Case sites run on trust, and trust is in short supply: players assume by default that the result is rigged. So when we started the Gocase.gg CS2 case platform, we set one rule: the server decides every outcome, and anyone can check it. Everything else, from the CS2-style roulette to upgrades and contracts, was built around that rule.
Odds before you pay, not after
In CS2 itself, Valve only discloses odds by rarity tier. A case site builds its cases itself, which means it can show the chance of every single item. On a case page there is a "Show chance" switch for exactly that: turn it on and you can see that a knife drops in thousandths of a percent, while the cheapest skins come out in two or three openings out of ten.
The odds are derived from the case's target RTP and the current valuations of its items, and they are recalculated whenever Steam prices move. The catalogue's base RTP is 90%. One detail matters a lot: the generator has no hidden limits on expensive drops. If it did, verifying fairness would be pointless, because the odds on screen would no longer match the real ones.
How provably fair works
Before an opening, the server generates a secret server seed and shows the player only its SHA-256 hash. The player sets a client seed of their own, and every opening has a sequence number, the nonce. The number that picks the item is an HMAC-SHA256 of the two seeds and the nonce, and the item itself is chosen by weight from the same odds table the case page displays.
While a seed is active, only its hash is known, so there is no way to fit a result to a particular player. When the player rotates the server seed, the old one is revealed, and every opening made with it can be recomputed on the fairness verification page. The form there calls the very same function that runs when a case is opened; there is no separate "demo" logic.
The roulette follows the server's answer
The browser receives a finished result, and the storefront builds the strip around it: the winning item sits at a position known in advance, surrounded by other items from the same case. The scroll follows CS2's deceleration curve and sounds like the game. You can open up to five cases at once in parallel columns, switch on fast mode or auto-open with profit and loss limits. The balance is debited in the same transaction that issues the item, so nothing can be tweaked from the browser.
That split frees the design. The animation can be polished as much as we like: it decides nothing, it only shows a decision already made.
Upgrades: the formula in plain sight
In an upgrade, the player stakes an item from their inventory for a chance at a more expensive one. The chance works like this: the stake's price divided by the target's price, multiplied by an RTP of 90%, with a cap of 85% so that a nearly even swap never becomes a sure thing. A 100-coin stake on a 300-coin item gives 30%. The target has to be worth at least 1.05 times the stake and no more than 20 times.
The wheel draws a sector exactly the size of the chance, and the pointer stops on the number that came up: landing in the sector is the win, with no separate logic for the animation. The seed scheme is the same as for cases, so upgrades are verified on the same page. The rules, formula included, open right from the upgrade page, along with an honest warning that a lost stake is gone. And if the target's price changes while the player is thinking, the server will not take the stake; it shows the new chance instead.
What stays behind the scenes
The team works in a separate admin app: a case editor with odds, a simulator and version history, skin withdrawals to Steam with manual review of large amounts, bonuses and promo codes. The simulator shows how a case will behave over the long run before the first player ever sees it, and the version history explains how the odds came to be what they are.
What the project taught us
- Let the server decide the result and record it; then the interface can be as flashy as you like.
- Show the maths where the player makes the decision, not on a separate rules page.
- Never let the copy promise more than the system does: players can check every promise.
- Fairness is a feature you can recompute, not a badge in the footer.
Case opening is entertainment for adults (18+), and over time it always returns less than you spend; we designed Gocase so players can see that up front. More on the stack, the admin app and the design system is in our Gocase.gg case study.