ARCHITECTURE
Dexter is a hybrid perpetual venue. The product feels like one exchange, but the system is split into layers with different authority.
The interface feels singular, but execution, publication, and custody remain clearly separated.
One visible venue.
Policy before execution.
Pricing, matching, risk, funding, publication.
State ships with context.
Collateral stays bounded.
| Layer | Primary job | What remains outside it |
|---|---|---|
| Product surface | Markets, charts, order entry, positions, assets, and account views | No matching, no custody, no settlement finality |
| Gateway and read model | Turn persisted exchange state into stable product and API responses | No fill decisions, no balance authority |
| Exchange runtime | Validate signed flow, apply risk, price trades, advance the ledger, and prepare commitments | No direct custody and no unilateral withdrawals |
| Contract layer | Hold collateral, store withdrawal requests, preserve root history, and control treasury-sensitive actions | No live matching loop |
#One venue, separate operating layers
A user experiences Dexter as one venue.
Underneath that surface, however, the venue is deliberately layered so fast execution, readable product state, and custody-critical permissions are not forced into one component.
The product layer is responsible for clarity.
The gateway is responsible for normalization and access boundaries.
The runtime is responsible for live exchange state.
The contracts are responsible for custody, settlement references, and governed protocol balances.
Additional product surfaces can sit on top of the same records.
They do not create a new protocol layer.
They remain downstream consumers of the same gateway and read model.
In production, Dexter runs in liquidityless vAMM mode.
That means the live venue does not depend on passive maker inventory resting in the book.
Execution pressure, skew, spread, and inventory posture are handled by the runtime, while custody and withdrawal rights remain contract-bound.
product surface
-> gateway and read model
-> off-chain runtime
-> published commitments
-> vault, treasury, and settlement contracts#Where the trust boundary actually sits
Dexter does not claim that every component is on-chain.
It claims something narrower and more important: execution coordination can be fast off-chain as long as custody, settlement references, and protocol-owned value stay explicit.
User collateral, withdrawal requests, nonce history, fee balances, insurance balances, and income-side accounting all remain in contract-governed storage because those are the places where ownership must stay unambiguous.
The runtime can advance state and publish settlement context.
It does not get to redefine custody after the fact.
That is what turns the hybrid split into a real architectural boundary instead of a marketing label.