7. Economy and licensing
How the money works: what the coin is, how viewers get it, who is paid what, and what changes when the layer runs on your platform instead of ours. Every number here is read from the code that enforces it, not from a plan.
The unit
The in-app currency is called coins. Its exchange rate is fixed in one place in the code: 100 coins correspond to 1.00 USD (1 coin per cent). Every price, every revenue share and every payout derives from that one number, so the store, the ledger and the payout math cannot disagree. It lives on the economy sheet as coinsPerMinor and is read where it is used, so changing it is an admin action rather than a deploy.
One balance, two buckets underneath:
| Bucket | Where it comes from | Playing | Settling |
|---|---|---|---|
| Cash | Bought with money | Identical | Pays out, backed by the money that bought it |
| Promo | Earned watching, daily allowance, pack bonuses | Identical | Settles to zero, backed by nothing |
This split is the load-bearing wall of the whole economy. A promotional coin had no money behind it, so no revenue share is ever booked against it. The viewer cannot tell the buckets apart while playing, the ledger never confuses them, and the platform can never owe real money against coins it printed.
A second rule sits on top, and it now has two settings rather than one.
On our own site, bought coins may be staked. The loop is closed: there is no cash-out, no transfer between viewers, and every payout is coins or cosmetics, so a bet never pays money to anyone whoever funded it. purchasedCoinsCanBet governs this and is on.
Inside a host platform, only earned coins may be staked, whatever that switch says. A viewer arriving from Twitch or Kick is judged by that platform's rules on anything resembling a wager, and the honest answer there is that money spent through the host buys participation and never a stake. platformPurchasesCanBet governs this and is off.
Both are enforced in the wallet against the ledger, not in the UI, so a client cannot opt out of either.
How viewers get coins
| Route | Amount | Notes |
|---|---|---|
| Watching | 5 coins per minute | Capped at 900 a day; per account, live streams only, server-clocked. Both numbers are settings |
| Daily claim | 20 coins | Flat, not an escalator. Day seven of a run pays 50 more, day thirty grants a cosmetic |
| First vote of the day | 10 coins | Paid once a day for taking part at all |
| Welcome | 300 coins | Expires after 72 hours if unused |
| Packs | 300 coins for $2.99 up to 15,000 for $99.99 | Headline includes a promo bonus; the backed part is exactly price times the exchange rate |
| Bits, on Twitch | 1 coin per Bit | The only checkout Twitch permits inside an extension. Bought this way, it cannot be staked |
Prices live on the server only. The server refuses to boot if any pack's headline disagrees with the backing math, so a mispriced pack is an outage, never a quiet loss.
Who is paid, and how much
Streamers earn from three flows. All shares are computed on the backed part only, the portion of the spend that real money stands behind.
| Flow | Streamer share | Example |
|---|---|---|
| Direct spends in their channel (gifts, artifacts, support) | 25% of the backed value | A viewer spends 900 bought coins ($9.00) on an artifact: the streamer is owed $2.25 |
| House rake on settled betting pools | 40% of the backed rake | The house takes 10% of a settled pool; the streamer gets 40% of whatever part of that rake was funded by bought coins |
| Blackjack table and bankroll rounds | Same rake rules | The engine rakes profit at the same 10% and shares it the same way |
| Bits spent in their Twitch panel | 80%, paid by Twitch | Twitch's own split, not ours. The extension developer receives the remaining 20% and we do not touch the money |
Payout terms: earnings mature after a 15 day hold (the card dispute window), minimum payout $50.00, paid via Stripe. Everything is booked in an append-only ledger with idempotency keys, so a replayed webhook or a retried settlement can never pay twice.
The platform books 15% of a backed spend as its own revenue, recorded as a line in the event chain rather than inferred, and keeps 60% of the backed rake. The remainder of a spend recirculates as coins. Promo play costs the business nothing beyond serving it, because no money ever stood behind those coins.
What a game needs to plug in
No access to the game's code, and no SDK we must approve. The integration is an outbound WebSocket from the game (or its backend) to the crowdplay server. The game:
1. Connects with its key and declares a catalog: what the audience may do. 2. Receives one aggregated count per action per tick, never raw clicks. 3. Opens polls, betting markets, two-sided books or a table when it wants one, and settles them by naming the winner.
The game stays authoritative the whole way. We never render its pixels, never hold its users, and cannot move its state; we can only tell it what the crowd asked for. A studio integrates in days because the surface is deliberately small: connect, declare, read one number, settle.
Does the host platform have to be compatible?
No platform partnership or approval is required for the tech to work. What varies by platform is only where the panel lives:
| Surface | How | Status |
|---|---|---|
| Our own site | The panel is in the watch page beside the player | Live |
| Any site the licensee owns | Same panel, embedded, their token identifies the viewer | Live (tenant mode) |
| Twitch | A native extension inside Twitch's own player, viewer identity signed by Twitch | Built, submitted for review |
| Kick | Kick has no extensions platform, so a companion second screen at our URL, opened beside the stream | Live |
| Anywhere else | The companion pattern generalises: any platform with a chat to share a link in can carry it | Pattern proven by Kick |
Viewers who arrive from a host platform without an account here hold an earned-only staking wallet. Until Bits existed this was true by construction, since somebody with no account had no way to buy anything. Bits gives them one, so the rule is now stated rather than assumed: money spent through a host platform buys participation, never a stake. It is enforced in the wallet against the namespaced viewer id, so it holds however a client is modified.
Twitch and Bits
The economy does not use Bits, deliberately. Twitch's policy is that anything sold inside an extension must be sold through Bits, with Twitch taking its share. Our panel therefore sells nothing: inside Twitch it is earned-only, which keeps it cleanly inside both the monetisation policy and the rules on prediction-like features.
Real-money purchases happen on our own site, on our own Stripe account, at the full margin. A viewer who wants to buy coins does it there and the balance is theirs everywhere the account works.
A Bits-priced purchase path inside the extension is possible later if the funnel justifies it, but it hands Twitch a platform cut and a second price list to keep honest, so it is a decision to make with data, not a default.
Licensing: the two economy models
A licensee chooses one of two shapes, and the engine checks which one it is rather than assuming:
Hosted economy (ours). The licensee's viewers get balances in a ledger we run, keyed inside that tenant so ids never collide across licensees. We operate the coin, the store and the settlement; revenue shares are booked the same way as on our own platform. This is the turnkey option.
Their own currency. The licensee supplies their wallet to the engine and we never see a balance. Debits, credits and settlement happen in their system; they pay their streamers however they already do. The engine's rake hooks are optional and are simply not wired. This is the option for anyone with an existing economy, including operators whose currency is regulated.
In both shapes the licensee's users stay theirs: we learn an id and a display name from a token their backend signed, and nothing else crosses.
Part of the IMPAKT crowdplay integration pack. All documents.