Indexing dispute against indexer 0x0a015d9e (decisionbasis-style curation scheme, GDR-15 basis)

Indexer: 0x0a015d9e17d3978164486473a2ddbb654418db07

I filed dispute 0x9347e202063c5cc554f9245795d580a01dbaea111ce4f717271e81d051ad7b41 on allocation 0x6997fe50693b5ef8bfa8962491b11deee3f606bd (QmUjdo2amhPaVEwiGQtcX9bNhVUiVt3K1iyW5wB1XbSuiR, chapel). The PoI was presented on 2026-10-16.

The basis is the one the Arbitrators accepted in GDR-15: manipulating the curation mechanism to provoke economic actions from honest indexers. This indexer is the name signal curator on 744 of 1000 sampled open allocations, is the only indexer on nearly all of them, and collects about 24x the network median reward per allocated GRT. Everything is on chain and the full evidence pack is here: Evidence pack: indexing dispute against 0x0a015d9e (GDR-15 basis) · GitHub

Happy to answer questions from the Arbitrators or the indexer here.

Two additions.

I reproduced two of the indexer’s base-sepolia PoIs on my own graph-node (QmPVy6gga8N783YvdQfKJrzHfkas72e6FBjjkCuKKwJziL and QmP644tHn1ba3q8s463ZxUPsf6pXhnskf25yCbQECmEtPE at block 48200175) and both match what was presented, public and indexer-hashed alike. So this is not a bad PoI case, the indexing is fine. The dispute rests on the curation scheme, the same ground as GDR-15.

The curation side, from L2GNS events over the last 58 days: this address minted about 242k GRT of name signal in 3,470 transactions and burned about 147k GRT in 1,848. No other curator on the network is within a tenth of that volume. The last batch of burns landed about half an hour before this thread went up.

Hi @AxiomaticAardvark thanks for posting. For completeness sake, here is the usual message the arbitration council posts to contact fisherman and indexer, thanks!


The Arbitrators are contacting Indexer address 0x0a015d9e17d3978164486473a2ddbb654418db07 and fisherman 0x083a086ca2ccec6526cbe97b2841a481f99834af for a new dispute filed in the protocol.

Dispute ID: 0x5f09720628c817c3ba5f1002c8a207693a5f6c677d452ddb81e113771abb527a
Allocation: 0x6997fe50693b5ef8bfa8962491b11deee3f606bd
Subgraph: QmUjdo2amhPaVEwiGQtcX9bNhVUiVt3K1iyW5wB1XbSuiR

It’s been brought to our attention that while this specific allocation/subgraph is being disputed there isn’t a problem with the POI/indexing and instead the dispute is about broader indexer behavior. In light of this, this dispute is to be used to centralize any and all discussion about this specific indexer, please do not open additional disputes.

Please use this forum for all communications.

Arbitration Team

