Thanks @fishermanpete, we’ve reproduced it and agree with the technical finding.
**What we confirmed**
- For `QmeTjgLfbsnT4bFWEtJf29uHLqjyQnkoAaCASShL1UVPEi` at block 25,875,139 (hash `0x04726bee…`) and indexer `0x090f7382…`, our graph-node returns `proofOfIndexing` `0xfff20c85…`, the value presented on 2026-09-01. Its public PoIs at 25,867,938, 25,875,139 and 25,882,338 are `0xf2ebaea9…`, `0x78ef641a…` and `0x192a6a50…`, matching the report’s “wrong” values.
- The manifest sets `indexerHints.prune: auto`, so graph-node (we run v0.45.0) keeps its default minimum of 500 blocks of history, about two hours on mainnet. Our closes on this deployment came 3 to 21 hours after the epoch block.
- graph-node’s `proofOfIndexing` only rejects blocks above the subgraph head. For a block below the earliest retained block, it builds a PoI from whatever digest rows remain and returns it as a normal result (`get_proof_of_indexing` in `store/postgres/src/deployment_store.rs`). Nothing in graph-node or indexer-agent flags it.
Our indexed data is correct. Our PoI at block 26,242,728 matches three independent indexers, and, as the report notes, a full-history sync reproduces our correct presentations byte for byte. The other four wrong presentations in the report have the same cause.
**Our position**
We’d ask the Arbitrators to consider a Draw under §8. The incorrect PoI came from graph-node returning a value, rather than an error, for a block it no longer held, under the default history the subgraph’s own manifest requests. This is graph-node’s default behavior, not something specific to our setup: any node on default settings that is asked for the PoI of a prune: auto deployment after the epoch block has been pruned (about two hours on mainnet, minutes on faster chains) returns a wrong value if the subgraph has changed since. As the report shows, every node allocated to this deployment, including pinax2 and Ellipfra, returns the same values for these blocks today. Because pruned nodes agree with one another, comparing PoIs across indexers doesn’t reveal it; only a full-history sync does.
The report contrasts this with our other indexer presenting correctly hours earlier. All staked.cloud indexers query the same graph-node and store, so the correct and incorrect presentations came from the same data, computed at different times. Had graph-node returned no PoI, indexer-agent would have refused to present one.
**What we’re changing**
1. Raising retained history on every pruned deployment we index (133) to just over one epoch of blocks for its chain (8,000 blocks on mainnet), so the epoch block is still held whenever we close. New pruned deployments will also keep more than an epoch by default.
2. Holding closes on those deployments until the extra history has built up.
Is there any additional information you’d like from us?
Thanks,
Staked Team
PS I think this also brings up a larger discussion about how to handle POIs of pruned subgraphs. I’d like to raise the issue here with the graph-node maintainers, specifically I propose that proofOfIndexing return an error for blocks below the earliest retained block and that PoI digests be kept longer than entity history. In particular, it seems that the default value of GRAPH_MIN_HISTORY_BLOCKS=500 combined with the current graph-node behavior where it doesn’t refuse POI requests for pruned blocks, means that any indexer using the default will not produce valid POIs on pruned subgraphs. So an indexer on the default will submit an invalid POI whenever it closes or collects on such a subgraph more than about 500 blocks after the epoch’s start block: roughly 100 minutes later on mainnet, or 2 minutes on Arbitrum.
Note this response was generated with some AI help 