RUNTIME AND PUBLICATION
It validates signed flow, applies risk and market-state rules, updates balances and positions, advances funding, runs forced routines such as liquidation and ADL, and prepares the settlement references later anchored by the contract layer.
| Published item | Why it exists |
|---|---|
| State root | Anchors account state for later settlement and withdrawal proofs |
| Root id and timestamp | Places that state inside an explicit publication history |
| Sequence commitment | Binds event ordering to the committed state |
| Oracle-source hash | Binds the source posture used when state advanced |
| Order-batch commitment | Binds the batch context around that state |
| Config hash and version | Bind the risk and venue rules in force at publication time |
#Single-writer exchange state
Dexter is built around a narrow write path.
Funding updates, liquidation passes, imbalance routines, market-state changes, and publication all move through one ordered runtime flow rather than through competing writers.
In a derivatives venue, incorrect sequencing can be as dangerous as incorrect pricing.
The single-writer model reduces that risk by making one runtime responsible for the state transition sequence that the rest of the system later reads and verifies.
The same runtime that updates balances is also the runtime that prepares the material later referenced by settlement.
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 side does not have to trust a vague operator claim.
When the runtime publishes a root together with sequence, oracle, batch, and config references, the vault receives a concrete description of what the venue believed when it advanced state.
That matters for withdrawals, disputes, fraud proofs, reconciliation, and later review.
In production, the publication path 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 through precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment). The root is then committed with commitStateRootWithConfig(...), which binds the runtime state to the active configHash and configVersion. If those bindings do not line up, or if the contract-side governance lock is not satisfied, the publication should not become settlement context.
Production posture is stricter than a root commit alone. Governance lock expects the audit anchor to be active, setOrderCommitRequired(true) to be in force, and the publication path to keep at least one durable evidence rail enabled: either an archive requirement or a DA attestor requirement. In other words, a root is not considered production-grade just because it exists. It also 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.
Without publication, the contract side would only know that some off-chain process claimed to have reached a balance state.
With publication, the contract side can anchor a specific runtime view, preserve that view in history, and require settlement actions to point back to something concrete.