Home/Developers/Security model

Engineered to be attacked and stay fair

A money-moving platform is a target. VerseGame assumes hostile traffic everywhere and is built so the worst case stays boring.

Every byte is signed

API requests and wallet callbacks carry HMAC-SHA256 signatures computed over the raw body. A request that is unsigned, mis-signed or altered in transit is rejected before any handler runs. Secrets are stored hashed and encrypted at rest, shown exactly once at creation.

Sessions that can't wander

Launch tokens are short-lived and bound to one player, one game and one tenant. Before a game starts, the client verifies its URL parameters against the canonical server-side session — so even cosmetic URL tampering (like changing the displayed currency) is detected and corrected. Money was never at risk from the URL: settlement always derives from the database session, not from anything the browser sends.

Tenant isolation at the database layer

Every operator's players, bets, rounds, settings and logs are scoped by tenant in every query, not filtered in the UI. One operator can never see, or affect, another's data — the isolation is structural.

Money that can't drift

Amounts are integer minor units with idempotent transaction IDs. Double processing, floating-point drift and replayed callbacks are ruled out by construction, not by policy.

Isolated fault domains

The live round engine runs independently of the HTTP API: a crashing route, a slow query or a misbehaving integration cannot stall a round or disconnect players mid-game.

The demo showcase is inert

The public demo on this site runs against a dedicated internal tenant with play money only. It shares no data with any real operator and cannot touch real funds.

Ready to talk?

The VerseGame team answers every partnership inquiry directly.

Contact us