Skip to main content

Round tracking

When a published game calls a deployed Maths Component, the platform can record the call as a round: a row in Bet History, a session roll-up, and a balance movement for the player.

This is not automatic — it depends on the component's bet and win mapping.

When a round is recorded​

All of these must hold. If any one fails, nothing is written — no round, no balance change:

  1. The deployed component has a bet/win mapping stored — see the bet and win ports.
  2. The bet is greater than zero. (A call with no stake — a paytable lookup, say — is not a round.)
  3. The player's balance is greater than the bet. An exact all-in is refused too.
  4. The response actually contains the win key. This stops a leftover bet value from booking a phantom round on a call that never computed a win.
The published game callsa deployed maths componentbet / win mapping stored?yesbet above zero?yesbalance above the bet?yesresponse contains the win key?yesRound recordedBet History row · session roll-upthe player's balance movesnonononoNothing is writtenno round, no balancechange, no roll-up —the game still plays
note

The mapping is stored at deploy time, on the deployed function. Components deployed before their mapping was in place stay untracked until you deploy again and republish the game.

The win is capped​

A staked round pays at most bet × the game's max win multiplier (the Max Win Multiplier on the game, 5000× by default), whatever the component script returned. /round has always done this; since 9 September the component endpoint does too.

When a cap applies:

  • the round is recorded and the player is paid the capped amount;
  • the response's win key carries the capped amount, so what the screen shows is what was paid;
  • the round audit keeps the script's own figure, so a replay still reproduces the maths.

A call with no stake, no win key or a game without a multiplier is never capped.

Jackpot pools ride the round​

If the game has active jackpot pools, every staked round contributes to them and any pot won is added to the round's win — the platform's own draw for random and must_hit_by pools, or a claim from your maths for scatter pools (an output wired to a Component Outputs port named jackpotClaims; see Slot Features). Pools need an identified player: a guest session is not eligible.

Amounts are minor units​

A bet of 100 means 1.00 — the same convention as the platform's balances. Getting this wrong records wrong money: a win port accidentally aimed at an RNG value will be booked as a payout.

The money genuinely moves, in the pot the game's mode selects: demo games move play money, live games move real money.

Who the player is​

Each call carries a per-browser client id, a per-tab session id, and — if your graph provided one — a player id.

A player id exists only if you used the player nodes (Create New Player, Get Player). Most games don't, and get the guest path:

  • The platform creates one player per browser, shown as Anonymous.
  • Guests start with a play-money float and are topped up when a bet would exceed it — demo play is never turned away for being broke. Top-ups appear on the platform as adjustments.
  • Real players are never given free money: an overbet by a real player is rejected.

Guest rounds are marked as demo play, so reporting can separate them from real ones.

Where it shows up​

Platform pageContents
Bet HistoryOne row per round — bet, win, Win/Lose status.
SessionsRounds rolled up per player, game and tab.
TransactionsDeposits and withdrawals only. Rounds do not appear here.

Rounds also feed the platform's RTP monitoring, financial reporting and compliance reports.

Tracking never breaks your game​

Recording runs after your maths and its failures are swallowed: it cannot reject a round or change the response your frontend gets. If tracking is misconfigured, the game still plays — it just isn't recorded.