ARCHITECTURE
Dexter is one product to the trader — connect a wallet, buy a $49–$299 pack, trade, get paid — and five layers underneath. Each layer owns exactly one job and holds exactly the authority that job requires. A degraded oracle cannot pause a withdrawal. A stuck operating wallet cannot freeze collateral. The challenge engine cannot rewrite a matching-engine fill. Settlement runs on Base, custody sits in dedicated contracts, and every payout traces back to a published state root anyone can verify in an explorer.
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.
Read the table as a permission map. Each layer's first column is what it is allowed to do; the third column is what it cannot do, by construction. Nothing in the table moves user funds without a corresponding contract call on Base.
| Layer | Primary job | What it cannot do |
|---|---|---|
| Product surface | Render markets, charts, order entry, positions, assets, and account views | No matching, no custody, no settlement |
| Gateway and read model | Normalize persisted runtime output into one stable API; gate signed ingress with agent auth, IOC, and order-commit policy | No fill decisions, no balance authority |
| Runtime engine | Single-writer flow: validate signed orders, apply risk, price, fill, advance funding, prepare publication | No direct custody, no unilateral withdrawals, no parameter changes |
| Publication | Commit state roots with sequence, oracle, batch, and config bindings the vault settles against | No matching loop, no balance writes |
| Contracts on Base | Hold collateral, queue withdrawals, preserve root history, enforce multi-sig on treasury actions | No live order matching, no off-chain authority |
#One venue, separate operating layers
A trader sees one venue. The implementation splits that venue across five layers because forcing fast execution, readable product state, and custody-critical permissions into one component is how derivatives venues lose user funds. The product surface owns clarity. The gateway owns normalization and the admission policy on signed flow. The runtime owns live exchange state under a single-writer model. Publication owns the bindings between off-chain state and on-chain settlement. The contracts on Base own custody and the multi-sig gates on treasury movement.
Third-party surfaces — dashboards, copy-trading rails, mobile clients, institutional API consumers — read from the same gateway as the in-house app. They do not constitute a new protocol layer; they consume the same persisted state. That is the structural reason a copy-trader bot, a retail mobile front end, and a quant desk see consistent fills.
Dexter ships in liquidityless vAMM mode. The live venue does not depend on resting maker inventory; execution pressure, skew, spread, and inventory posture are handled inside the runtime against the vAMM curve. Custody and withdrawal rights remain bound to the contracts regardless of what posture the runtime takes. A bad inventory call cannot cost a trader their margin.
product surface
-> gateway and read model
-> off-chain runtime
-> published commitments
-> vault, treasury, and settlement contracts on Base#Where the trust boundary actually sits
Dexter does not claim every component is on-chain. It claims something narrower and more useful: execution can be fast off-chain so long as custody, settlement references, and protocol-owned value live on-chain with explicit rules. User collateral, withdrawal requests, nonce history, fee balances, the insurance reserve, and income-side accounting all sit in contract-governed storage on Base because those are the places where ownership has to stay unambiguous.
The runtime advances state and publishes the settlement context the vault reads against. It does not redefine custody after the fact, and it does not authorize a withdrawal the contracts would not honor on their own. Treasury moves above $10,000 require a 2-of-3 multi-sig; insurance and governance moves require a 3-of-5 with an external signer. The runtime cannot bypass either gate. That is what turns the off-chain / on-chain split into a real architectural boundary instead of marketing language layered over a black-box backend.