18+ --:--:-- UTC

Server decides, device shows

On a regulated game the outcome is generated and logged by the operator's server the instant you commit to a round — your device only plays back an animation of a decision already made.

The keystone of online-game integrity is that the result does not live on your phone. GLI-19, the technical standard most regulated markets certify against, requires that every critical function — above all the generation of the game outcome — be produced by the operator's central platform and be independent of the device in your hand. The device is a thin client: it commits your stake, then renders an animation of a result the server has already determined and recorded. This one fact explains why a dropped connection cannot cost you a settled win, why disputes are read from the server log rather than your screen, and why a round cannot be hurried past its regulated minimum. What it does not prove, on its own, is that the game offers fair value — that is the separate work of RNG and RTP certification.

The thin-client model

Picture the split of labour between the two machines. Your device is a presentation layer: it takes your input, sends the commit to the platform, and then draws whatever the platform tells it — spinning reels, a rising multiplier, a dealt card. The determinative work happens elsewhere. The moment you commit to a round, the platform's random number generator fixes the outcome, the platform writes it to the game log, and only then does your screen begin the animation that reveals it. Nothing you do on the device between commit and reveal can reach back and alter a result that already exists server-side.

What "critical functions" means

GLI-19 §2.6.5(g) states that "all critical functions including the generation of any game outcome shall be generated by the Gaming Platform and be independent of the Remote Player Device." The phrase carries weight: a critical function is anything that determines or records what happens in a round — the RNG call, the mapping of that random value onto the paytable, the settlement of the wager, the write to the audit log. All of it sits on the platform. The device is trusted to display and to collect input; it is not trusted to decide. A tampered or spoofed client is therefore a client that can misbehave on screen without ever changing the outcome the server has banked.

Why regulators mandate it

The rule serves three ends at once: integrity, because the result cannot be manufactured or manipulated on an untrusted consumer device; auditability, because the authoritative record of every round lives in one controlled place a regulator or test lab can inspect; and tamper-resistance, because moving the decision off the device removes the attack surface a modified app would otherwise offer. The requirement is near-universal in certified markets. Ontario's Registrar's Standards carry an equivalent obligation (Standard 4.31), and several other regimes echo the same server-authority principle in their own technical rules — among them Greece, Spain, Italy and Colombia.

What it settles: disconnection, disputes, speed

Three player-facing questions collapse into this one principle. Disconnection: because the outcome was fixed and logged the instant you committed, a lost connection cannot re-roll it or quietly void a stake — the interrupted round is recovered and settled from the server record (see game recovery). Disputes: "what I saw on my screen" is not the evidence; the platform's game log is, which is why a contested round is adjudicated from that log. Speed: because the server gates when the next round may begin, it can enforce a minimum round duration no client-side trick can shorten (see the minimum-round-time rule).

The honest boundary

Server authority proves one thing precisely — that your device cannot change the odds or the result — and it is important not to stretch it into a claim it does not support. It does not, by itself, show that the game is fair value: that the RNG is unbiased, that outcomes are drawn as the paytable claims, or that the advertised return to player is real. Those are the province of RNG certification and RTP verification. Server authority answers "does my phone decide the result?" with a clear no; "is the game itself fair?" is a separate question with its own separate proof.

Worked example

You tap spin on a certified slot and your connection drops before the reels stop. The result is not waiting to be computed on your phone — it was generated by the platform's RNG and written to the game log at the instant of your commit. When you reconnect, game recall shows the round already settled: the balance change stands whether the animation ever finished on your device. The screen was always going to show a decision the server had already made and recorded.

Key facts

Primary ruleGLI-19 v3.0 §2.6.5(g) — critical functions on the platform"the generation of any game outcome shall be generated by the Gaming Platform and be independent of the Remote Player Device"
What must be server-sideAll critical functions, above all outcome generation and the RNGthe device presents and collects input; it does not decide
Mirrored inOntario Registrar's Standard 4.31; echoed by Greece, Spain, Italy, Colombianear-universal across certified markets
The boundaryProves the device can't change your odds — not that the game is fair valuefair value is proven by RNG and RTP certification instead

Education, not advice. This explains what certification standards require so you can read a game clearly — it is a teaching summary, not legal or compliance advice. Requirements vary by market and change; always confirm against the standard and the local regulator. 18+.

Get the iGamer Briefing

A short, cited email when something in iGaming changes — plus one fundamental worth understanding. Independent, 18+, no hype.

18+. No spam, no operator ads. See our privacy note. Unsubscribe anytime.