Summary: The Rewards Eligibility Oracle (REO) is best understood not as a mere monitoring tool or dashboard for The Graph, but as a new control layer that gates inflationary indexing rewards on measured service quality. Its core mechanism is a split between off-chain oracle nodes that evaluate indexer performance from gateway-collected query data, an on-chain oracle contract that stores time-bounded eligibility, and an upgraded Rewards Manager that checks that eligibility before distributing rewards. That makes REO a useful comparison point for oracle-mediated rewards systems, slashing-lite quality enforcement, and data-service incentive design: the important move is that The Graph no longer treats rewards as purely stake-and-allocation driven, but routes them through an off-chain quality-assessment pipeline with explicit governance knobs and fail-open safety valves.
What it does:
Evaluates indexers against published service-quality criteria such as days online, successful query responses, latency, and freshness over a rolling evaluation window
Uses off-chain oracle nodes to process performance data, currently sourced from gateway pipelines into BigQuery, and determine which indexers qualify
Renews qualified indexers on an on-chain eligibility contract for a fixed period, initially framed as 14 days, after which eligibility expires unless refreshed
Lets the upgraded Rewards Manager query the oracle at reward-claim time and deny rewards to indexers that are currently ineligible
Exposes operator-controlled configuration for eligibility period, oracle-update timeout, and a global validation toggle
Includes an operational stack around batching, RPC failover, scheduler-driven daily updates, artifacts for auditing, and dashboards/notifications for monitoring
Key claims:
The core reusable primitive is reward gating by service-quality oracle. REO inserts a distinct assessment-and-authorization layer between doing protocol work and collecting inflationary rewards.
REO makes a governance surface that would be easy to miss if filed only under The Graph. Power now sits not only in staking and allocations, but also in gateway metric collection, eligibility-criteria publication, oracle-node operation, operator role assignment, timeout settings, and the governor’s choice to connect or disconnect the oracle from the Rewards Manager.
The system is deliberately fail-open in at least two ways: governance can disable the oracle by setting the zero address on the Rewards Manager, and the oracle design treats all indexers as eligible if oracle updates stop beyond the configured timeout. That makes liveness and fairness tradeoffs explicit.
The off-chain criteria are intentionally conservative at launch, but the GIP explicitly says requirements can evolve over time through oracle-node configuration and published criteria updates rather than fresh protocol upgrades for every threshold change. That is analytically important because practical policy can move faster than onchain governance.
REO is not equivalent to slashing. It withholds rewards rather than seizing stake, so it behaves more like a quality-conditioned issuance router than a punitive fault-proof system.
REO belongs in the active corpus because it separates three layers that generic The Graph infra coverage tends to flatten together: query-payment rails like Graph Tally, quality-enforcement and eligibility policy via REO, and the underlying issuance machinery in Rewards Manager / Horizon.
The biggest open question is whether REO genuinely decentralizes service-quality enforcement or whether it concentrates soft governance in whoever controls gateway telemetry, BigQuery-derived methodology, criteria updates, and oracle-node operations.
Whitepaper: No standalone whitepaper surfaced. The strongest primary materials were GIP-0079, the official forum proposal, the REO repository docs, the eligibility-criteria document, the technical design note, the dashboard README, and The Graph technical roadmap; see ../whitepapers/rewards-eligibility-oracle-primary-sources-2026-05-11.md.