Skip to content

šŸŒ Oracle System

The Oracle System is Surge's BTC/USD price feed. Unlike external oracle plug-ins, Surge treats price discovery as a first-class part of the protocol: the price that drives a borrower's collateral ratio is the same price every signer in the Distributed Custody Network sees and validates against before producing a signature.

The Oracle System powered by:

  1. Chainlink's decentralized oracle network updates their feed
  2. Our Oracle system reads the latest price fromĀ Chainlink and updates

The Oracle System powers:

  • Collateral monitoring - monitoring each Vault's live Collateral Ratio (CR).
  • Liquidation enforcement - surfacing positions for checkHealth(...) when CR < MinCR or near liquidation threshold.
  • Per-signer validation - every signing request is evaluated against the most recent confirmed price; stale or out-of-band prices abort signing rather than producing a bad spend.

The intent is that no single off-chain actor can move a position into liquidation, and no signer participates in a signing session whose authorisation is grounded in an unhealthy price.

Failure Safety

  • Deterministic fallbacks. If insufficient fresh updates are available for a new median, the system reuses the last confirmed price until new data finalises. No "best guess" or extrapolation.
  • Graceful degradation. Rather than emitting a stale price, the protocol pauses CR updates and surfaces an alert. Existing positions remain readable; new health-trigger actions wait until fresh data is available.
  • Manipulation resistance. No one can override prices, Immutable and All logic verifiable on-chain

Per-Signer Oracle Validation

Each DCN signer validates the price grounding of every authorisation before participating in signing session:

  • Freshness. The price is no older than the configured staleness window.
  • Cross-signer consistency. The price the signer sees locally agrees with the protocol's consensus price within a configured delta.
  • Sanity bands. The price has not deviated from the last confirmed value by more than a configured percentage over a single interval.

If any check fails on any signer, that signer refuses to participate, the quorum is not met, and no signature is produced. The cost of an oracle anomaly is a delayed liquidation, not a wrong one.

See Signing Policy for how this validation interlocks with the rest of the per-signer policy stack.

Oracle Events

The Oracle System emits canonical events consumable by the Smart Contracts, the Relayer, and external observers:

  • PriceUpdated { medianPrice, timestamp }
  • CollateralRatioUpdated { positionId, newCR }
  • LiquidationTriggered { positionId, CR }

These events form a complete, replayable audit trail for liquidation decisions: any observer can reconstruct, from public data, exactly which price drove which collateral-ratio update and which liquidation.

Roadmap

The oracle path will continue to evolve toward broader source diversity, public transparency of submitter identities and signed-update history, and a published deviation budget so any party can independently verify that the protocol's medianized output remained inside policy at every interval. The destination state is a feed whose correctness can be audited end-to-end by anyone, not trusted by configuration.