How to design a free token economy for your sportsbook

A free token economy for a sportsbook is the set of rules that decides how players get virtual tokens for your community and what they can do with them. For a play-for-fun sportsbook the answer is always the same at the edges: tokens come in for free (a starting balance, a refill, points for taking part) and nothing of value ever comes out. Inside those edges you have real design choices, and they decide whether your community keeps playing.

The rule: free in, nothing of value out

Our Play-for-Fun Policy puts it in one sentence: no player, and nobody else taking part, pays, risks, wins or receives anything of monetary value. The tokens in your sportsbook must be worthless in both directions.

Two things follow that shape every decision below.

First, you can't make tokens valuable by making them scarce. If players run out and have no free way back in, some will look for tokens elsewhere, and a black market in "free" tokens is exactly the value leak the rule exists to prevent. The policy requires a free route to keep playing at all times.

Second, anything that looks like money pushes the design the wrong way. Your token label is a word like TOKENS, COINS, POINTS or your community's own name, never $, €, USD or BTC. Your refill button says "Get more tokens", never "Deposit" or "Buy". A negative balance after a corrected result is a record, never a debt.

Starting balance: how big?

The starting balance is the first number a player sees, and it should be tied to your stake limits. In the console you set a minimum stake, a maximum pre-match stake, a maximum live stake and a maximum return per bet. Decide those first.

A simple way to size it:

The ratio matters more than the number. Somewhere between 20 and 50 typical stakes gives a new player room to try accumulators and live bets without going broke in one evening, while still making a bad weekend visible on the leaderboard. Everyone must start with the same amount.

With the managed balance (the Hosted Token Balance), we keep each player's token balance as a record, and your server credits tokens through the API. The credit call creates the player if they don't exist yet, so you can load the starting balance before their first session:

curl -X POST https://api.thesportsbook.app/b2b/v1/users/viewer-42/credit \  -H "Authorization: Bearer $SPORTSBOOK_API_KEY" -H "Content-Type: application/json" \  -d '{"amount": 50, "idempotency_key": "credit-8f1c2", "reason": "Daily free tokens"}'

The response returns the new balance, an operation id and a replayed flag. The idempotency_key is what makes this safe: if a request times out and you retry with the same key, the tokens are applied at most once. For a starting balance, a key like start-viewer-42 means a player can never be credited twice, however many times your sign-up code runs. The reason shows up in the player's history in your console. Details are in the docs on the hosted token balance (opens in a new tab).

Refills: daily or weekly, and the "Get more tokens" button

Refills are the free route the policy requires. Two common designs:

• Flat refill: add a fixed amount once a day or week. Simple, but active players drift upward over time.
• Refill to a floor: if a player's balance is below a threshold, bring it back up to it. Players who bet well keep their lead; players who went broke can play again tomorrow.

Refill-to-floor usually suits a leaderboard better, because it doesn't reward simply showing up every day with an ever-growing balance. You read the balance (GET /b2b/v1/users/{user_ref}/balance) and credit the difference.

Make the idempotency key carry the period, for example refill-viewer-42-2026-09-28. A double click, a retry or two browser tabs can't then give the same player two refills on the same day.

Inside the sportsbook, a player can press "Get more tokens". The SDK turns that into the tokens-requested event on your page, with the player's balance and your token label, so your code can show the refill:

<div id="sportsbook"></div><script src="https://play.thesportsbook.app/sdk.js"></script><script>  const sportsbook = TheSportsbook.init({    container: "#sportsbook",    launchUrl: "LAUNCH_URL_FROM_YOUR_SERVER",    height: "auto",    onBetPlaced(bet)    { refreshBalance(); },    onTokensRequested() { openFreeRefill(); },    async onSessionExpired(e) {      if (e.reason === "user_blocked") return;      const { launch_url } = await fetch("/api/sportsbook/session", { method: "POST" }).then((r) => r.json());      sportsbook.updateToken(launch_url);    },  });</script>

openFreeRefill, refreshBalance and the session route are your own code. Two rules for whatever openFreeRefill shows: it must not sell tokens, show a price or accept a payment, and it must not lead to a page where anything convertible into tokens can be bought. And the event itself is only a signal. Never credit tokens because the browser said so; let the player ask your server, and let your server decide.

Tokens for taking part, at one rate for everyone

Activity tokens are the most fun part to design and the easiest to get wrong. Permitted sources are free and unrelated to money: watch time, follows, chat activity, completing a community profile, attending a free community event. Channel points can be converted too, as long as the rate ignores any subscriber multiplier or bonus; Twitch Predictions vs a play-for-fun sportsbook explains why most streamers keep the two apart anyway.

The test for every rule you write is: does the number of tokens a player gets ever depend on whether they, or anyone else, paid? If yes, it's out.

