The Graph: a decentralised query protocol for blockchains

The five-minute read

One action, walked through

1. A developer publishes a subgraph manifest: which contracts, which events, which schema.
2. Curators signal on it, locking tokens as a statement that the subgraph is worth serving.
3. An indexer runs the mappings against chain history and keeps the store up to date as new blocks arrive.
4. A consumer, or a gateway in front of them, pays a query fee and receives a signed result.
5. If the result does not match the mapping, a challenger can dispute it under the paper's rules, with the indexer's stake at issue.

The argument, unpacked

What has to be true

• The chain data the mapping reads is available to indexers and to challengers.
• At least one indexer serves the subgraph. A perfect manifest with nobody running it is an empty API.
• Query receipts are retained by anyone who might dispute.
• The dispute window is long enough to matter and short enough that indexers will lock stake.

What happened after the paper

The Graph shipped a hosted service first and a decentralised network after, with gateways, curation and dispute parameters that evolved. Many applications still used the hosted path for a long time. The paper describes the staked indexer market. Whether a given query is served by that market or by a single operator is a fact about the deployment.

What to check before you use the idea

• Is this query served by a staked indexer or by one hosted operator?
• What would a challenger need in hand to prove a wrong answer?
• Who wrote the mapping, and is a wrong mapping distinguishable from a wrong index?
• What happens to the application if the indexer falls behind the chain tip?

Terms

Subgraph

A published mapping from chain events to the entities a query will return.

Indexer

An operator who runs the mapping, serves queries, and locks stake against being wrong.

Curator

A party who signals that a subgraph is worth indexing, with tokens at stake in that signal.

Fisherman

A challenger who disputes a query result that does not follow from the chain and the mapping.

The problem the paper names

A contract write is verifiable from the chain. A rich read — every trade in a pool, every position in a market — is a query over history that a phone should not reconstruct alone. Centralised indexers fill the gap and become silent dependencies.

What the design proposes

• A subgraph schema defines how chain events become queryable entities.
• Indexers choose subgraphs, stake, and serve queries. Their responses can be checked against the stated indexing rules.
• Curators and delegators, in the paper, allocate attention and stake. They are economic roles, not honourifics.

How the mechanism is specified

• Payment for queries is what makes indexing a job rather than a volunteer mirror.
• Disputes and fisherman-style checks are the paper's answer to a wrong index, and they only work if a wrong index is detectable from public data.
• Hosted services and the later decentralised network should not be cited as if they were the same deployment.

What this page does not treat as proven

• An index is not a source of truth above the chain. If it disagrees with the chain, the chain wins.
• The paper does not make every possible query cheap.
• We do not describe token rewards as income.

Why a venture studio still reads it

Agent and analytics ventures usually hide an indexer in the architecture diagram. The Graph is the paper that pulls it into the open and gives it a stake, a schema and a dispute path.