4. Readiness
What exists, what does not, and what that means for a pilot. Written this way because a partner's engineers will find all of it in the first week, and finding it from us is cheaper for both sides than finding it themselves.
Built and running
- The protocol, end to end: catalog, counted intent, polls, predictions,
fixed-odds markets, two-sided books, and the bankroll where the host stakes and the crowd backs them.
- Multi-tenancy: per-tenant engine, wallet and ledger, with isolation tests.
- Viewer tokens: minted by the licensee, verified here, ten minute life.
- Server-side enforcement: catalog membership, cooldowns, per-tick caps,
balance checks, one vote per viewer, idempotent settlement.
- Durable settlement: movements written as they happen, replay-safe.
- A verifiable event log: hash-chained, one row per action.
- Per-platform identity: Twitch and Kick tokens verified, signature before
parse, algorithm pinned, viewer ids namespaced per platform.
- Measured latency and throughput: see 06-latency-and-scale.md.
- Interaction without video (
media=0), the shape for somebody else's player. - A worked reference game: a blackjack table with real odds, a provably fair
shoe, crowd betting and crowd voting on the play.
Not built
Each of these is a real gap, not a caveat.
A packaged SDK. The protocol is plain JSON over a WebSocket and a client is a thin wrapper, but there is no Unity or Unreal package to drop in. Today a partner writes that wrapper. It is the single largest thing between here and an easy integration, and it is the licensable artifact.
Reconnection and replay. A game that drops loses its catalog and its open round. The round refunds so nobody is out of pocket, but the game must re-register from scratch. A commercial integration needs the server to hand back live state on reconnect.
A Twitch extension. Twitch and Kick viewer tokens are verified and a viewer on either is seated with a namespaced wallet, so the identity half is built. The extension itself is not: no viewer bundle for their iframe, no extension backend service, nothing submitted for review.
Spatial intent. Intent is "what", never "where". Anything positional has to be expressed as discrete zones your game validates, because a viewer clicking a point is clicking a point several seconds out of date.
Moderation. No ban, timeout, slow mode or report flow, and no way for a streamer to disable one action mid-stream.
Horizontal scale. One process holds the channel registry and every open round. A second machine does not share them. The fix is a shared registry and a message bus, and it is understood rather than done.
What that means by integration shape
| Shape | State |
|---|---|
| A. Your game on our platform | Ready. Write a socket client. |
| B. Your game, your platform, our layer | Ready in protocol. You write the client and a token endpoint. No SDK yet. |
| C. A game nobody controls | Host-driven only. Real, but a different product, and it will not become A or B. |
The honest summary
The engine is further along than the packaging. A partner with an engineer who can hold a WebSocket open will have counted intent flowing in a day or two. A partner expecting to import a package and call crowdplay.init() is waiting on work that has not started.
Ask for the pilot on shape A or B. Do not sell shape C as either.
Part of the IMPAKT crowdplay integration pack. All documents.