A modular core that fails closed.
GameBridge is one hardened core with domain packages and one AI worker, not a mesh of services. It refuses to start without its secrets, verifies every payment callback before money moves, and shuts down cleanly so a deploy never leaves a half-finished transaction behind.
- 22+
- vendors wired in behind hardened callbacks
- 90+
- operator screens behind one permission model
- 2FA
- TOTP with backup codes on every admin account
- Fail-closed
- boot, webhooks and every money path
- 20M+
- simulated rounds per GameBridge Studios certificate
Few moving parts, each one hardened.
The stack is deliberately short: one API process owns the domain, one worker owns AI generation, PostgreSQL owns the truth. Everything that can fail closed does.
Runtime
- A Go API with domain packages, plus a separate AI worker for GameBridge Studios generation and the AI media loop
- React and TypeScript on the front end; Capacitor shells for iOS and Android
- PostgreSQL as the system of record, Redis alongside it, S3 and CDN for assets
- Cloudflare WAF, DDoS protection, CDN and geo at the edge; managed AWS services underneath
- Realtime channels for players, brands and admins, with guaranteed delivery for asynchronous work
Fails closed
- Missing secrets stop the process from booting; unsigned payment callbacks are rejected
- Health and readiness checks confirm the database and cache before traffic arrives
- Singleton jobs run exactly once across the fleet through leader election
- Bounded shutdown drains in-flight work instead of hanging a deploy
- Panic recovery in every background job, so one bad task cannot take the process down
- Idempotency keys and deterministic lock ordering on every money path
Application security
- RBAC with page keys per screen and action keys for every money-moving operation, enforced in the sidebar, the route guard and the server
- Admin 2FA with TOTP, backup codes and lockout; an Activity Log for every admin action
- Encryption in transit and at rest; CORS hardening, sanitized CMS output and rejected SVG uploads
- Secret scanning as a release gate, so a committed secret blocks the release
- Payment webhooks verified by signature, amount and brand; KYC callbacks hardened; sportsbook callbacks behind an IP allow-list
Operations
- Structured logs and CloudWatch; in-admin Engine Diagnostics with jobs, run history, heartbeats and a dead-letter queue
- Deploy runbook with pre-open money audits before a brand takes traffic again
- 38 operator guides in the built-in Documentation Center, with Ctrl+K search and a What's New feed
- JSON import and export across bonuses, campaigns, packages, banners, segments and games; CSV and XLSX for reports
Fairness you can verify, paperwork a lab can read.
Originals use commit-reveal HMAC-SHA256 seed pairs with a nonce for instant, stateful and slot games, and pre-committed hash chains for crash and roulette. Rotating the player seed reveals the server seed for the in-browser verifier. Around that sits an RNG dossier and submission handbook prepared for GLI-11, GLI-19, BMM and iTech Labs.
- GameBridge Studios mints a certification package per math version: PAR sheet with RTP standard error and confidence interval, hit frequency, volatility and max-win reachability
- 20M+ round Monte Carlo validation with hard publish gates before a game goes live
- Definition JSON and a machine certificate bound to the definition hash and engine version, so any lab can reproduce the result
- RNG test streams for Dieharder and NIST STS on request
- 1 · Commit
Server seed generated from the OS CSPRNG; only its SHA-256 hash is shown before play.
sha256: 9f3a…c41e - 2 · Client seed
Player sets or rotates a client seed at any time; nonce increments per bet.
seed: nova-maya-7 · nonce 412 - 3 · Derive
HMAC-SHA256(server, client:nonce) → CTR stream → rejection-sampled integers, no modulo bias.
HMAC → 0.7421 → 74.21 - 4 · Reveal
On rotation the server seed is revealed; anyone recomputes every historical outcome.
reveal: 5d1c…e903 ✓
Commit-reveal seeds and hash chains, verifiable in the browser. No certificate is claimed until a lab issues one.
Gate, migrate, audit, open.
- Step 1Gate
Automated tests and secret scanning gate every release. A failing check is a failed release, not a warning.
- Step 2Migrate
Database changes ship in a planned window, following the deploy runbook, once for the whole network.
- Step 3Audit
Pre-open money audits run before traffic opens. Every check must come back clean; anything it finds is corrected first.
- Step 4Open
The process refuses to start without its secrets, readiness checks confirm the database and cache, and the brand's domain takes traffic again.
Technology, security and operations, one runbook.
A stack a small team can actually operate.
- Modular Go core plus one AI worker, not microservices
- Managed PostgreSQL, Redis, object storage and CDN
- One codebase for every brand: a release ships once for the whole network
- Realtime channels with guaranteed delivery for asynchronous work
Controls in the code path, not in a policy document.
- Fail-closed boot and signed webhooks
- RBAC enforced server-side, admin 2FA, Activity Log
- Encryption in transit and at rest; WAF and DDoS protection at the edge
- Secret scanning as a release gate
Deploys that open only when the money ties out.
- Deploy runbook with pre-open money audits
- Health and readiness probes, CloudWatch, structured logs
- Engine Diagnostics with heartbeats and a dead-letter queue
- Bounded shutdown and singleton jobs that run exactly once
What technical due diligence asks.
Is it microservices?
Where does it run?
How do releases reach us?
How is the RNG certified?
How do we verify the security claims?
Where the hardening shows up.
Payments and ledger
Double-entry, cent-exact, idempotent, with self-healing purchases and fail-closed webhooks.
Más informaciónIntegrations
22+ vendors wired into the core, with hardened callbacks and per-brand configuration.
Más informaciónOperator console
90+ screens, RBAC in sidebar, route guard and server, and an Activity Log for every action.
Más información