Provisions: staking against a service

Horizon turned one staking pool into stake provisioned to named data services, each with its own rules, its own thawing, and its own slashing.

5 of 10 in the Indexer path advanced 12 min

Checked against Graph Horizon (2025-12-11)

Last read 2026-08-30 Due again 2026-11-30

Every protocol claim below was read at these sources on 2026-08-30. Where they disagree with each other, the lesson says so.

Before Horizon there was one protocol and one thing to stake against. Horizon generalises that: the protocol becomes a substrate on which several data services run, and stake is provisioned to a specific one.

What a provision is.

A provision is an amount of stake committed to a named data service, under that service’s rules.

Registration follows the same logic. Per the documentation, “registration is now handled by each data service when needed. For the SubgraphService, indexers register directly with it.” There is no longer a single global act of becoming an indexer. You become an indexer for something.

For most operators today that something is the Subgraph Service, and the practical difference from the old model is small. The structural difference is not, and it becomes visible the moment a second service you care about exists.

your stake provision data service obligations & slashing

Why this shape.

Three reasons, and they are worth understanding because they explain a lot of Horizon’s other choices.

Different services need different rules. Serving GraphQL over a subgraph and producing a different kind of data product have different failure modes, different proofs of correct behaviour, and different reasonable penalties. Forcing them through one set of parameters would mean each fitting badly.

Risk should be separable. If a new service turns out to have a mechanism flaw, the damage is bounded by what is provisioned to it. Operators can participate in something new without exposing everything.

Services should be addable without a protocol rewrite. The whole point of a substrate is that adding one does not require changing the base layer.

What this means operationally.

You register with the service. For the Subgraph Service, directly with it.

Your obligations are the service’s obligations. Publishing POIs, the staleness limit, and what constitutes a violation are properties of the Subgraph Service, not universal protocol facts. Another service can define them differently.

Slashing is per service, and now flexible. Arbitrators determine the amount by severity within a cap of 10% of the indexer’s stake, with a recommended value of 2.5%. Previously the amount was fixed rather than judged, so a minor operational fault and deliberate misbehaviour attracted the same penalty.

Delegated stake is not currently slashable for the Subgraph Service: Not currently. The capability exists in Horizon and is switched off. A future service could switch it on for itself, which is a thing to tell your delegators rather than a thing to leave for them to discover.

The self-stake minimum still applies. 100,000 GRT remains the floor for the Subgraph Service. Minimums for services that do not exist yet will be set as those services are integrated, so treat any figure you see for them as provisional.

Thawing on the indexer side.

Stake provisioned to a service cannot be withdrawn immediately, for the same reason a delegator’s cannot: the protocol needs the stake to still be there when a dispute about past behaviour is resolved.

Plan capital accordingly. Stake committed to a service is committed for the length of that service’s thawing period beyond the moment you decide to stop, and that is a scheduling constraint rather than a fee.

Before reading on: why let each service define its own slashing rather than keeping one protocol-wide rule?

Because a single rule has to be simultaneously right for services that have not been designed yet.

Slashing needs to be proportionate to the harm a service can suffer and to what its proofs can actually establish. A service where correctness is cheap to verify can afford a firm penalty, because false positives are rare. A service where correctness is expensive or probabilistic cannot, because the same penalty would occasionally punish honest operators.

Fix one rule for everything and you get the worst of both: too harsh where evidence is weak, too soft where it is strong. Per-service rules let each one be calibrated to its own evidence, and let an operator read the terms before provisioning to it. The cost is that “what happens if I get this wrong” stops having one answer, which is why it now needs checking per service.

Check yourself

Under Horizon, an indexer registers:

Why is stake provisioned per service rather than pooled?

Slashing under Horizon is: