1. Integration overview

What the layer does

Viewers watching a live game act inside it. They vote the next play, back the player with their own stake, bet for or against an outcome, and fire single-use powers. The game receives those as counted intent and decides what happens.

Three rules hold the design up, and they are worth understanding before the protocol, because everything in it follows from them.

The game is authoritative. Viewers never send commands. They send intents, the server counts them, and the game is handed a tally. Ten thousand viewers asking for the same thing arrive as one number with a count on it. A viewer cannot spawn anything; they can only ask, and your game decides.

Everything is deadline based. Video reaches a viewer one to eight seconds after the moment it shows, so a viewer is always acting on a stale picture. Every poll carries a server-side deadline and the server's own clock, and the expectation is that you draw the countdown into the video. Then the clock a viewer reads on the stream is the clock the server is enforcing. A poll shorter than your video delay is a poll most of your audience cannot answer.

The currency is a closed loop, on our platform. Viewers get coins by taking part or by buying them, and both play the same. What keeps the interaction layer clear of gambling regulation is the exit rather than the entrance: coins cannot be cashed out, transferred between viewers, or converted into anything, and every payout a round makes is coins, cosmetics or status. A wager for money needs a prize of value, and there is none to give.

One exception is open at the time of writing: our own gift shelf still redeems coins for physical merchandise. It is named here rather than left for your counsel to find, and it is being resolved before any licensed deployment.

Inside somebody else's platform it is stricter, by construction rather than by rule: a viewer with no account here has no purchase path, so their balance can only ever be what they earned. That is the shape Twitch and Kick require of anything resembling a prediction, which is why the same layer runs inside them unchanged.

On a licensee integration the currency is yours: your viewers arrive with a balance from your ledger, and settlement happens against it, under whatever rules you operate. See 3. Security and data.

The three shapes, and which one you are

The shape determines the work. Most conversations go wrong by assuming a different one from the other side, so this is the first thing to settle.

A. Your game, our platform

Your game runs on an IMPAKT channel. Your game process holds a socket to us, publishes a catalog, and receives intent. Viewers are IMPAKT accounts using IMPAKT currency, and we handle identity, wallet and settlement.

You build: a socket client in your game, the catalog, and the handlers that apply what the crowd asked for.

Ready today. This is the path the platform's own games use.

B. Your game, your platform, our interaction layer

Your players stay on your site or in your client. You render everything. We carry only the interaction: a socket per game, a socket per viewer, and the counted intent between them. Your viewers are identified by short-lived tokens your backend mints with your own secret, so you never hand us a user database and we never hold your accounts.

You build: the same game-side client as A, plus a token endpoint in your backend, plus the viewer-side UI. media=0 on the viewer socket takes chat and crowdplay without video, which is exactly this shape.

Ready today, with the gaps in 4. Readiness — the missing piece is a packaged SDK, not the protocol.

C. A game we do not control

A streamer plays a third party title, on any platform. The game cannot hold a socket, so nothing can be authoritative inside it. What remains is host driven: the streamer or an operator opens a round, the crowd bets or votes, and a human settles the result.

This is real and it works — it is how the platform's own blackjack table runs — but it is a different product from A and B, and it will not become them. If a proposal says "works with any game", this is the shape it means.

What you need to run

• A process that can hold a WebSocket open. Anything: Unity, Unreal, a Node

service beside your game server, a Python worker.

• For shape B, an HTTPS endpoint in your backend that mints viewer tokens.
• No inbound ports. Both sockets are outbound to us.

What we need from you

• A slug and a shared secret, which we exchange out of band.
• The list of actions your game will accept, with a cost and a cooldown each.
• A decision on the currency: ours, or yours settled through your ledger.

Part of the IMPAKT crowdplay integration pack. All documents.