Summary: Graph Horizon is best understood not as a routine protocol upgrade for The Graph, but as a refactor that turns The Graph into a reusable staking-and-payments substrate for many different data services. Its core move is to separate service-provider stake, payment collection, and service-specific logic into explicit layers: provisions assign slashable stake to a chosen data service, GraphTally-style payment collection plugs into generalized escrow and distribution contracts, and each data service can define its own registration, slashing, thawing, and operational rules. That makes Graph Horizon a useful comparison class for staking-backed service marketplaces, machine-payments systems, and modular infra protocols: the important question is not just how The Graph indexes subgraphs, but how a protocol lets many data services share common economic security while still creating new control surfaces around service admission, delegation, dispute policy, and fee routing.
What it does:
Recasts The Graph as a broader data-services protocol rather than a subgraph-only indexing network
Introduces provisions, which assign stake to a specific data service and make that stake slashable under that service’s rules
Makes delegation data-service-specific, so delegators choose both a provider and the service whose risk/reward profile they want to back
Generalizes payments around integrated escrow and distribution contracts, with GraphTally as the first built-in payment collection system
Lets each data service define its own registration requirements, thawing periods, slashing rules, and operating constraints rather than forcing one global service model
Uses SubgraphService as the first Horizon-native data service, including a path toward longer-lived allocations with periodic POI freshness requirements
Expands the kinds of services The Graph can host beyond subgraphs, with official materials naming possibilities like Firehose, Substreams, SQL queries, LLM queries, oracle systems, and challenge systems
Key claims:
The Horizon overview explicitly says the protocol is being transformed into a “more flexible and modular data services platform,” which is the clearest reason to catalog Horizon as a protocol substrate rather than as a product refresh.
GIP-0066 frames Graph Horizon as a data-services protocol composed of staking and payments primitives, and it explicitly lists potential data services beyond subgraphs. That matters because the protocol’s core unit is no longer the indexer serving a subgraph, but the more general relationship between service provider, data service, payer, and receiver.
The provision primitive is the main reusable mechanism. A provider stakes GRT, assigns part of it to a specific data service, and that service can then treat the provision as slashable economic security subject to its own thawing and dispute rules.
Horizon moves practical power into data-service design. The official docs say registration is now handled by each data service when needed, and the GIP says each service can define its own slashing authority, thawing requirements, and operational standards.
Delegation becomes a sharper governance surface in Horizon because delegators must choose both a service provider and a data service. This is more analytically useful than generic staking language because it makes service-level risk selection explicit.
The payment system is no longer just a side mechanism for subgraph queries. The docs describe GraphTally as the integrated payment collection system inside a generalized payments protocol, which means Horizon is trying to standardize fee collection and fee distribution across future data services.
The what changes docs show that even seemingly familiar subgraph operations are being decomposed differently: payment collection now locks stake according to a stake-to-fees ratio, allocations are designed to become long-lived, and gateways serve only Horizon-era GraphTally receipts.
Horizon belongs in the active corpus because it separates at least three layers that generic The Graph infra coverage usually flattens together: payment rails like Graph Tally, reward-quality gating like REO, and the higher-layer staking/payments framework that future data services inherit.
Whitepaper: No standalone Graph Horizon whitepaper surfaced in this pass. The strongest primary materials were The Graph’s official Horizon docs and the approved GIP-0066 specification; see ../whitepapers/graph-horizon-primary-sources-2026-05-12.md.