Horizon made stake provisionable to named data services, each with its own rules, obligations and slashing. The Subgraph Service is the first and still dominant one.
The interesting question is what else gets built, because a substrate with one application is not a substrate. This entry is a survey of what exists, and it is deliberately dated: this is the fastest-moving part of the ecosystem and several of these are reference implementations rather than live businesses.
The shared machinery
Building a data service means implementing the same things every time: TAP v2 receipt validation, RAV aggregation, on-chain collection, persistence, and a payment gate in front of whatever you actually serve.
horizon-core factors that out into reusable building blocks, including a generic TAP-gated reverse proxy. If you are building one, start there rather than reimplementing receipt handling, which is the part with the sharp edges.
hello-data-service is the minimal reference implementation, and horizon-skills generates a complete service from a short specification. There is a guide dispatch that walks the whole thing.
What is being built
Query and RPC services. Dispatch is a decentralised JSON-RPC service: the thing an application uses before it ever reaches indexed data. compass turns every subgraph into a pay-per-call MCP tool, which is a bet that the consumer of chain data is increasingly an agent rather than a front end.
Alternative data shapes. seahorn indexes Solana program activity into typed, fork-correct entities over REST, which subgraphs do not cover. SDSCE brings Substreams onto Horizon as a paid service. wsaas streams pre-parsed transfers and swaps over one WebSocket connection, gated by TAP.
Things that are not query serving at all. FHSCE is trust-minimised chunked file sharing. nutcracker is end-to-end encrypted agent memory. chain-integration-ds meters per-chain integration revenue and settles through RecurringCollector rather than per-query receipts.
That last group is the point of Horizon. None of them serve a GraphQL query, and all of them use the protocol’s staking, payment and slashing machinery. The substrate is doing what a substrate is for.
The economics nobody has solved
Indexers are paid by issuance to serve subgraphs. A new data service has to attract operators who could instead be earning on the Subgraph Service, and it has to do so from its own revenue, because issuance goes to the Subgraph Service.
That is a hard start. The forum dispatch on this is blunt about it: the substrate works, and getting operators to run something new on it is the unsolved part.
Worth reading alongside GIP-0089, which redirects a fifth of issuance to the Foundation treasury once it activates. Where issuance goes is exactly the lever that decides whether a second data service can ever recruit operators.