MasayumeDocs
Open app
How it works

Where the records live

Chain ownership, server history and browser recovery material.

Reviewed 2026-09-07

Masayume uses several kinds of storage because a wallet balance, a chat message and an agent's explanation answer different questions.

Interactive system map

Where each kind of information lives

The contract balance, your local keys and a server history row are different records.

Masayume

Explore each part and its connections. Expand to use more of your screen.

Follow an arrow to explore a connected part.

Selected part · 1 of 9Your browser

Keys · intents · claim tickets

What this part does

Browser storage holds convenience-key state, transaction intent recovery and local private claim material used by the relevant features. A wallet remains a separate signer.

Control & permission Keep recovery material private. Clearing browser storage can remove convenience and local records.

Outgoing connections

  • From Your browsersigned actionsAction or record
  • From Your browserfeature requestAction or record
Inside the boxYour browser

Browser storage holds convenience-key state, transaction intent recovery and local private claim material used by the relevant features. A wallet remains a separate signer.

Control & permission Keep recovery material private. Clearing browser storage can remove convenience and local records.

Public markets remain readable without Postgres. Social features, X relay, durable agent memory, Lucky draws, scoreboards, match history and the settler worklist do depend on it.
Read the map as text
  1. Your browser Somnia contracts: signed actions.
  2. Somnia contracts Market indexer: venue events.
  3. Your browser App server routes: feature request.
  4. App server routes Postgres: server records.
  5. Operator processes Postgres: agent + game history.
  6. Operator processes Encrypted deck journal: sealed deck.
  7. Somnia contracts History and recovery UI: live contract facts.
  8. Postgres History and recovery UI: stored history.
  9. Private desk service Somnia contracts: resume from state.
  10. App server routes Private desk service: private request.

Where each kind of information lives

Masayume

Select a part to see what it does and who controls it. The map adapts to the space available.

Follow an arrow to explore a connected part.

Selected part · 1 of 9Your browser

Keys · intents · claim tickets

What this part does

Browser storage holds convenience-key state, transaction intent recovery and local private claim material used by the relevant features. A wallet remains a separate signer.

Control & permission Keep recovery material private. Clearing browser storage can remove convenience and local records.

Outgoing connections

  • From Your browsersigned actionsAction or record
  • From Your browserfeature requestAction or record
Inside the boxYour browser

Browser storage holds convenience-key state, transaction intent recovery and local private claim material used by the relevant features. A wallet remains a separate signer.

Control & permission Keep recovery material private. Clearing browser storage can remove convenience and local records.

Public markets remain readable without Postgres. Social features, X relay, durable agent memory, Lucky draws, scoreboards, match history and the settler worklist do depend on it.

Read the map as text
  1. Your browser Somnia contracts: signed actions.
  2. Somnia contracts Market indexer: venue events.
  3. Your browser App server routes: feature request.
  4. App server routes Postgres: server records.
  5. Operator processes Postgres: agent + game history.
  6. Operator processes Encrypted deck journal: sealed deck.
  7. Somnia contracts History and recovery UI: live contract facts.
  8. Postgres History and recovery UI: stored history.
  9. Private desk service Somnia contracts: resume from state.
  10. App server routes Private desk service: private request.

The record for each feature

RecordMain location
Markets, fills, holdings and settlementDreamDEX contracts and their indexer
Trading Balance, grants and owned vault positionsEventVault
Range, Parlay, Boost and private slot stateTheir named Masayume contracts
Duel entry, deck commitment, picks, payouts and creditsGameArena
Strategy creator, runner, spec and subscription consentStrategyRegistry
Agent decision reservations, execution attempts, heartbeats and readable historyPostgres, joined with chain facts
X links, mention claims, execution journals, receipts, reply delivery, service checks and polling cursorPostgres
Comments, Takes and bettor recordsPostgres
Duel history, ratings, arcade scores and Lucky drawsPostgres
Encrypted committed-deck materialOperator file journal, plus optional Postgres copy
Private claim and browser signing convenienceBrowser-held recovery/session material

The database is optional for browsing

Public market reads can work without a database. That does not mean every feature works without one. X relay, social activity, durable agent memory, Lucky draws, scoreboards, duel history and the settler's worklist depend on stored records.

When a store is unavailable, “not connected here” is different from “you have no history.” Pages should preserve that distinction.

The implementation uses the postgres driver and SQL schema definitions. On first use, an idempotent schema creation runs under a transaction and advisory lock. There is no separate Drizzle migration command in the current workspace.

X execution and reply records

An X mention is claimed once in x_receipts before execution. When replies are enabled, its x_reply_delivery entry is created in that same database transaction. The final execution receipt is written later; posting the reply is a separate operation.

The receipt keeps the claimed sender id and handle, with the requested amount separate from optional booked cost, quantity and resolved Window details in details JSONB. Sender snapshots are preserved when later execution facts arrive. Older rows can lack booked fields. Their requested budget must not be presented as a measured fill cost.

The delivery record keeps the exact text, optional media id, posting state and acknowledged reply id. Delivery sent means X acknowledged a reply, not that a trade filled or a market was won. An ambiguous post is held for inspection rather than automatically posted again.

Acknowledged reply ids also identify the relay's own receipts during mention polling. Those receipts cannot become new commands. Startup suppresses unfinished recursive reply deliveries while preserving sent acknowledgements for audit; acquisition and pre-post checks repeat the same exclusion.

The X transaction journal persists its intent before broadcast and the hash when broadcast returns. Recovery validates the receipt or searches from the saved block using the expected executor nonce, then matches exact EventVault execution facts. An unresolved receipt is not resent, and missing evidence remains unknown. Older incomplete rows can still require investigation.

The runner separately records each strategy decision before a model call and each execution attempt before an order send. These reservations preserve once-per-Window behavior across restarts. Stale or missing risk data blocks new entries. Neither durable database history nor a recovery scan replaces the contract's authority over funds.

Private-looking is not encrypted

Market Rooms are access-controlled at the API. A wallet proves its address and eligibility before receiving a room token. The server can read comments; the messages are not end-to-end encrypted.

Strategy Persona and Playbook text are published openly. The Memory Market does not currently provide an encrypted store for purchasable private playbooks.

PrivateDesk avoids putting an owner beside each market slot on-chain, but the server knows both halves while processing it. See Private mode for the exact limit.

Recovery needs the right record

A chart screenshot is not a receipt. An agent's reason is not a trade confirmation. A database projection is not the authority to move somebody's funds. Keep transaction hashes and claim material when the app provides them, and inspect the matching contract when an action's result is unknown.

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.

On this page