> ## Documentation Index > Fetch the complete documentation index at: https://docs.kinematic.run/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > These are the customer docs for kinematic, a name written in lowercase except at the start of a sentence. Kinematic provides provably fair casino games, served to a casino's site by a game server: a Cloudflare Worker that the kinematic dashboard deploys into the casino's own Cloudflare account. > Never put SESSION_SECRET or WALLET_SECRET in code, prompts, logs, commits or chat. Read them from environment variables and ask the person you work with to set them. The dashboard's Integration page shows each secret once. > Values such as lucky-star, luckystar.example, og-rgs-lucky-star.luckystar.workers.dev, games.luckystar.example and player_48213 are examples. Use the casino's own casino ID, game server origin, element tag, session issuer and currencies: the Instructions for your coding agent on the dashboard's Integration page hold them, or ask the person you work with. > To debug, start at https://docs.kinematic.run/troubleshooting and https://docs.kinematic.run/reference/errors. The wallet contract is at https://docs.kinematic.run/api/wallet.openapi.yaml. > Sandbox bets are recorded on Solana devnet. Live game servers record nothing on Solana until the audited mainnet program is deployed. # Test your integration > What to check in sandbox, how to test your wallet against the contract, and what Check my wallet verifies before you go live. Test in two stages: the page and your sessions in sandbox, where the game server holds test balances, then your wallet before you go live. ## In sandbox Sign in to your site as a test player and work through this list on the page that shows the games. **1. Every game you offer** Place a bet in each game. The result appears, the balance moves, and the game stays ready for the next bet. Multi-step games (Mines, Pump, HiLo, Blackjack and Crash) play a full round, including a cash out. **2. The proofs** Open **Provably fair** in a game's toolbar. The **Proofs** tab checks each bet in your browser and lists every check as passed. Once a bet is recorded, its row reads **Recorded on Solana** and links to the devnet transaction. The **Odds** tab shows each game's return to player at the settings on screen. **3. Reloads, tabs and devices** Reload the page while a bet is in flight: the bet still settles. Open a second tab: both show the same balance. Sign in as the same player in a private window: the player keeps playing. A private window works only when your session tokens carry `cnf`; without it the game server answers `player_key_changed`. **4. Session renewal** Leave a game open for longer than your tokens live. The element renews its session before each token expires, and the next bet goes through. **5. Limits** Type a stake below your minimum for the currency, then one above your maximum, and press **BET**. The game server refuses both with `bet_limit`, and the balance does not change. The ½ and 2× keys keep the stake within your limits. **6. Stopping new bets** On the **Game server** page, select **Stop new bets** and confirm. The next bet is refused with `bets_disabled`, while a round already in play finishes. Select **Accept new bets again** and confirm with **Accept new bets**. **7. The dashboard** Your bets show on the [Live](https://docs.kinematic.run/dashboard/live-monitor.md) page as they settle. On **Home**, the launch checklist marks **Place your first bet** done, and on **Integration** the **Put the games on your page** and **Sign session tokens** steps show **Done**. ## Your wallet Test your wallet's endpoints with your own tests before you point a live game server at them. Each case below is a call your wallet must answer exactly as stated. The [reference wallet](https://docs.kinematic.run/integrate/wallet.md#a-reference-wallet) answers every one of them, so you can compare. | Case | Expected answer | | - | - | | A correctly signed `/balance` | `200`, `status: "applied"`, the balance and the current revision. | | A debit the player can cover | `200`, `status: "applied"`, the balance reduced by `amount`. | | The same debit again, same ID and body | `200`, the same receipt as the first time, and no second debit. | | The same ID with another body | Any status other than 200. Nothing changes. | | A wrong signature | Any status other than 200, such as `401`. Nothing changes. | | A timestamp more than 60 seconds old | Any status other than 200. Nothing changes. | | A debit larger than the balance | `200`, `status: "declined"`, and no part of the amount debited. | | A credit | `200`, `status: "applied"`, the balance increased by the gross `amount`. | | The same credit again | `200`, the same receipt, and no second credit. | | Any call | No redirect. | Sign test calls exactly as the game server does: HMAC-SHA256 of `timestamp + "." + body` with your `WALLET_SECRET`, as lowercase hex. ## Check my wallet **Check my wallet** sits in the **Connect your wallet** step on **Integration**. It opens once your casino is in live mode with a wallet URL. Until then the step says: * In sandbox: `The check opens in live mode, with your wallet URL. You set both in Settings.` * In live mode without a wallet URL: `Add your wallet URL in Settings to check your wallet here.` Only owners and admins can run it; other members see `Only the casino's owners and admins can run the check.` 1. Enter a **Test player ID**: a test account in your wallet, named as your session tokens name it, such as `test-player-1`. 2. Choose a **Currency** from your casino's currencies. 3. Select **Check my wallet**. The check sends `POST /balance` for that player and currency, signed with your `WALLET_SECRET` exactly as your game server signs it, with an `id` that starts with `balance_` and an `amount` of `"0"`. It then sends the same call with a wrong signature. A balance call changes nothing, so the check is safe to run against your production wallet. It waits 8 seconds for each answer and follows no redirect. It runs seven checks, in this order: | Check | Passes when | | - | - | | URL | Your wallet URL is an https URL without credentials or a fragment. | | Answer | Your wallet answers HTTP 200 to the correctly signed balance call, within 8 seconds and without a redirect. | | Receipt | The answer is a JSON object of at most 16 KiB. | | Echo | The receipt repeats the request's `id` and `currency`. | | Status | The receipt's `status` is `"applied"`. | | Amounts | `balance` and `revision` are strings of digits in minor units, such as `"95000"` and `"42"`, without decimals or signs. | | Forged | Your wallet refuses the call with the wrong signature: it answers with a status other than 200. | A failed URL check stops the check there. A failed Answer skips Receipt, Echo, Status and Amounts, and a failed Receipt skips Echo, Status and Amounts; a skipped check reads `Not run, because an earlier check failed.` Forged runs whenever the URL check passed. After an Answer of HTTP 401 or 403, check that your wallet verifies with the `WALLET_SECRET` from **Integration** and that its clock is right; after HTTP 404, check the wallet URL, to which your game server adds `balance`, `debit` and `credit`. The result starts with a summary line, such as `Your wallet passed all 7 checks for test-player-1 in USD.` or `Your wallet passed 5 of 7 checks for test-player-1 in USD.`, followed by each check's result. On later visits the step shows your last check, such as `Your last check passed all 7 checks, on