3. Security and data

Written for the person who has to sign off the integration.

What crosses the wire

From your game: a catalog of action ids with costs and cooldowns, and the rounds you open and settle. No player data.

From a viewer: a token you minted, and the intents they submit — an action id, a vote, a stake amount.

To your game: counted intent. {action, count, viewers, dropped} per tick. Not a list of who did what.

What we know about your users

Exactly what you put in the token: an opaque id and an optional display name.

There is no account here, no lookup against anything, and no enrichment. We hold no email, no address, no payment detail and no profile for a licensee's viewer. If your id is a UUID rather than a username, we cannot identify the person at all, and we would encourage that.

The token expires in ten minutes by default. Losing one costs a ten minute window on one channel, and nothing else.

What is stored

Per tenant, isolated:

movement carries an idempotency key.

game, product, amount and timestamp. It exists so a partner report can be produced and checked.

Deliberately not stored for a licensee's viewers: IP addresses, user agents, device fingerprints, or anything else identifying beyond the id you supplied. That is enforced by the shape of the code rather than by policy — the columns do not exist on the rows a licensee's traffic writes.

One precision, because a reviewer will find it in the schema and it is better stated here. IMPAKT's own platform accounts do record a user agent and an IP against a session, for the "signed in devices" list a person uses to see and revoke their own logins. That table is for people who hold an IMPAKT account. A licensee's viewers never touch it: they have no account here, no session row, and nothing is written about them beyond what is listed above.

The event log is verifiable

Each event is hashed together with the hash of the one before it, so the log is a chain. Publishing one hash fixes every event up to that point: any later edit, deletion, reordering or insertion changes it and is detectable by anyone holding the events. This matters for a rev-share on measured lift, where both sides need the numbers to be checkable rather than asserted.

Isolation between tenants

One engine instance per tenant, built the first time that tenant appears. Each has its own sessions, its own wallet and its own view of who a viewer is, and none can see another's, because the engine only ever returns what its own instance created.

A channel of the same name under two tenants is two different rooms, and messages do not cross between them. Both properties have tests standing on them.

Authentication

with === leaks its prefix to a timing attack.

verified before the payload is parsed.

changing one variable with no deploy.

Transport

TLS throughout. The sockets are outbound from your side, so you open no inbound ports and change no firewall rules.

What we would tell your security team unprompted

Three things, because they will find them anyway and it is better coming from us.

The platform runs a single process. Who is live, who is watching and every open round are held in memory in one machine. That is a scaling and availability ceiling, not a data one, and it is the first thing that changes for a partner whose traffic warrants it.

A game that drops mid-session loses its catalog and its open round. The round refunds rather than stranding anybody, but re-registration and replay are not built yet. See 4. Readiness.

There is no moderation layer. No ban, timeout, slow mode or report flow. A streamer cannot currently disable an action mid-stream. If your integration puts this in front of a large public audience, that gap is yours to weigh.

Part of the IMPAKT crowdplay integration pack. All documents.