RUNTIME AND PUBLICATION
The runtime is the single-writer engine that owns live trading state — position, equity, funding accrual, fills, liquidation passes. Publication is the discipline that turns that live state into committed roots the Base contracts settle against. Together they are why a trader's history, a leaderboard rank, and a 90 / 10 payout amount cannot be quietly rewritten after the fact: every state transition lands in one ordered sequence, every root is bound to the sequence and to the config and oracle posture that produced it, and every withdrawal settles against a root that anyone with an explorer can verify.
The runtime validates signed flow from the gateway, applies risk and market-state rules, updates balances and positions, advances funding (peer-to-peer with a 1% admin slice above $1,000 per 8h window), and runs forced routines — liquidation, ADL, the 50/50 keeper-and-insurance residual split. Every state transition produces the references the contract layer later settles against. The table below is what ships with every commit; a root without these bindings is rejected by the vault.
| Published item | What it binds |
|---|---|
| State root | Anchors account state for settlement and withdrawal proofs on Base |
| Root id and timestamp | Places state inside an explicit publication history; both monotonic |
| Sequence commitment | Binds event ordering to the committed state — no reordered fills |
| Oracle-source hash | Binds the price-source posture used while state advanced |
| Order-batch commitment | Binds the admitted batch around that state — no inserted or removed orders |
| Config hash and version | Bind the active risk and venue rules — fee schedule, margin tier, market list |
#Single-writer exchange state
Dexter runs one write path. Funding updates, liquidation passes, imbalance routines, market-state changes, and publication all move through one ordered runtime flow — never through competing writers. In a derivatives venue, wrong sequencing is as expensive as wrong pricing: a funding tick applied out of order can falsify equity, a liquidation racing a fill can settle against the wrong mark. The single-writer model eliminates both classes of bug by making one runtime the sole author of the state transition sequence the rest of the system reads.
The same runtime that updates balances prepares the material that publication later anchors. That is why settlement context and trading state cannot disagree — they come from the same process, in the same order, behind the same commitment.
signed IOC order
-> admission and risk checks
-> pricing and fill decision
-> ledger, position, fee, and funding updates
-> snapshot and read-model write
-> precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment)
-> commitStateRootWithConfig(root, schemaVersion, configHash, configVersion)
-> vault accepts the root only while publication guards remain satisfied#Publication as settlement context
Publication exists so the contract layer never has to trust a vague operator claim about runtime state. When the runtime ships a root together with sequence, oracle, batch, and config references, the vault on Base receives a concrete description of what the venue believed at the moment state advanced. That description is what withdrawals, disputes, fraud proofs, reconciliation, and post-hoc review all hang on. Without it, the contract would only know that an off-chain process claimed a balance; with it, the contract can anchor a specific runtime view, preserve it in history, and require every settlement action to point back to something concrete.
Publication is not treated as a runtime-only action. Before the vault accepts a root, the sequencer commitment, oracle-source hash, and order-batch commitment must already be precommitted via precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment). The root is then submitted through commitStateRootWithConfig(...), which binds it to the active configHash and configVersion. If the precommitted material does not line up with the root, or if the contract-side governance lock is not satisfied, the publication is rejected and the root never becomes settlement context.
Production posture is stricter than a root commit alone. The governance lock requires the audit anchor to be active, setOrderCommitRequired(true) to be in force, and the publication path to maintain at least one durable evidence rail — either an archive requirement or a DA attestor requirement. A root that exists in isolation is not production-grade; it has to remain tied to the audit chain that explains how the state was published and to the same admission discipline that produced the order flow that generated it. That is what makes the off-chain runtime safe to anchor against on-chain custody.