Price sources
The exact source priority, freshness checks and cross-feed validation.
Source order
The backend reads Coinbase Exchange and Binance prices for configured teams, with CoinGecko as a fallback. For each snapshot, it considers fresh candidate prices in this order: Coinbase, Binance, then CoinGecko.
A snapshot can request a preferred source for consistency. If that source is unavailable, the feed falls back to the normal priority order. Binance may use its WebSocket or REST feed; the most recently received fresh Binance tick wins.
- Coinbase Exchange: first fresh candidate
- Binance: second fresh candidate
- CoinGecko: fallback candidate
Freshness and availability
Each candidate must pass a source-specific age limit. A stale or missing candidate is ignored. If no fresh candidate remains, the snapshot is withheld and retried rather than fabricated.
The checked-in backend example sets Coinbase's stale limit to 180,000 ms and the maximum cross-feed deviation to 200 basis points. Runtime configuration may differ; these are example values, not a promise about every deployment.
Cross-feed validation
The chosen price is compared with every other fresh candidate. If any available candidate differs beyond the configured deviation threshold, validation fails and the snapshot is blocked. If only one source is fresh, no cross-source comparison is possible.
What to audit
For a settled fixture, compare its recorded kickoff and end snapshots, price source metadata where available, onchain oracle submissions, and the final result. Source failover and validation are backend controls; the chain records the accepted submission, not every discarded tick.