GeeWinSecurity
Security & Rules
Platform

How the platform keeps games fair and secure. What developers can and cannot do.

Game Sandbox

Every game runs inside a sandboxed iframe with restricted permissions:

RestrictionDetails
No direct DB accessGames communicate only via postMessage
No server-side codeGames are static HTML/JS/CSS files
No external requestsGames cannot make fetch/XHR calls to external servers
No cookie accessiframe is sandboxed with no same-origin privileges
No balance manipulationAll payouts are calculated server-side by the primitives
Origin-verified messagesOnly messages from the game iframe are accepted — other tabs/frames are ignored
Platform-controlled stakesBet amounts and currency are set by the platform UI, not the game iframe
Rate-limited actionsBet and action messages are rate-limited (max 1 per 25ms) to prevent spam
Server-side PVP resolutionWhen a resolver is configured, outcomes are always determined server-side

RNG & Fairness

All randomness is generated server-side using cryptographic functions. Game developers have zero control over outcomes:

Server Seeds

Generated using Node.js crypto.randomBytes. Committed before the game starts via SHA-256 hash.

Provably Fair

Every game provides a commitment hash before play and reveals the seed after. Players can verify at /provably-fair.

What Developers Control

Can Do ✓Cannot Do ✗
Define game rules (outcomes, weights, states)Change RNG or seed generation
Set visual presentation (HTML/CSS/JS)Access player balances directly
Choose which primitive to useOverride payout calculations
Set outcome multipliers (within RTP limits)Make external network requests
Access game config via window.GAME_CONFIGModify platform code or APIs

RTP & House Edge

The platform enforces a 97% Return to Player (3% house edge):

1// For one-shot games:
2// You provide: multipliers (e.g. [0, 0.5, 1, 2, 5, 10])
3// Platform calculates: probabilities for each multiplier
4// so that Σ (probability × multiplier) = 0.97 (97% RTP)
5

6// For state-machine games:
7// You define: transitions with explicit probabilities
8// Platform validates: RTP via value iteration at upload time
9// Must be ≤ 97% RTP
⚠
Your multiplier values stay exactly as you set them — the platform only adjusts the probabilities of each outcome to achieve 97% RTP. If your multipliers can't produce a valid 97% distribution, the upload will be rejected.

Revenue Split

Developers earn 50% of their game's house profit. House profit = total wagered − total paid out. You earn half of what the house makes from your game.

Total WageredHouse Profit (3% edge)Your Earnings (50%)
$10,000$300$150
$100,000$3,000$1,500
$1,000,000$30,000$15,000

Earnings accumulate as players bet on your game and can be claimed once per week via the Analytics tab. New games have a 7-day waiting period before earnings become claimable. Payouts are credited to your USDT balance.

Upload Rules

Single HTML fileYour entire game must be in one .html file (inline CSS/JS is fine)
GAME_CONFIG requiredMust define window.GAME_CONFIG with a valid primitive and config
gameReady requiredMust send parent.postMessage({ type: 'gameReady' }, '*') on load
No external scriptsAll code must be inline — no CDN links or external imports
Thumbnail optionalUpload a .png/.jpg thumbnail for the game card (recommended)

Testing & Uploading

Use preview mode to test before uploading. Navigate to Dashboard → My Games → Create New Game to get started.

1// In preview mode:
2// - window.TEST_MODE = true
3// - window.PREVIEW_MODE = true
4// - Uses test balance (not real funds)
5// - Same API behavior as production
6// - Test in multiple tabs for PVP games
7

8// Upload flow:
9// 1. Go to Dashboard → My Games → Create New Game
10// 2. Select your HTML file
11// 3. Platform detects GAME_CONFIG automatically
12// 4. Click "Preview" to test in sandbox
13// 5. Click "Upload" when ready to publish
✓
Always test your game thoroughly in preview mode before uploading. Once published, players can bet real money on your game.
Testing GuideExamples