How much head-deployment traffic bypasses the ISA?

Consumer pinning is measurable from outside the gateway. Here is a method, a number, and one question only Edge & Node can answer.

Background

An indexer asked in the indexer Discord why almost all queries on the subgraphs they care about go to one operator, despite better latency and being at chain head. We published an analysis concluding the gap was allocation coverage. That was wrong, twice, and both corrections are in graph-support#17.

The actual mechanism came from Marc-André (Ellipfra): consumers can pin an API key to a specific indexer, which bypasses indexer selection entirely. He named two paths to it — a consumer pinning away from an indexer serving bad data and never unpinning, and consumers with long, time-sensitive queries pinning to avoid timeouts, because the ISA scores on averages and cannot route per query shape.

The measurement

Pinning is not directly observable, but its shadow is. If an indexer is allocated on a deployment, healthy, at chain head, cheaper and faster than the incumbent, and still earns approximately nothing there, selection is not what decided it. Three public sources are enough:

  1. Realised query-fee revenue per indexer per deployment. On Lodestar, /api/indexer/<address>/revenue?window=30&byDeployment=1, which is RAV settlement rather than telemetry.
  2. Active allocations per indexer, from the network subgraph, to establish who is actually competing on a deployment.
  3. Each indexer’s unauthenticated /status endpoint, for health, earliestBlock, latestBlock and chainHeadBlock, which rules out pruning and lag as explanations.

The numbers

For the two indexers in that thread, over 30 days, restricted to the 190 highest-fee deployments and to the 50 where both hold active allocations:

  • The smaller indexer takes 20.3% of the two-way revenue pot on contested ground, against 43.6% fee-weighted allocation coverage.
  • The outcome is bimodal, not graded. It out-earns the incumbent on 26 of 50 contested deployments, at shares up to 95%, and earns near zero on most of the rest.
  • On the 23 where it loses, the incumbent is healthy on 23 of 23, and the loser is no more pruned there than where it wins (median 105,252 blocks retained across all 50, so pruning is uniform while the outcome is not).
  • The losing set carries 340,061 GRT of 30-day deployment fees against 156,314 GRT across the winning set. The concentration is not incidental: the top 10 deployments are 62.1% of sampled 30-day query fees.

A uniform indexer-side property cannot explain a variable outcome. Once health, freshness, pruning, price and latency are ruled out per deployment, what remains is demand-side routing that the ISA did not decide.

What we cannot see, and the ask

We cannot observe a pin. This is inference from the absence of any indexer-side explanation, so it corroborates Marc-André’s account rather than proving it.

The question for Edge & Node: what share of gateway queries carry an indexer preference, and is that share growing? Ideally broken down by deployment, since the effect concentrates on the highest-fee subgraphs. That single figure decides whether this is a handful of large consumers or a structural feature of how the network now routes.

The open question

Marc-André’s own framing, which is the more interesting thread: pinning is an easy workaround for consumers but not a good long-term state, and it is unclear how feasible query-aware routing in a next-generation gateway would be. The ISA scores an indexer on averages and cannot express “query X is long, indexer Y serves it fastest, send X to Y”. Until it can, pinning is the only tool a consumer with that problem has.

Posting this because the measurement appears not to be written down anywhere, and because an indexer looking at a dashboard cannot currently distinguish “I am losing on merit” from “this deployment is pinned”. Those call for completely different responses.

Credit: Tehn for the original question and for not accepting our first answer, Marc-André (Ellipfra) for the mechanism. Corrections welcome, we have already needed two.