Provably fair slot outcomes through one API

What does provably fair mean for slots?

Provably fair is a verification pattern that lets a player, operator, or auditor check whether an outcome was generated from committed seed material instead of changed after the fact.

In Cymba, each spin uses a server seed, client seed, and nonce to generate deterministic outcomes. The server seed remains secret while active, but its SHA-256 hash is available as a commitment. Later, when the seed rotates, the previous seed is revealed and prior spins can be replayed.

That replay is the point. If the same inputs produce the same result, and the revealed seed hashes to the original commitment, the result is independently checkable.

The Cymba verification flow

The normal spin flow starts with /api/v1/spin. Cymba increments the API key nonce, combines the server seed with the provided or generated client seed, resolves the spin, and returns the result plus provably fair fields.

The response includes:

• server_seed_hash
• client_seed
• nonce
• result_hash
• config_hash where supported by the serialized result

When the operator rotates the seed through /api/v1/seed/rotate, Cymba reveals the previous server seed and creates a new server seed hash for future spins.

At that point, previous spins under the old seed can be reproduced through /api/v1/verify.

Why result hashes matter

Seed replay proves the RNG stream. Result hashes add tamper evidence for the serialized spin response.

Cymba computes an HMAC-SHA256 hash over the canonical result payload. After the server seed is revealed, a verifier can recompute the hash and compare it with the original result_hash.

This matters because a dispute is not only about whether the random outcomes were fair. It is also about whether the published result was changed after the spin.

Why config hashes matter

For slot games, the game config is as important as the RNG seed. Two games can use the same random outcomes and produce different wins if their reel strips, paytable, wild rules, or feature settings differ.

Cymba binds results to configs through config hashes and PAR sheet exports. A PAR sheet gives a reviewer the canonical config and expected hashes. A live spin can then be checked against that config.

That makes it harder to quietly swap a game to a different math model without leaving evidence.

What provably fair does not solve

Provably fair does not replace legal compliance, certification, or responsible operation.

It does not prove that a game is licensed in a jurisdiction. It does not verify the operator's wallet, player balance, or payout process. It also does not promise that a game has a particular RTP unless the game config and math model are separately reviewed.

Cymba's role is narrower and more concrete: generate and serialize slot outcomes in a deterministic, replayable, tamper-evident way.

Where this helps most

Provably fair slot APIs are especially useful for crypto casinos, sweepstakes platforms, and studios that need a public trust story without exposing proprietary engine source.

The operator can keep player systems and money movement in-house while relying on Cymba for the math output and verification material.