Seed commitments before results
Server seed hashes are published before spins land. After seed rotation the previous seed is revealed and any prior spin can be replayed.
Crypto Casino
Cymba gives crypto casino teams a hosted slot math API with server seed commitments, client seeds, nonces, result hashes, and replay so every spin can be independently verified.
API example
POST /api/v1/spin
Authorization: Bearer cy_live_...
{
"config": "dragon-ways",
"lines": 20,
"client_seed": "0xABCD1234..."
}
{
"result": {
"round_id": "01JQ9R3Z...",
"summary": {
"total_multiplier": 50,
"breakdown": {
"free_spins": 50
}
},
"result_hash": "9f3e12..."
},
"provably_fair": {
"server_seed_hash": "c7a4b1...",
"client_seed": "0xABCD1234...",
"nonce": 211
}
}
In traditional online casino models, players extend trust to the operator. The RNG is certified by an external lab, but players cannot verify a specific spin themselves.
Crypto casino players often expect more. The culture around trustless systems, transparent protocols, and self-verifiable outcomes is part of the product proposition. A crypto casino that cannot show its math is demonstrably fair will lose players to platforms that can.
Cymba provides the math infrastructure to support that story.
Before a session, Cymba generates a server seed and publishes its SHA-256 hash. That hash is the commitment: the server cannot change the seed without the change being detectable because the hash would no longer match.
Each spin uses the server seed, a client seed provided by the player or operator, and an incrementing nonce. The combination deterministically drives the RNG outcome. Cymba serializes the result and computes an HMAC result hash over the canonical payload.
When the session ends or the operator triggers a seed rotation, Cymba reveals the previous server seed. At that point anyone with the seed, client seed, nonce, and config can reproduce the spin and verify that the result hash matches.
For platforms that want to extend their trust story further, client seeds do not have to be random strings. Some crypto casino operators use a hash of a recent block or beacon chain output as the client seed.
This means the seed input partially derives from a public, unpredictable, and external source. An operator cannot predict the seed in advance because it depends on a future on-chain event. Players can check that the seed was used correctly.
Cymba accepts any client seed string. What that string derives from is the operator's product decision.
Provably fair RNG is only half the story. The other half is proving that the math model was what the player expected.
Cymba includes a config hash in spin responses. A PAR sheet export captures the config hash alongside the canonical config, RTP data, and fixtures. Players or auditors can check that the config hash on a live spin matches the config hash in the published PAR sheet.
If an operator changed the reel strips or paytable without updating the published PAR sheet, the hash mismatch is a visible signal.
Cymba does not provide wallets, token balances, on-chain settlement, deposit and withdrawal logic, player KYC, or licensing.
These are entirely the crypto casino operator's responsibility. Cymba supplies the math output and verification material. The platform built on top determines how bets are placed, how wins are paid, and what regulatory framework applies.
For operators, that separation is also a feature. Cymba is a replaceable component in the stack. The math layer can be audited, replaced, or extended independently of the payment and player systems.
The fastest way to start is a free API key, a cloned template config, and a spin from the playground. The API returns result hashes and provably fair fields on every call, so there is nothing to enable.
For teams building on-chain integrations, the approach is to call Cymba off-chain, capture the result hash, and then log or commit that hash on-chain in the operator's own contract.
Start with a free API key, clone a template, and run your first provably fair spin.