From spin request to result, a full walkthrough of the two-stage control pipeline
A flowchart-led tour of the spin pipeline and its two-stage control model: RTP table selection and weighted result picking, with interpolation fallbacks.
A slot's regulation system is a dynamic control layer sitting on top of the natural probability model, used to achieve flexible RTP management and player experience optimization while preserving the game's mathematical correctness. The regulation system never tampers with the game's core probability model; instead it adjusts the result selection strategy through compliant mechanisms.
The distinction here is crucial. Regulation does not mean "modifying" an already computed result after the player presses Spin; it means deciding, before sampling, which fully mathematically verified distribution to sample from. The RTP, volatility and Hit Rate of every candidate distribution are computed and sealed in advance; all the regulation layer does is make a weighted choice among these distributions. Once this design boundary is held, the mathematical properties of the whole system remain forever derivable and auditable.
The need for such a control layer stems from a practical gap: the mathematical model guarantees long-term convergence, but the player experience happens in a short-term sample. On a high-volatility machine with a theoretical RTP of 96%, the realized return over a few hundred rounds may fall anywhere within an extremely wide interval. The purpose of the regulation layer is to make the short-term distribution more predictable and closer to the design intent, without shaking the long-term expected value.
From arrival to response, every Spin request goes through the following complete processing pipeline:
The design principle of the whole pipeline is to concentrate uncertainty in a single stage. Parameter parsing, mode determination, board lookup and result scaling are all deterministic pure functions; the only place randomness is introduced is the regulation stage. This makes the entire flow very easy to test: replace the random source with a fixed sequence, and the same set of inputs necessarily produces the same set of outputs, so regression tests can compare round by round without tolerating any error margin.
The core of regulation is divided into two stages executed in sequence:
The two-stage split corresponds to two problems of completely different nature:
Handling the two together produces a situation that is very hard to maintain: any adjustment to the feel may accidentally alter the expected value, and any numerical adjustment affects the feel, with the two requirements checking each other until neither can be moved. Once split, the first stage is responsible only for expected value, while the second stage promises to change only the shape of the distribution and never the expected value. Responsibility boundaries are clear, and their verification methods are completely different too: the former verifies convergence, the latter verifies variance and tail characteristics.
The system pre-configures several probability tables with different RTPs (such as LOW / MIDDLE / HIGH), and stage one's job is to decide, according to an established strategy, which table this Spin uses. The selection logic falls into three kinds according to the regulation mode (set independently per configuration group):
When the target RTP falls between two probability tables, a probabilistic choice is made through linear interpolation:
P(choose LowRTP table) = (HighRTP - targetRTP) / (HighRTP - LowRTP)
Over long-run statistics, the actual RTP converges precisely to the target value. Interpolation precision is usually scaled up to the ten-thousandths (×10000) for integer arithmetic, avoiding floating-point error.
The correctness of the interpolation follows directly from the linearity of expected value: if a table with RTP R₁ is chosen with probability p and a table with RTP R₂ with probability 1−p, then the overall expected return is p·R₁ + (1−p)·R₂. Substituting p from the formula above yields exactly the target RTP. This shows that interpolation is not an approximation technique but a strictly holding identity. As long as each table's own RTP is accurate, the interpolated target value carries no systematic bias.
What must be kept in mind is that interpolation only guarantees the expected value, not the variance. After mixing two distributions, the overall variance is larger than the weighted average of the two variances, and the excess is proportional to the square of the RTP gap between the two tables. This means adjacent tiers should not be spread too far apart: the wider the tier spacing, the more noticeably the volatility in the middle of the interpolation deviates from the design value. In practice you work backwards from "the variance increase after interpolation must not exceed an acceptable proportion" to decide how finely the tiers should be cut.
Switching to integer arithmetic addresses reliability at another level. Floating-point numbers may show last-digit differences across hardware and compiler options, and once a regulation outcome depends on such a difference, deterministic replay no longer holds. Scaling all probabilities to the ten-thousandths and handling them as integers means the same set of inputs takes the same branch in any environment.
Dynamically adjust RTP according to the aggregate statistical pool level:
(cumulative wagered - cumulative paid out) > cumulative wagered × (1 - gameRtp)The essence of this mechanism is a negative feedback controller: when the actual statistical RTP is above the theoretical value, it means the recent sample leans toward the player's side and the system lowers the target slightly; when it is below the theoretical value, the system raises it slightly. Over the long run the actual RTP is pulled back to oscillate around the theoretical value, instead of converging slowly at a rate of 1/√N as pure natural probability would.
The difficulty in designing the controller lies in response speed. Respond too slowly and it becomes pointless; respond too quickly and the player feels a noticeable change of rhythm within a short period, which damages the experience instead. The common approach is to set upper and lower bounds on the adjustment magnitude, and to make the adjustment proportional to the degree of deviation rather than a step jump, so that RTP changes smoothly enough that an individual player can hardly perceive it.
Providing an RTP boost during a trial period for new players:
The core design here is conservation of expected value within the cycle: whatever the trial period pays above the norm must be recouped by the recovery period paying below it within the same cycle, so that the weighted average RTP of the whole cycle equals the base value. In other words, support mode changes the ordering of the distribution of returns along the time axis, not the total amount.
The reason individual correction is needed is that the cycle scheme only guarantees the average, not every player's actual trajectory. If a particular player happens to draw a high-multiple result during the trial period, their cumulative RTP may already be far above target, and applying the fixed recovery magnitude at that point would over-compensate. Making a real-time correction from the individual's cumulative statistics lets convergence happen at the individual scale rather than only at the aggregate scale.
Once the RTP table has been determined, stage two picks the concrete game result from that table's payout-weight distribution by weighted random draw. The selection strategy is determined by the weight mode:
The core logic of the SD1 / SD2 / SD3 modes:
What this flow aims to achieve is a constrained optimization: compress the distribution's standard deviation to within the target under the hard constraint that the expected value must remain unchanged. Since the expected value is the inner product of probabilities and payouts, the RTP trimmed from the tail must be added back to other bands intact, or the overall expected value shifts. This is the step most prone to implementation error, and the one that most requires automated verification to guard it.
Why trim "starting from the high-multiple tail"? Because payout appears as a squared term in the variance computation, so high-multiple results contribute far more to variance than they do to expected value. To take an extreme example: a result with probability one in ten thousand and a payout of 1000x contributes only 0.1 to RTP but about 100 to variance. This means trimming the tail buys a large drop in variance for a very small shift of expected value, making it the most efficient direction to compress in.
The place it is added back is deliberately chosen to be the mid-range band from "average payout to cap". Adding all the RTP back to the lowest payout would concentrate results too heavily on small returns that are barely felt at all, and the player would feel "constantly hitting, yet never hitting anything"; adding it back in the middle maintains a certain sense of reward tiering, and is the compromise between mathematical correctness and player feel.
Setting a cap is not only about controlling variance; several practical considerations are involved.
Tying the cap to the bet amount keeps the compression effect consistent across bet tiers. Because standard deviation is computed in units of multiples, the same multiple cap represents different absolute volatility at different bet amounts, so the threshold and the cap are usually set in segments by bet band rather than as a single fixed value.
The two-layer weighted draw design decouples the "payout tier" from the "concrete presentation". The upper layer decides how much this round pays, a numerical question; the lower layer decides which board presents that payout, a presentation question. Under the same payout tier there are often dozens of different board combinations: some may be line wins, some may come from free games, and some may be the result of a special feature. They are numerically equivalent but visually quite different. The weights at this layer can therefore be configured purely by presentation rhythm, with no need to worry about affecting RTP at all.
After weighted selection produces a presentation index:
actual bet / template betProportional scaling holds because a slot's payout is essentially a linear function of the bet amount: the board determines the multiple, and the bet amount is merely a multiplier. This lets one template serve every bet tier, so the size of the template library is independent of the number of bet options.
In implementation the one thing to be careful about is rounding error. When a board contains several payouts that are each scaled and then summed, the result of rounding item by item may differ from the result of scaling the total by the smallest unit. The correct approach is to scale on the basis of the total and then distribute the difference back to each line item according to an established rule, ensuring the invariant "the sum of the line items equals the total" always holds.
The core design principle of the regulation system is graceful degradation: in any situation of missing configuration, abnormal parameters or an unavailable external dependency, the system silently falls back to natural probability mode.
The judgment behind this principle is that natural probability is always a safe answer. It has passed full mathematical verification, depends on no external state, and requires no configuration. So when the regulation layer cannot function properly, the best handling is not to abort the flow but to fall back to this known-correct baseline. By comparison, choosing to fail the request would make the game outright unplayable; choosing to reuse the previous computation result would introduce unpredictable statistical bias. Both are worse than degradation.
The situations that trigger degradation fall broadly into three categories:
The last point is also the most easily overlooked: degradation must be observable. A silent fallback is imperceptible to the player, and that is precisely the design goal; but for the development team, if there is no way to distinguish "regulation working normally" from "degrading all the time", the system will drift away from its design intent for a long time with nobody noticing. Every degradation should therefore record its cause and context, and the degradation rate should be tracked statistically, so that this safety net is itself kept under inspection.