Solving a slot to a target RTP

The short version. You rarely hit an exact RTP by tweaking pays and reels by hand. The reliable way is to simulate a large set of rounds in classes (losses, base wins, feature rounds, win-cap rounds), then let an optimizer choose how often each round happens so the mode lands on your targets: the RTP, plus hit rate and feature frequency. Check the result, then repeat for every bet mode.

Why hand-tuning stalls

Every number in a slot pulls on every other. Make a symbol pay more and the RTP rises, so something else has to pay less; make the feature richer and it has to come less often. By hand, you end up nudging reel strips, re-simulating, and landing at 96.4% when you needed 96.5%, over and over. If RTP, volatility and hit rate are new to you, start there.

Solving flips the problem around. Instead of guessing inputs and measuring outputs, you generate plenty of real rounds first and then choose their frequencies to hit the outputs you want.

Step 1: decide the targets

Per bet mode, write down:

• The RTP. On Stake Engine every mode, including bonus buys, must sit between 96.0% and 96.7%.
• How the RTP splits between the base game and the feature. A larger feature share makes the game more volatile.
• Hit rate (how often a spin pays anything) and feature frequency (1 in N spins).
• The max win (win cap), and roughly how rare it should be. Stake Engine expects it to be "realistically obtainable", typically more often than 1 in 10,000,000.

Step 2: simulate in classes

Simulate rounds in outcome classes rather than purely at random. In the Stake Engine math SDK these are criteria with quotas: for example a share of simulations that must be losses, a share that must be base-game wins, a share that must trigger the feature and a small share that must hit the win cap. A round is re-run until it meets its class.

The point is coverage. Pure random simulation produces only a handful of win-cap rounds, and players would see the same rare round again and again. Classes guarantee enough distinct rounds in every part of the distribution; the next step decides how often each part actually happens. For production, Stake Engine's guidance is 100,000 to 1,000,000 simulations per mode for slots.

Step 3: optimize the weights

An optimizer then assigns each round a weight, its chance of being picked, so the totals match your targets. The math SDK's optimizer is a genetic algorithm written in Rust. Per mode you give it:

• Conditions per class: two of RTP, average win and hit rate. Order matters; put the win cap first.
• Scaling: a bias toward or away from particular win ranges.
• Parameters: how many trials, and minimum and maximum mean-to-median ratios, which is how you steer volatility.

The output is a re-weighted lookup table: the same rounds, with new frequencies. Nothing about the rounds themselves changes, which is why a solved game's RTP is exact rather than estimated.

Step 4: check what you got

• Every mode's RTP inside the target band, not just the base game.
• Hit rate and feature frequency where you designed them (Stake Engine treats non-zero wins rarer than 1 in 50 as a concern).
• No gaps in the win ranges, and the win cap actually present in the books.
• Standard deviation of the base mode at least 0.6 (a Stake Engine critical test), and the risk measures if you're aiming for the highest bet limits.

The math SDK's analysis step writes a PAR sheet (hit rates and RTP contributions per class), which is the easiest place to see whether the feature is carrying the share you meant it to.

Common mistakes

• Solving only the base mode and forgetting the bonus buy, which has its own RTP.
• Too few simulations in a rare class, so the optimizer has almost nothing to weight.
• Targets that fight each other (a very high hit rate with a very rich feature), so the optimizer can't satisfy both.
• Changing pays after solving: any change to what rounds pay means simulating and solving again.

How Volt does it

In Volt's Math workspace the targets are settings: the RTP, how close each mode has to land, and the max win. Press Solve, pick how many rounds per mode (10,000 for a quick check, 100,000 for Engine's minimum, up to 1,000,000), and Volt simulates every bet mode on your Mac and runs the math SDK's optimizer to weight them to the target. The results table shows each mode's RTP, hit rate, feature frequency and max win against the targets, and the same numbers feed Ship's checks.