Live updates and recovery
How market books and game rooms stay current without confusing a display with a receipt.
Market updates and game-room messages use different paths. Both help the screen stay current. Neither turns an unconfirmed action into a confirmed fill.
Explore each part and its connections. Expand to use more of your screen.
Follow an arrow to explore a connected part.
Discovery + indexed history
What this part does
The SDK queries the indexer to find markets and indexed history. An indexed status can lag, so writes use fresh RPC checks where required.
Outgoing connections
- From DreamDEX indexerquery resultsRead or display
The SDK queries the indexer to find markets and indexed history. An indexed status can lag, so writes use fresh RPC checks where required.
Read the map as text
- DreamDEX indexer Shared reader: query results.
- Somnia RPC + WS Shared reader: chain facts.
- Somnia RPC + WS Book coordinator: watched books.
- Live price feed Markets + Reels + tools: feed readings.
- Shared reader Markets + Reels + tools: facts + history.
- Book coordinator Markets + Reels + tools: shared book.
- Game-room WebSocket Duel screen: advisory messages.
- Arena event projector Game-room WebSocket: chain events.
- Game-room WebSocket Duel screen: confirmed updates.
Market books
The shared market reader connects to Somnia Markets SDK, the DreamDEX indexer, the configured price feed and chain WebSocket. One coordinator holds a watch per market and shares a normalized book with every visible component that needs it.
It distinguishes a book still loading, a live book and a stale reading. An empty book is not used as a substitute for a read that has not arrived.
The coordinator keys by market id. A pool can be reused for another Window; a stale page must not accidentally display its successor's liquidity. Consumers share depth 10 and render the portion they need.
Endpoint rotation exists as a capability, but automatic runtime rotation is disabled in the current source. A second configured endpoint is not evidence of automatic failover.
Game rooms
The long-running ops service hosts the WebSocket room. A browser first obtains a signed room token from the app. Web and ops share the same ROOM_TOKEN_SECRET, so the room can check the token without asking the app again.
The socket performs a protocol-version handshake, checks the match seat and, once registered, the browser key named by the arena. Before on-chain entry, the wallet association is the browser key's claim. Do not treat the room token alone as proof that the wallet owner signed in.
Chat, reactions, presence and “pick pending” are room messages. A pending pick does not contain the chosen side. Confirmed picks and results come from the arena's event projection and chain snapshots.
Reconnecting
A reconnect asks the contract for current match state rather than replaying the browser's old assumptions. The database projection helps locate active matches; the server also tracks committed matches waiting for creation.
The ordinary queue is temporary. If the process restarts while you are only queued, search again. A committed deck has encrypted recovery material in a local journal before it is published.
A useful separation
| You see | It tells you |
|---|---|
| New price or live book | A recent market reading arrived. |
| Opponent presence | Their room connection is present. |
| Pick pending | They are attempting an action. |
| Fill receipt | The chain recorded the trade. |
| Settled card or claim | Contract settlement or payout was recorded. |
The app directly integrates the Markets SDK and these transports. No separate direct Reactor or Somnia Data Streams SDK call is present in the audited application source.
Source notes
This guide follows the application code reviewed on 2026-09-07. Links point to that reviewed commit and require repository access. GitHub may show 404 if you are signed out or do not have access.