​

Why it matters

Oracles are core infrastructure for DeFi, stablecoins and risk systems, but networks differ in architecture, chain footprint, and reliability assumptions. A consistent set of Protocol entities with minimal, well-sourced coverage fields makes oracle infrastructure easier to discover, compare and link across Geo.

What to publish

Create or update a Protocol entity for each oracle protocol

Use the Protocol type as the main representation of the oracle.

Update-first (no duplicates):

  • Search Geo using the oracle’s website. If an entity already exists (oracle or an indexing directory), update and align; do not recreate under a new identity.

If a corresponding Project or Company entity exists (operator/maintainer/org):

  • Do not create a second “protocol identity” as a Project.

  • Link Protocol → Operating Project/Company (using the best available Geo relation) and/or add as a Related entity.

Fill the following Protocol properties, as available:

  • Website URL

  • Docs (developer documentation)

  • GitHub (org or primary repo)

  • X, Discord, Telegram and LinkedIn

  • Launched (date)

  • Has protocol type (besides using Topics or Tags) to encode:

    • price feeds

    • proof of reserves feeds

    • randomness

    • data streams or low-latency feeds

    • cross-chain messaging

  • Optional:

    • TVL

    • Volume 24h

Coverage statement:

  • Add a short, sourced statement in the Protocol description summarizing coverage, e.g.:

    • “Provides price feeds across EVM chains and selected non-EVM networks.”

  • Keep it high-level and directly supported by official documentation.

Scope

  • 8-15 Oracle protocols, prioritising the most integrated networks and widely referenced systems.

Potential sources

  • Websites and developer docs (primary)

  • GitHub repos and release pages (primary)

  • Public feed directories

Quality rules

  • Official-first only: no third-party lists as the primary source of truth.

  • No over-claiming: if coverage or feed types aren’t clearly documented, don’t tag them.

  • Avoid unstable metrics: only add TVL and Volume if you have a standard way to keep them current.

  • Avoid duplicates: one Protocol entity per oracle network; do not create parallel Project entities representing the same oracle protocol identity.