What an indexer actually does

An indexer runs the machines that turn chain data into something queryable, serves queries against it, and periodically proves the work was done. That description is accurate and it undersells the job considerably, because none of the hard parts are in it.

The obligation, stated plainly.

You stake at least 100,000 GRT of your own GRT, may accept up to 16x that amount in delegated stake, and you allocate that stake to subgraphs you undertake to index and serve.

While allocated, you periodically publish a Proof of Indexing: a hash committing to the data you derived. If you go longer than 28 days without one, your allocation is stale and stops earning. If a POI you publish disagrees with what other honest indexers produced, somebody can dispute it and you can be slashed.

That is the whole contract. Everything else is your choice, and the choices are where the money is.

The four processes.

graph-node. Executes subgraphs. Follows chains, runs mappings, writes entities to Postgres, and answers GraphQL. This is the component doing the indexing, and it is the one whose resource appetite will surprise you.

indexer-agent. The decision-making component. Watches the network, opens and closes allocations according to your indexing rules, manages deployments, and submits transactions including RAV redemptions. If you have views about what to index, this is where they are expressed.

indexer-service-rs. The query front door. Takes queries, validates the payment receipt attached to each one, forwards to graph-node, and stores receipts. It is stateless and it is what the network actually talks to.

indexer-tap-agent. Aggregates stored receipts into vouchers that can be redeemed on chain. Runs as a single instance. Covered properly in the payments lesson.

Around those sit Postgres, the chain endpoints for every network you index, and whatever monitoring you are willing to be woken up by.

What the software will not decide for you.

This is the part that separates indexers who earn from indexers who merely operate.

Which subgraphs to index. Thousands exist. Your capacity does not stretch to them. Signal indicates where the protocol thinks value is, and following signal blindly puts you in competition with everyone else doing the same.

How to price queries. You publish a cost model. Price too high and the gateway routes around you. Price too low and you serve expensive queries at a loss. This is a real pricing problem and the defaults are a starting point rather than an answer.

How much stake to allocate where. Allocation determines your indexing rewards and, through the rebate mechanism, how much of your query fees you keep.

Which chains to support. Every additional chain is another node to run, another sync to babysit, another thing that breaks at the weekend.

The costs nobody quotes.

• Archive nodes. Indexing history means reading history. Either you run archive nodes or you pay someone for them, and on a busy chain neither is cheap.
• Storage that only grows. Every subgraph you index is a Postgres database that gets larger indefinitely.
• Attention. Chains fork, subgraphs fail on contract upgrades, syncs fall behind. Stake sitting behind a broken deployment earns nothing while looking exactly like stake that is working.
• Capital opportunity cost. Your self-stake is committed. Compare against what it would earn delegated to somebody else, which is the honest baseline and is the subject of the next lesson.

What Horizon changed at the top level.

Three things, each covered properly later in this path:

• Stake is provisioned against a specific data service rather than pooled generally. You register with the Subgraph Service and provision to it.
• Allocations can in principle remain open indefinitely, with periodic POIs replacing the close-to-collect cycle. In practice the shipped stack still recycles them, and that gap has its own lesson.
• Slashing is flexible, judged by arbitrators within a cap rather than fixed.