GATEWAY AND READ MODEL
The gateway is the public boundary between every trading client and the runtime. Challenge orders during the $49–$299 evaluation window, funded fills under the 90 / 10 split, leaderboard reads, withdrawal requests — all of them pass through the same ingress and read from the same persisted state. A copy-trading bot, a retail mobile app, and an institutional API client see the same surface, which is why third parties can build dashboards on Dexter without asking for permission and why the rules cannot be quietly relaxed for one consumer.
The gateway serves stable responses from persisted runtime output, never from runtime in-memory process state. That is what lets it cache, version, fall back, and stay deterministic under load — every read goes through the same code path whether the runtime is busy, idle, or restarting. In production it is also the narrow ingress boundary for signed trading flow: agent authorization, timing checks, IOC enforcement, and order-commit submission all happen here before a single byte reaches the matching loop.
| Surface exposed by the gateway | Backing source |
|---|---|
| Market summaries and order books | Runtime snapshots, order-book records, mark and index state |
| Account, fills, funding history | Persisted account summaries, fill logs, funding settlement records |
| Publication and liveness | Root history, freshness windows, sequence and config commitment metadata |
| Venue posture signals | Health snapshots, market-state outputs, oracle source health |
| Signed trading ingress | POST /agent/authorize signer policy; createdAtTs / goodTilTs windows; IOC discipline; required order-commit submission |
#What the gateway actually owns
The gateway owns presentation, normalization, and the admission policy on signed ingress. It does not own matching, mark construction, custody, or settlement finality — those live in the runtime and the Base contracts. Its job is to expose one stable interface over already-persisted state and to keep the trading front door narrow enough that the rules for entry are explicit and inspectable.
The split between public market reads, authenticated account views, and restricted service routes is enforced as three different permission models, not one. A wallet that can read its own positions cannot read another wallet's positions; an unauthenticated consumer can read the order book but cannot read fill history; an internal service route cannot be invoked from the public ingress at all. The gateway is therefore part of the safety boundary, not just the UI layer.
Third-party surfaces — copy-trading rails, mobile clients, institutional API consumers — read the same records under the same permission model as the in-house app. They are downstream consumers of one boundary, not parallel protocol layers. There is no "partner" tier with quiet access to private endpoints.
#The role of the persisted read model
The runtime continuously writes snapshots, fills, funding records, market summaries, account summaries, and health signals into a persisted store. The gateway reads from that store, never from runtime process memory. Two consequences follow: every consumer sees the same state at the same sequence point, and a runtime restart never produces a stale or split-brain read.
signed user flow
-> POST /agent/authorize sets signer policy
-> gateway checks createdAtTs / goodTilTs / IOC / sequence policy
-> gateway submits required order commitment
-> runtime updates exchange state
-> snapshots, fills, funding, and health are persisted
-> gateway normalizes those records
-> every app and API consumer reads one stable surfaceHybrid venues become unreviewable when each screen is backed by a different invisible source. The read model is what prevents that on Dexter. The gateway explains the venue; it does not decide the venue. Anyone reproducing a trader's PnL, a leaderboard rank, or an insurance balance can do so from the same persisted records the gateway serves.