PRODUCT SURFACE, GATEWAY, AND READ MODEL

It sits between the product surface and the runtime and serves stable responses from persisted exchange outputs rather than private runtime memory.

In production it is also the narrow ingress boundary for signed trading flow. The same service that exposes market and account state is where signer policy is enabled, IOC discipline is enforced, and required order commitments are submitted before placement.

Surface exposed by the gateway	What it is built from
Market summaries and order books	Runtime snapshots, order-book records, and price state
Account, fills, and funding history	Persisted account summaries, fill logs, and funding records
Publication and liveness views	Root history, freshness checks, and commitment metadata
Venue posture signals	Health snapshots, market-state outputs, and publication liveness
Signed trading ingress	Agent authorization, timing checks, IOC enforcement, and order-commit submission

#What the gateway actually owns

The gateway owns presentation, normalization, and access boundaries.

It does not own matching logic, mark construction, custody, or settlement finality.

Its job is to expose one stable interface over state that has already been written somewhere durable and to keep the live trading front door narrow enough that admission policy stays explicit.

That distinction matters because a product that reads live runtime memory directly becomes hard to cache, hard to inspect, and hard to reason about under degraded conditions.

Dexter avoids that by making the gateway a controlled translation layer rather than a hidden decision maker.

Public market reads, authenticated account views, and restricted service routes do not share one permission model.

That makes the gateway part of the safety boundary, not just part of the UI.

Other product screens may consume the same records, but they remain downstream consumers of one read boundary rather than separate protocol layers.

#The role of the persisted read model

The runtime continuously writes snapshots, fills, funding records, market summaries, account summaries, and health signals into storage that the gateway can expose.

The gateway therefore reads a persisted record of venue state rather than an in-memory process image.

TEXT

 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
   -> app and API consumers read one stable venue surface

A hybrid venue becomes hard to review when each screen is backed by a different invisible source.

Dexter uses the read model to avoid that.

The gateway explains the venue, but it does not decide the venue.

Back to top