Provably Fair Instant Games API

Instant games your players can verify

Every instant round Cymba resolves is committed before it's played and replayable after: server seed hash published up front, player-supplied client seed, HMAC-SHA256 outcome derivation, and a verify-card endpoint that reproduces the entire reveal from the seeds.

{ "server_seed_hash": "3e1c7d...", "result": { "round_id": "9f2c41...", "prize": { "prize_id": "m15", "multiplier": 15, "kind": "win" }, "card": { "mechanic": "beat_target", "cells": ["5", "2"], "meta": { "your_value": 5, "target_value": 2 } }, "result": { "total_multiplier": 15, "breakdown": { "base": 15 } } }, "verified": true }

Fairness that survives an adversarial player

The test of a fairness protocol isn't whether honest players trust it — it's whether a player who assumes you're cheating can prove you aren't. For instant games that requires three properties:

The outcome is fixed before the reveal. Cymba commits to the server seed by publishing its hash pre-round (GET /api/v1/seed). The drawn prize is a pure function of (server_seed, client_seed, nonce) — nothing about scratch order or timing can change it.
The player contributes entropy. The client seed is caller-supplied; the server can't grind seeds against it after the fact.
Everything is replayable. After seed rotation reveals the server seed, /api/v1/verify reproduces the round byte-identically — prize, card, and round id. Any independent implementation of the spec arrives at the same bytes.

The presentation is part of the proof

Instant games have a failure mode slots don't: the reveal is generated separately from the outcome, so a buggy or malicious presentation could display something the draw doesn't pay. Cymba closes that gap twice — at play time, the engine reads every generated card back through the mechanic's own win rule and refuses mismatches; at dispute time, /api/v1/verify-card takes the card block a player was shown (no seeds required) and reports exactly the prize it displays, refusing tampered or ambiguous cards with a 422.

Provenance on every logged round

Each logged play stores its seed commitment, client seed, nonce, config hash, and result hash. The dashboard's Rounds view exposes this per round, and the public /verify page replays any round from that provenance — a link you can hand to a player mid-dispute.

What Cymba does not do

Cymba proves the math was fair. It does not handle wallets, balances, player identity, licensing, or jurisdictional compliance — those stay in your platform.

Frequently Asked Questions

What does provably fair mean for an instant game?

Before the round, the server publishes a SHA-256 hash of its secret seed. The outcome is derived via HMAC-SHA256 from (server seed, client seed, nonce) — so the server can't change the result after seeing your seed, and you can prove it after the seed is revealed at rotation.

Why verify the whole card and not just the prize?

A dishonest presentation could show a losing grid over a winning draw (or vice versa). /api/v1/verify replays the presentation layer too — the deterministic round_id derivation makes the replay byte-identical, card included. And /api/v1/verify-card reads any displayed card forward to the prize it names, no seeds needed — a tampered or ambiguous card is refused.

Do slots and instant games share the fairness protocol?

Yes. One server-seed commitment per API key covers every /play round — slots and instant games share the endpoint, the config picks the engine — nonces are consumed in round order across both, and seed rotation reveals the previous seed for replaying every round played under it.

Can players verify without an API key?

Yes — the public verifier at /verify replays any logged round from its provenance data, no authentication required.

Instant games your players can verify

Commit before play

Players hold half the seed

Replay the whole card

Replay a round after seed rotation