Config included
The PAR sheet includes the canonical game config and config hash so reviewers know exactly what math model is being checked.
Audit
Cymba turns a stored game config into a self-contained PAR sheet bundle with canonical config data, RTP results, math reference material, and deterministic replay fixtures.
API example
GET /api/v1/par-sheet/book-of-secrets
Authorization: Bearer cy_live_...
{
"config_id": "book-of-secrets",
"spec_version": "1.0",
"config_hash": "f91a...",
"theoretical_rtp": {
"total_rtp": 96.08
},
"verification_fixtures": [
{
"fixture_index": 1,
"expected": {
"result_hash": "d4e5f6..."
}
}
]
}
A PAR sheet is a math reference document for a slot game. It describes the game's configuration and expected return characteristics so the game can be reviewed, implemented, or audited.
In traditional slot development, PAR sheets are part of the bridge between game design, math, engineering, and compliance review. They give reviewers a concrete model to inspect instead of relying on screenshots or informal descriptions.
Cymba treats the PAR sheet as an exportable product surface.
A Cymba PAR sheet bundle can include:
The important idea is that the artifact should be self-contained enough for review. A math consultant should be able to inspect the config, understand the relevant model, recompute or check RTP, and replay deterministic fixtures.
If a game changes, the math changes. Even small edits to reel strips or payouts can affect RTP and volatility.
That is why a Cymba PAR sheet includes a config hash. The hash binds the exported artifact to a specific canonical config. Live spin responses can also expose config hashes, letting operators compare a spin against the PAR sheet that supposedly describes it.
This creates a clear check: if the hashes do not match, the spin and PAR sheet are not describing the same math model.
Fixtures are sample spins with known inputs and expected outputs. Cymba's PAR sheet exporter generates public fixture seeds, client seeds, nonces, and round IDs, then captures expected result hashes.
An external reviewer can implement the same protocol and math model, replay those fixtures, and compare hashes.
If the hashes match, the reviewer has stronger evidence that their implementation and Cymba's result serialization align for those cases. If they do not match, the mismatch points to a config difference, a math interpretation difference, or a regression that needs investigation.
PAR sheets sit after configuration and RTP calculation.
A typical flow is:
That flow keeps the audit artifact tied to the actual config used by the API.
A PAR sheet is not a gambling license. It is not regulatory certification. It does not verify an operator's wallet, player accounting, or jurisdictional controls.
It is a structured math artifact. For Cymba, that is exactly the point: isolate and document the slot math layer so it can be reviewed without pretending to be the entire casino platform.
Start with a free API key, clone a template, and run your first provably fair spin.