Keep the activity rate modest compared with the refill. If watching for a weekend earns more than a month of good bets, the leaderboard stops measuring anything interesting.

What's off-limits, with examples

The prohibited list is long because people are creative. Tokens must never be:

• sold, or offered for money, crypto or any other payment;
• bundled with or granted as a perk of a paid subscription, membership, tier or pass, including gifted subs;
• granted for donations, tips, bits, super chats or similar paid interactions;
• granted in proportion to money spent ("1 token per $1 spent");
• given with the purchase of merchandise, games, in-game items or anything else;
• converted from points, currency or items that were bought or have value, including redeemable loyalty points;
• granted for an entry fee;
• earned on offer walls, paid surveys, free trials or third-party sign-ups.

On the way out, the same logic applies. Tokens, balances and rankings can't be exchanged for money, gift cards, discounts, goods, tickets, subscriptions, or in-game items that can be bought or traded. Players can't send tokens to each other, and accounts can't be sold.

Loyalty programs: a separate free balance only

Plenty of operators already run points: a store loyalty scheme, a membership tier, a game's soft currency (studios should read adding a sportsbook to your game or app, which covers purchasable currencies in detail). The question is always "can I use those points in the sportsbook?" The answer is no, unless those points themselves meet every play-for-fun rule, which redeemable loyalty points never do.

What you can do is run the sportsbook "with a separate free token balance that can't be converted to or from your loyalty points". Members get sportsbook tokens the same free ways as everyone else. The two balances never touch: no conversion in, no conversion out, no loyalty points for good bets.

Seasons and resets

Seasons give a play-for-fun sportsbook a rhythm. A league season, a tournament or a calendar month works; a company or club betting league usually follows the domestic season. At the end, everyone goes back to the same starting balance and the leaderboard starts again.

A reset with the managed balance is a few API calls per player:

1. Wait until open bets have settled. GET /b2b/v1/rounds/open shows what's still open; tokens on open bets settle into the balance later, and a reset before that skews the new season.
2. Debit each player's balance down to zero (read the balance first; a debit larger than the balance is refused with nothing moved).
3. Credit the new season's starting balance with a key such as season-2026-10-viewer-42.

Keep last season's final standings on your own site. A season reset is on the allowed list in our policy; wiping people's history is just bad community management.

Recognition that works: leaderboards, badges, roles, shout-outs

"Leaderboard positions, badges, titles and community roles are fine; prizes of value are not." Recognition must be free, non-transferable, never for sale, and not a gateway to anything of value.

The sportsbook doesn't ship a leaderboard, so you build one from your players' bet records: the API returns each player's rounds, open rounds and balance, and paid plans can also export bets to CSV from the console. That gives you room to choose what you rank:

• Balance at season end. Simple, but rewards whoever bet biggest on one lucky accumulator.
• Net tokens over the season. Balance minus everything credited from refills and activity. Fairer, since it measures betting rather than attendance.
• Settled bets won, with a minimum number of bets. Rewards consistency.

Then make the recognition visible: a title next to the nickname on your site, a Discord role, a chat color, a mention by nickname at the end of a stream. Keep shout-outs to the nickname; don't promote the winner's own channel or links. Our guide for streamers has more ideas for on-stream recognition.

Managed vs seamless: where the balance lives

Everything above assumes the managed balance, where we keep the record and you credit and debit through the API. It's on every plan and needs no wallet code on your side.

The alternative is the seamless wallet (the Operator-Held Token Balance), where your system keeps each balance and we call your endpoint to debit a stake, credit a return or roll back a bet. It suits operators who already have an accounts system and want one balance shown everywhere on their site. It's a Custom add-on ($49 a month, $39 billed yearly, at the time of writing, September 2026; see pricing) or included in Full. The wallet URL and signing secret are configured on our side, so switching to seamless starts with a note through our contact page.

Seamless changes where the number is stored, not the rules. The balance you connect must still be a separate free token balance, never money, a redeemable points scheme or a purchasable currency. Seamless wallet integration for a sportsbook covers the debit, credit and rollback calls.

Virtual tokens for your community: a worked example

A token economy that works for most communities:

1. Stake limits: minimum 10, maximum 100 pre-match and live, a maximum return that fits.
2. Starting balance: 2,000 tokens, credited on first sign-in with a one-time key.
3. Refill: back up to 500 once a day if below it, on "Get more tokens".
4. Activity: a small, flat amount for watch time or chat, the same for everyone.
5. Season: monthly, reset after open bets settle, standings archived.
6. Recognition: a title and a role for the top three by net tokens.

For the bigger picture, read what a play-for-fun sportsbook is, and before going live work through the launch checklist for a play-for-fun sportsbook. You can start free (opens in a new tab): the managed balance is included on every plan, and nobody has to approve your sportsbook.

Frequently asked questions