Clean math boundary
Cymba returns multipliers, never monetary values. Your platform converts multipliers into sweepstakes coin outcomes.
Sweepstakes
Cymba handles the game math layer for sweepstakes casino platforms. You own the sweepstakes coins, prize redemption, and player experience. Cymba returns multipliers.
API example
POST /api/v1/spin
Authorization: Bearer cy_live_...
{
"config": "golden-reels",
"lines": 25,
"client_seed": "player-abc-session-7"
}
{
"result": {
"round_id": "01JR2M9Y...",
"summary": {
"total_multiplier": 10,
"breakdown": {
"payline": 10
}
},
"config_hash": "b8c2..."
},
"provably_fair": {
"server_seed_hash": "3e1c7d...",
"client_seed": "player-abc-session-7",
"nonce": 103
}
}
A sweepstakes casino is a platform that lets players use virtual coins to play games with the possibility of redeeming prizes. The legal distinction from real-money gambling usually rests on the sweepstakes structure, not the game mechanics.
From a technical standpoint, the games still need slot math: reel strips, paytables, win evaluation, RNG, and feature resolution. That math layer is operationally identical to any other slot game engine. The difference is in how the platform wraps it.
Cymba handles the math layer and leaves the sweepstakes wrapper to the operator.
Cymba resolves slot outcomes and returns multipliers. The operator's platform calls the API with a game config and receives the grid, win breakdown, feature events, total multiplier, and verification material.
The operator then applies that multiplier to the player's current bet in sweepstakes coins. That calculation happens entirely on the operator's side. Cymba has no visibility into coin balances, prize pools, player accounts, or redemption logic.
That separation is intentional. The sweepstakes structure and coin economy are the operator's product. The slot math is a component those products consume.
A sweepstakes platform typically needs a library of slot games with different themes, volatility profiles, and mechanics.
Cymba lets operators manage that library through stored configs. Each game is a JSON config with its own ID, reels, paytable, features, and RTP target. Operators can clone templates, modify them, validate, calculate expected RTP, and publish through the API.
Adding a new game does not require backend code. It requires a new config and a new entry in the platform's game lobby.
Sweepstakes platforms sometimes need to demonstrate that game outcomes are fair. This is both a trust issue with players and an occasional compliance requirement.
Cymba's provably fair model supports this. Before a session, Cymba commits to a server seed hash. After the session, the seed can be rotated and previous spins can be replayed from the revealed seed, client seed, nonce, and config.
That gives operators a concrete response to dispute queries: replay the spin and show the output.
Sweepstakes operators in some markets are expected to produce math documentation for regulatory or compliance review. A PAR sheet from Cymba includes the canonical game config, config hash, theoretical RTP data, and deterministic replay fixtures.
That artifact gives a reviewer the game definition, the expected math, and the tooling to independently verify outcomes. Whether it satisfies a particular compliance requirement depends on the market and review body.
Cymba does not handle sweepstakes structure, coin distribution, prize redemption, player KYC, jurisdictional analysis, or legal compliance.
These are the operator's responsibilities. Cymba provides the slot math and audit tools; the platform built around it determines whether and how a sweepstakes model is compliant in a given market.
Start with a free API key, clone a template, and run your first provably fair spin.