Theoretical RTP
Cymba can exact-enumerate smaller config spaces or use Monte Carlo simulation for larger and feature-heavy games.
RTP
Cymba helps teams validate slot configs, calculate theoretical RTP where practical, cache RTP results, and track observed RTP from live spin logs.
API example
GET /api/v1/rtp/book-of-secrets
Authorization: Bearer cy_live_...
{
"config_id": "book-of-secrets",
"total_spins": 12847,
"rtp": 95.6582
}
RTP means return to player. It is the long-run expected percentage of wagered value that a game returns as wins.
A game with 96% theoretical RTP is expected to return 96 units for every 100 units wagered over a very large sample. That does not mean every session returns 96%. A player can win big, lose quickly, or sit through long dry periods. RTP is a property of the math model, not a promise about the next spin.
For teams building slot games, RTP is one of the most important numbers in the product. It affects operator economics, game feel, volatility, and audit expectations.
Theoretical RTP is calculated from the game config: reel strips, symbols, paytable, win rules, and features. For simple games, this can often be exact. For large dynamic or feature-heavy games, simulation may be more practical.
Observed RTP is calculated from actual spin logs. It answers a different question: across the spins that have happened, what percentage has the game returned?
Both numbers matter. Theoretical RTP tells you what the game should do over the long run. Observed RTP helps you monitor whether live results are behaving plausibly as volume grows.
Cymba is tied to the same config model used by the spin API. That means the config you validate, spin, and export is also the config used for RTP analysis.
For smaller combination spaces, the engine can exact-enumerate outcomes. For larger games or mechanics that create a bigger state space, it can use Monte Carlo simulation. Feature contributions can be broken out so teams can see how much RTP comes from base wins, scatters, free spins, hold and respin, meters, jackpots, random multipliers, or other mechanics when available.
The dashboard can cache RTP results for a game config so expensive calculations do not need to run on every page load or PAR sheet export.
RTP is not something you should discover after launch.
Small changes to a reel strip, paytable, scatter trigger, free-spin multiplier, or max-win cap can shift the economics of a game. A config editor without RTP feedback creates risk because non-engineers can make math changes without seeing their long-run impact.
Cymba's product flow keeps these pieces close: edit or clone a config, validate it, calculate RTP, run playground spins, and export audit material.
Cymba logs spin outcomes as multipliers and line counts. It does not log money. The observed RTP endpoint aggregates those logs for a stored config and returns total spin count plus observed RTP.
This gives teams a lightweight monitoring signal without turning Cymba into the wallet or ledger.
RTP should be communicated carefully. It is a statistical expectation, not a per-player guarantee.
High-volatility games may need very large samples before observed RTP settles near theoretical RTP. Bonus-heavy games can also show large swings if rare features drive a meaningful share of the return.
Cymba helps expose the math, but operators are still responsible for how they present games, manage player balances, and comply with their market's rules.
Start with a free API key, clone a template, and run your first provably fair spin.