The problem The Graph solves

Start with a question an app actually needs answered.

Show me the last twenty trades made by this wallet, newest first, with the token symbols and the price in each one.

Every fact in that question is already on chain. Nothing is missing. And yet you cannot ask it.

A chain answers by position, not by meaning.

A node exposes a small set of lookups. Give it a block number and it returns the block. Give it a transaction hash and it returns the transaction. Give it an address, a block range and a topic filter, and eth_getLogs returns matching logs.

What it will not do is any of the things a database does. There is no ordering by a field you care about. There is no joining one contract’s events against another’s. There is no aggregation, no grouping, no counting. There is no index on “wallet” because the chain does not know that “wallet” is a concept.

So the honest answer to the question above is: read every block since the contract was deployed, decode every log, throw away almost all of them, and keep a running table of the ones that matter. On a busy contract that is millions of logs. Doing it live, per page view, is not a strategy. Doing it once and keeping the result is an index.

Indexing is the boring part, and it is most of the work.

An index is the derived table. You follow the chain from some starting block, decode the events you care about, and write rows into something you can query. From then on the question above is a SELECT with an ORDER BY and it returns in milliseconds.

The difficulty is not the idea. It is everything around it:

• Chains reorganise. A block you indexed can stop existing, and the rows derived from it have to be unwound.
• Contracts get deployed by other contracts. A factory pattern means the set of addresses you are watching grows while you are watching.
• Decoding requires the ABI, and the ABI is not on chain in any reliable place.
• The result has to keep up with the tip of the chain forever, not just catch up once.
• Somebody has to pay for the machine, and keep paying, at three in the morning, in year four.

Every team that has needed on-chain data has built this. Most have built it more than once.

Doing it yourself is fine until it is your only copy.

You can run that indexer in-house. Plenty of teams do, and for some workloads it is the right answer. What you have then is a single service, owned by you, which your product depends on completely. If it falls behind, your app shows stale prices. If the box dies on a bank holiday, your app is down. If you stop paying for it, the data stops.

Now put someone else in that position. If one company operates the index that a hundred applications read from, those hundred applications have quietly inherited that company’s uptime, its priorities, and its right to change the terms. The chain underneath is permissionless. The layer everyone actually reads through is not.

What The Graph adds is a market, not a database.

The protocol’s contribution is not the indexing software. It is the arrangement that makes many independent operators willing to do the indexing, and makes it possible to trust what they return.

Four things have to be true at once for that to work, and the rest of this path is mostly about how each one is arranged:

• Somebody has to run the machines. Those are the indexers.
• Somebody has to say which data is worth indexing, before the queries arrive. Those are the curators.
• Somebody has to put capital behind indexers they think are good, so that reliable operators end up with more of it. Those are the delegators.
• Somebody has to define what “the data” means for a given contract. Those are the developers who write subgraphs.

And underneath all of it, an operator who serves a wrong answer has to be worse off than one who serves a right answer. That is what stake and disputes are for, and it is the part that makes the whole thing more than a list of vendors.

What it does not do.

Worth being clear early, because a good deal of confusion comes from expecting the wrong thing:

• It does not make the chain itself faster. It changes what you read, not what you write.
• It does not store data that never touched a chain. If your application has off-chain state, that stays your problem.
• It is not a general purpose database you can write arbitrary rows into. The data is derived from chain events, and derived data is all you get.
• It does not remove the need to think about cost. Queries are paid for. The question is who pays and how, not whether.

Where this path goes next.

You now have the problem. Next is the loop that pays for the solution: who gives money to whom, what they get back, and why anyone bothers.