Between the call and the verdict.

SCG.Validate() loads your API key and asks SCG’s server for a nonce before it touches any hardware. The nonce is random, issued to your game, single-use, and expires 30 seconds after it is issued.

Everything that follows is bound to it. The headset signs it into the attestation certificate, the payload carries it both inside and outside the seal, and gate 4 consumes it exactly once. A captured session is worthless against a different nonce, and a nonce is worthless twice.

The API key travels in a request header, so a bad key is refused here — before any cryptography runs and before a nonce is spent.

The bridge asks the Android KeyStore for a new key pair with this session’s nonce as the attestation challenge. The headset’s secure hardware — the TEE — answers with a certificate chain, and the bridge deletes the key as soon as the chain has been read.

The leaf certificate is signed by the hardware and chains to the manufacturer’s root. Inside it: the nonce, your package name, your signing certificate’s fingerprint, the verified-boot state, whether the bootloader is locked, and the security level of the key. None of that can be written by the app. Decompiling the SDK exposes its logic, but the chain is produced by hardware the app cannot reach.

At the same time the SDK collects what only software can see — device model, installer, ADB, developer mode, an attached debugger, root paths — computes the hashed device ID and runs its own scan. These are reports, not proofs. They are sealed in transit so nobody can rewrite them on the wire, but an app that has been hooked could still misreport its own state at the source. That is why they are yours to weigh in gate 8, and why hook detection and the bridge hash exist.

The native library builds the payload and seals it to SCG’s public key — X25519 key agreement with a fresh ephemeral key for every message, then AES-GCM. Anyone can seal; only the server can open.

Outside the seal, readable, are only the routing fields: sealed, nonce, timestamp, sdk_version and bridge_hash. Inside are the hashed device ID, the attestation chain, every check result and every device field. An interceptor sees an API key and an opaque blob.

The nonce and timestamp are carried both inside and outside on purpose. Someone who rewrites the readable copy cannot rewrite the sealed one without the server’s private key, so the two stop agreeing — and the server treats a mismatch as tampering, not as a flag. There is no innocent way to produce one.

What sealing buys: the payload cannot be read, edited or replayed in transit, and the attestation cannot be lifted out of it. What it does not buy: it does not turn a reported field into a proven one. Then the bridge posts it to /v1/validate.

Two shapes come back. A gate that rejects the request answers with an error code and no verdict — TEE_FAILED arrives with a reason, BASELINE_MISMATCH with the field that differed. A decision about a real, identified device — a ban, gate 8, the network fail-rate, or a pass — answers 200 with result in the body.

PASSED arrives with a signed token: a JWT your own server can verify, valid for five minutes, or sixty seconds when Photon custom auth is on. FAILED arrives with nothing. There is no token for a failed session to be tricked with, and the reason stays in your dashboard, not on the client.

The SDK caches the verdict for the session. Validate() called again returns the cached value; ReValidate() runs the full pipeline again, and the bridge allows that at most once every two minutes per player.

Branch on the result. PASSED: load the game and forward the token — to your own server, or to Photon as a custom-auth parameter before ConnectUsingSettings(), where it is verified server-side on every room join, so a bypassed client still cannot walk into a lobby. FAILED: kick, ban or flag for review; SCG never bans on its own. NO_CONNECTION: not a security failure — allow limited offline play if that suits your game and validate again when the connection returns.

In the dashboard you choose which of gate 8’s signals are instant fails, which count toward a flag limit and which are ignored; you can whitelist device IDs; and with cross-game banning on, a device you ban is flagged across every SCG-protected game.

Re-validation is not automatic. When a fresh verdict matters — after a suspicious event, before a ranked match — call ReValidate().