Whitepaper / ORACLE INTAKE, FALLBACKS, AND SOURCE SELECTION
Dexter whitepaper

SOURCES AND FALLBACK

Every fill, every drawdown check, every leaderboard rank, and every USDC payout traces back to a price Dexter accepted at a specific timestamp. A single publisher going dark cannot be the same event as a market freezing or a payout being denied — the source layer is engineered so that primary failure switches to a pre-vetted redundant path within the same tick, and only collapses the market into reduced or close-only when no path passes the deviation, freshness, and depth gates. Below is the full source ladder, how the mux promotes one path active, the exact conditions that flip a market into degraded posture, and what happens to your open positions and your 30-day challenge clock when that happens.

Page last sync: May 24, 2026
Sections 2 Read 1 min Whitepaper chapter

Normal operation on every Dexter market requires two healthy paths at once: a primary Hermes/Pyth push stream and an independent HTTP oracle mux that the runtime polls and cross-checks against the primary every tick. Single-source operation is not a steady state — it is an explicit liveness override engaged only when the runtime has logged the failure, recorded the policy exception, and downgraded the market to a degraded posture for the duration. The ladder below is therefore an ordered failover plan, not a buffet the mux picks from.

Source path Role in the venue
Hermes / Pyth (primary) Low-latency push reference anchor for every supported market; aggregates the publisher set Pyth verifies on-chain
HTTP oracle mux (cross-check) Independent pull path that must agree with Hermes within the deviation band on every tick before the mark is promoted
Single-path liveness override Engaged only when one family is down and the runtime accepts reduced quorum; the market simultaneously drops to reduced or close-only
Last-known controlled hold If no path is acceptable, the engine holds the last validated mark, halts new execution, and emits a degradation event for operations and the published state

#How a source becomes active

A fallback path existing is not the same as it being trusted. The source mux makes one decision per tick per market: which combination of available paths clears the freshness window, agrees within deviation bounds, passes the per-market lag ceiling, and respects the depth/spread guard. That decision is policy, not heuristic — the same inputs always produce the same outcome, and the chosen source set is recorded in the runtime log and stamped into the next settlement root.

Conservatism is the explicit default. When the primary weakens, the mux first tries to keep both paths live by widening latency tolerance within the configured ceiling. If the cross-check still fails the deviation band, the runtime prefers to downgrade the market — to reduced, then close-only, then halted — rather than promote a thinner source set into normal posture. Convenience and pretty uptime numbers are not valid reasons to keep trading on a path the rest of the policy does not stand behind.

When a fallback is engaged, two things happen simultaneously. First, the matching engine continues to fill reduce-only orders against the surviving path so users can manage open risk. Second, the market state is published as degraded so every connected client, the rule engine, and the cashier see the same posture. A reviewer reading the runtime log later can answer one question without ambiguity: at every tick, which path was active, why, and what posture did the market trade under?

TEXT
 tick T arrives
   -> mux reads Hermes primary + HTTP cross-check
   -> freshness, deviation, lag, depth gates evaluated
   -> if both pass: mark promoted, market stays live
   -> if one fails: mux retries within latency ceiling
   -> if still failing: market posture downgrades
        reduced -> close-only -> halted
   -> selected source set and posture hash
        committed inside the next state root

#Why source selection matters for settlement

The active source set is not an operational footnote — it is part of the on-chain settlement record. The runtime hashes the source-posture metadata (active publishers, fallback engagement, deviation observed, freshness margin, market posture) and commits that hash inside every state root the vault contract accepts. A withdrawal finalized against root R is therefore bound to the exact oracle configuration that produced the balances inside R.

This is the difference between "the venue says it used Hermes" and "the contract can prove which feed posture every payout depended on." It is also what makes the price layer auditable in the same sense the balance ledger is: a post-incident reviewer reading state roots on Base can answer not only what an account was worth at root R, but which source paths were live, which were degraded, and which posture the matching engine was running under when that snapshot was sealed. Mark construction details continue on Mark construction; session and degraded-state transitions are documented on Sessions and degraded states.