← work
[game-engine]2026-01-01

Xplode

Real-time multiplayer PvP where every move is on-chain. Sub-50ms commit latency via MagicBlock's 1ms ephemeral rollups, Solana settlement, zero gas for players. Live at playxplode.xyz — featured by MagicBlock.

RustSolanaMagicBlockWebSocketRedisPostgreSQLTypeScript

Overview

Xplode is a real-time multiplayer minesweeper where players bet SOL or USDC and every move is recorded on-chain. The challenge: blockchain games are usually unplayable because of latency. A 400ms block time feels broken in a real-time game.

The solution is MagicBlock's ephemeral rollups — 1ms block times, sub-50ms end-to-end latency — while settling final state on Solana. You get full blockchain transparency and provable fairness without sacrificing the feel of a native game.

Featured by MagicBlock: Watch full gameplay →

Architecture

Web Client (WebSocket)
       │
       ▼
Game Server (Rust)
  ├── Game Engine      — grid state, move validation, win detection
  ├── Redis            — live session state, leaderboards
  ├── DB Interface     — PostgreSQL for persistent game history
  └── Xplode Moves Client ──► MagicBlock Ephemeral Rollup
                                     │
                                     ▼
                              Solana (settlement)

The game server handles all real-time state via Redis. Move instructions are sent to the MagicBlock ephemeral rollup for on-chain recording — this is the critical path that had to stay under 50ms.

A separate Wallet Server handles SOL/USDC escrow, payouts, and cross-chain adapters (Solana + EVM).

What made this hard

Latency budget. The full round trip — client move → game server → on-chain record → confirmation → client update — had to stay under 50ms. Most of that budget belongs to the ephemeral rollup. The game server's own path had to be under 5ms, which meant no blocking DB calls on the hot path and careful Redis pipeline batching.

Provably fair randomness. Mine placement uses a commit-reveal scheme: the server commits to a seed at game start, players make moves, and the seed is revealed at game end. This prevents the server from knowing mine positions after the first move, but requires the client to verify the commitment on-chain.

Rematch flow. Coordinating a rematch between two players — both must accept, state must reset, a new escrow must be funded — without either player being able to grief the other required careful state machine design with timeouts and refund paths.

Key features

  • Sub-50ms on-chain move recording
  • SOL and USDC betting with zero gas for players
  • Leaderboards and PnL tracking
  • NFT minting for in-game expressions
  • Prometheus + Grafana observability