Disputes
--------
Dispute (0x9347e202063c5cc554f9245795d580a01dbaea111ce4f717271e81d051ad7b41)
├─ Type: Indexing
├─ Status: Undecided (0.98 days ago)
├─ Indexer: 0x0a015d9e17d3978164486473a2ddbb654418db07
├─ Fisherman: 0x083a086ca2ccec6526cbe97b2841a481f99834af
├─ SubgraphDeployment
│  └─ id: 0x5f09720628c817c3ba5f1002c8a207693a5f6c677d452ddb81e113771abb527a (QmUjdo2amhPaVEwiGQtcX9bNhVUiVt3K1iyW5wB1XbSuiR)
├─ Economics
│  ├─ indexerSlashableStake: 7500.0 GRT
│  └─ indexingRewardsCollected: 24.878614335185249185 GRT
├─ Allocation
│  ├─ id: 0x6997fe50693b5ef8bfa8962491b11deee3f606bd
│  ├─ createdAtEpoch: 1409
│  ├─ createdAtBlock: 0x02d80e80a0e4a2f49c4cb517d17ba82b5a786923f2c9192bece71f9d24f589de
│  ├─ status: Active
│  └─ lastPoiEpoch
│     ├─ id: 1414
│     └─ startBlock: 0x3c8ec42f4b02a5fc442042bca1372a0ec074e26cdc2a6b4398aca260dfed7b9b (#26206337)
└─ POI
   ├─ submitted: 0x08efed2d5ba5bb3165fbed91b63f70a90f10f24a14af1c8a405acbc7631b7dde
   ├─ match: Not-Found
   ├─ previousEpochPOI: Not-Found
   └─ lastEpochPOI: Not-Found

Data dump, as asked. Everything is derived from Arbitrum One events (SubgraphService, DisputeManager, L2GNS) over the 58 days to today, CSVs plus a summary and a README: Evidence: indexer 0x0a015d9e, dispute 0x9347e202 (osprey dump, 58 days of Arbitrum One events) · GitHub

The pattern, in numbers. This address minted 242k GRT of name signal in 3,470 transactions and burned 147k GRT in 1,848. Of those burns, 1,248 (102k GRT) came within 72 hours of another indexer opening an allocation on the same deployment, median 24 hours after.

Rewards: 205k GRT collected in the last 28 days on 803k allocated, 0.255 per GRT against a network median of 0.012 across 48 indexers, about 22x.

PoIs: three recomputed on an independent graph-node, all three match.

Since 16 October, the date of its last PoI batch: zero PoIs presented, 1,459 burns, 95k GRT of signal pulled.

can confirm

noted overpaying signals on some sepolia, synced the node, synced 100+ subgraphs, allocated, signal disappeared in less than 24h to some other exotic testnet subgraphs (base sepolia and chapel - why even keep these rewarded?)

given my previous history of being slashed for this behavior: https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-15/ there’s already of precedent that established that self-signalling may be a gray area, but signal rug is def punishable.

please consider slashing this indexer to the amount of unfair rewards (200k) and then some on their own stake so that there is no incentive of repeating the same attack

bad coffee, bad

What the protocol pays for

I want The Graph to be where developers get any blockchain data they need, reliably and at a low price, across every data service it runs. For subgraphs, that starts with indexing everything. So my aim is simple: if a subgraph exists on a network governance has chosen to reward, I want it indexed. I don’t try to guess which subgraphs will be queried, and the protocol doesn’t ask me to. A Principal Systems Architect presenting the 2024 protocol economics proposal put it plainly: “indexers are not well positioned to predict consumer demand”, and it’s not “the role of an indexer to try and figure out what queries are going to happen on which subgraphs” (Office Hours 187). Indexing rewards exist so that data is indexed before demand appears: “you need some amount of indexers that have stepped up and indexed the data before that query demand exists and and so that is what indexing rewards are for” (Indexer Office Hours 77).

I’ve put my own capital behind that. I index 37% of all the subgraphs that rewards-earning indexers cover (1,829 of 5,003, counting current versions with stake allocated), and serve queries on all of them, while holding 1.3% of the network’s signal. For my size, nobody indexes more: I cover nearly 9 times as many subgraphs per GRT of stake as any other indexer that earns rewards, and over 450 times the median, and I keep the 2nd most subgraphs synced to chain head on the network: 1,943 on their current versions, behind Ellipfra’s 2,753 and ahead of the 1,335 the upgrade indexer’s public status endpoint reports. The protocol has already approved paying indexers directly for this kind of coverage (GIP-0087 and GIP-0088); until that runs, curation is how it gets paid for.

How I counted, on 19 October 2026: subgraphs where an indexer has stake allocated, on the subgraph’s current version, and synced to within 100 blocks of chain head according to that indexer’s own public status endpoint, divided by its provisioned plus delegated stake. The comparison is with the 47 other indexers that earned rewards in the previous 30 days and whose status endpoints answered.

How I fund it

I curate with my own GRT, from my indexer address, on subgraphs I index, on networks governance chose to reward: the Council chose Arbitrum Sepolia and Base Sepolia (GGP-0052 and GGP-0053), and the Foundation chose Sepolia and Chapel (GGP-0057). Every position is public: today about 129,000 GRT across 1,705 subgraphs, about 76 GRT each on average.

Signal is a capital allocation, not a forecast of demand. My signal says one thing: I’m willing to pay for these subgraphs to be indexed. On 1,306 of the 1,705 subgraphs I curate, nobody else is. Those subgraphs received about 1.1 million gateway queries in the 30 days to 18 October, and I served about 548,000 of them (the gateway’s own QoS oracle, published on-chain). If no one paid for the long tail, rewards-earning indexers would have little reason to index it.

Why my signal moves when larger indexers arrive

I aim to size signal at roughly what makes a subgraph worth indexing for an efficient operator, and no more. Above that, issuance pays for duplicate indexing the subgraph doesn’t need. As the Principal Systems Architect quoted above put it, “you might have 100 indexes index it and when you don’t really need 100 indexes maybe you only need 10 … it becomes inefficient” (Office Hours 187). So when a much larger indexer arrives on a subgraph I’m funding, the market is already paying for it to be indexed. I reduce my signal there and put that capital on subgraphs nobody else covers. Finding the right level means adjusting and watching how the market responds, like any price discovery.

I keep indexing what I reduce: 1,838 of my 1,840 reductions in the last 30 days were on subgraphs I’m still allocated to. Anyone who arrives is free to stay. I won’t pretend I mind when a much larger indexer decides one of my subgraphs isn’t worth its time at that level. But that’s its decision.

My own returns over the last month were high, and I don’t dispute the figures. They came from being the only indexer on hundreds of small subgraphs: an average 89 GRT return per allocation over 30 days, against 1,338 for the median indexer, and the rate falls as others arrive. To the indexers objecting: if you can be bothered to scrape the bottom of the barrel for 89 GRT a subgraph a month, be my guest. The network wants this work done. The protocol pays for it. You’ve had years to do it, and you didn’t.

The capital gap

Rewards on a subgraph are split by allocated stake, so whoever has the most capital can take most of any pool. Among rewards-earning indexers with 500 or more active allocations, I have by far the smallest stake: the next is nearly 8 times mine and the largest over 200 times. Ellipfra’s allocations on subgraphs I curate come to about 2.8M GRT. That’s 1.7% of his stake, and about 3.5 times everything I have allocated. What do they call this in poker, the big stack bully, or something? On 17 October he wrote on Discord that he “could probably make this attack unprofitable with allocations”. That’s free market competition, and so is my deciding where my own signal goes. I can’t compete on stake; where my signal goes is the lever I have.

Competing in the open

The protocol assumes everyone acts in their own interest: indexers allocate for rewards, resize, and compete for the same pools. If wanting to beat competitors were the offence, every indexer would be guilty. What matters is how you compete, not whether you want to win. The GDR-15 investigation (post 38) found a separate curator wallet and signal on a deprecated version used “as a form of deception”. I do the opposite: I index 37% of the subgraphs rewards-earning indexers cover, my signal sits on the versions apps actually use, and every move is made in the open from my indexer address, where anyone can see it and price it before deciding.

The rules

The charter treats an indexing dispute as a challenge to a POI, and the Arbitrators have said there isn’t a problem with the POI here. After GDR-15 they recommended adding “a specific clause about indexing rewards manipulation through gaming the curation mechanism to avoid doubt that this is a penalized behavior”, and asked for “a mechanism that eliminates any room for interpretation and the need for social consensus” (post 43). Neither happened: when the Council approved a new charter 32 months later (GGP-0056, September 2025), it added no such clause. I’m not saying that makes anything right. I’m saying no written rule covers this, and slashing for it now would leave every indexer who curates guessing where the line is.

It’s also worth noticing who asked for this. On Discord, decisionbasis’s operator, whose indexer I disputed twice earlier this year (GDR-48 and GDR-49), wrote “can someone slash 0xbadcoffee”. Public choice economics has a name for competitors asking the rule-makers to remove a rival instead of out-competing it: rent-seeking. Arbitration shouldn’t be a way to remove a competitor the protocol rules allow.

Curation is meant to be permissionless; this would add an unwritten permission on top of it. In practice, no indexer could ever reduce its signal without fearing a slash. Signal would become a one-way door, and few indexers would risk funding new subgraphs at all. That means fewer subgraphs indexed, a network less useful to the developers and consumers who rely on it, weaker network effects, and slower growth for everyone.

1 Like

On serving queries: lifetime indexing rewards about 447k GRT, lifetime query fees about 1.6k GRT. 99.6% for being allocated, 0.4% for serving.

GDR-15 was decided under a charter with no curation clause either. The Arbitrators slashed signal used “to provoke economic actions from honest indexers” and said one dispute would have been slashed in full. Doing it from the indexer address changes who can watch, not what it does to the indexers who follow.

I served twice as many queries in the 2 months since my last collection as in the 7 months before it, per the gateway QoS oracle. My allocation and signalling strategy enabled me to grow how much work I deliver, and serve a wider band of the network’s subgraphs than almost any other indexer, while the network’s total query volume fell by about half.

Over the last 30 days, my queries had a 97.5% success rate, against a network median of 89%, and 190 ms latency against a network median of 336 ms. The gateway also penalises small stake indexers by not selecting them as often to serve queries.

1 Like

The query growth starts when the allocations do. The indexer had 2 open allocations on 1 September, 250 on 1 October and 800 on 18 October, 429 of them on deployments it signalled itself, none closed. Eight hundred allocations get more queries than two.

Nobody has disputed the serving. The dispute is the signal that put the allocations there. 5.5M queries since August with nothing collected does not change what they earned.

Firstly, thats entirely the point.

Secondly, in what would would it be the other way round?

Thirdly, this is completely factually incorrect. Must I really waste my time defending this? At what point is it the fishermans responsibility to bring correct data to the table?

You can see, right from my first week as an indexer I began serving hundreds of subgraphs. How many indexers even serve hundreds of subgraphs?

The allocation counts in my last post were wrong. They came from a table that starts on 26 August and I did not check it against the network subgraph. Your chart is correct: 344 open on 1 August, 1,281 on 10 August, 2,308 at filing, hundreds served since January. Your success rate and latency also check out against the oracle.

Here is the full history from the network subgraph, the QoS oracle and the rewards events on chain.

On 5 August the indexer opened 937 allocations in one day and 229 more on 13 August. Queries roughly doubled over the following weeks. Rewards did not move, because most of those subgraphs had no signal.

In September it minted signal 2,773 times, 131k GRT, on subgraphs it already held: 1,304 of the 1,444 allocations on subgraphs it later signalled were opened before the signal, a median 29 days before. Rewards went from 47k GRT in August to 93k in September and 156k in the first 16 days of October.

In October it burned signal 1,639 times, 121k GRT. 1,250 of the 1,848 burns since August came within 72 hours of another indexer allocating to that subgraph.

Of the 1,967 allocations opened since August, 1,014 served no queries at all between 17 August and 18 October and the median served two. 59.5% of the queries in that period came from the 341 subgraphs held on 1 August.

In the first 16 days of October the indexer collected 1.65% of all indexing rewards on the network, rank 11, with 0.054% of allocated stake. From 1 September to 18 October it served 0.20% of the network’s successful queries, rank 35 of 56.

The serving is not in dispute. The signal placed on subgraphs the indexer already held, and pulled when anyone else arrived, is what produced the rewards. GDR-15 slashed the same pattern.

One more thing, for the Arbitrators and for every indexer reading.

Signal is the only information an indexer has about where the network wants work done. Six indexers followed this signal: 3,303 allocations on 1,449 subgraphs, 12.1M GRT. 1,044 of those subgraphs now carry under 100 GRT of signal, because it was withdrawn once they arrived. 1,281 of their allocations are still open on them.

Whether or not the charter has a clause for it, placing signal so that other indexers will sync a subgraph and then pulling it when they do uses their good faith as the instrument. I would ask the Arbitrators to weigh that, and the rest of us to say whether this is how we want allocation to work.

My case in full is above, see my first post in this thread. I have nothing more to say here.

2 Likes