Supra Oracles

  • Name: Supra Oracles
  • URL: https://docs.supra.com/oracles
  • Category: oracle / verifiable-data infrastructure / DORA consensus network / dVRF-enabled data and randomness middleware
  • Summary: Supra Oracles is a bundled oracle stack: source assignment, consensus, proof delivery, and randomness all sit under one operator umbrella. That is the useful cut. The note is not here to validate another feed brand; it is here to keep the assignment and delivery chokepoints visible.
  • What it does:
    • Delivers decentralized price feeds and other real-world data to smart contracts across multiple blockchains
    • Uses DORA (Distributed Oracle Agreement) to aggregate values from multiple data sources into a representative S-value
    • Randomly assigns and periodically reassigns node/source responsibilities with dVRF as part of its anti-collusion design
    • Offers both push-style onchain publication and pull-style proof verification for consuming feeds
    • Exposes a separate dVRF product for application randomness with wallet-subscription and callback-based access patterns
  • Key claims:
    • The most important design move is that Supra exposes several control planes that generic oracle labeling tends to flatten together. The docs distinguish DORA consensus, Tribe-Clan topology, source-to-node assignment, S-value aggregation, push delivery, pull proof verification, and dVRF randomness instead of presenting one monolithic feed product.
    • The DORA litepaper and docs are particularly useful because they explain why node assignment and source assignment are different problems. Supra does not only aggregate across sources; it also uses VRF-based assignment so data-source coverage and anti-collusion properties are part of the protocol design rather than operational details.
    • Supra’s pull model is analytically important because it shifts one part of oracle consumption into proof packaging and onchain verification interfaces like verifyOracleProof / verifyOracleProofV2, which makes it more comparable to proof-carrying oracle systems than to always-pushed feed contracts alone.
    • The separate dVRF docs matter because randomness is not only a downstream product here; it also feeds back into the oracle network’s own assignment and anti-collusion rhetoric. That makes Supra a useful comparison point for systems where randomness, scheduling, and reporting power are coupled.
    • Supra’s overall architecture belongs in the corpus because it shows how an oracle provider can bundle consensus, routing, proof delivery, and randomness into one vertically integrated stack rather than competing only on update frequency.
  • Whitepaper: Supra maintains DORA litepaper and whitepaper materials alongside current docs; see ../whitepapers/supra-oracles-primary-sources-2026-05-11.md.
  • Sources:

Internal linkages

  • Best upward reads: chainlink, pyth-network, and switchboard. Those keep the note on the strongest oracle, bundled-runtime, and delivery-model contrasts without turning it into a directory.

Governance / control risk

  • The real questions are who controls source assignment, how much trust sits in DORA and dVRF policy, which delivery mode becomes the operational default, and how much downstream users inherit from Supra’s own proof and routing stack.

  • Supra is useful because those choke points are unusually bundled. It is still a lower-tier oracle stack, not a category anchor.

  • Last reviewed: 2026-06-04 UTC