Request for Information about Disputes #GDR-39

Governance & GIPs
1

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

Dispute ID: 0xad6d21423b299afee81005fbe86650511f9fedeb647595f51c22a9495bfd740c
Allocation: 0x15fe97853d4a67aa26bcdd90f1c8f38c55fbeff7
Subgraph: QmSq8WeQ28K6nNSg2JiN1xkC7EhLXHmPMUrUszMxrstdCY

Fisherman, could you share the insights or data you gathered that led to you filing the dispute? Please provide all relevant information and records about the open dispute. This will likely include POIs generated for the affected subgraph(s).

About the Procedure

The Arbitration Charter regulates the arbitration process. You can find it in Radicle project ID rad:git:hnrkrhnth6afcc6mnmtokbp4h9575fgrhzbay or at GIP-0009: Arbitration Charter.

Please use this forum for all communications.

Arbitration Team

1 Like
2

Thanks arbitrators for opening the forum post.

This is about grt.stakecn.eth with closing subgraph that is not up-to-sync. You may check their operator wallet 0xcD09Fc5fc328DfEB2792248B03fEe9A0c0b216Aa
with tx ID 0x64235141ee327e072ce736b7a4e17c2ad0f820b75892523f9f8bfeb2fa25e845

They used the Close Allocation contract method to close subgraph. Synced ones on the other hand they used Multicall method that comes from the agent.
Looks like they manually called the contract Close Allocation with a manual POI, instead of letting the agent do it.

Additionally you can curl http://43.248.96.60:7600 with the subgraph QmSq8WeQ28K6nNSg2JiN1xkC7EhLXHmPMUrUszMxrstdCY, blockNumber = 327283426 it returns null value. 327283425 returns POI value which means they are only synced till here.

1 Like
3

Hey there! Thanks for raising this up.
We managed to verify the claims of the subgraph not being synced yet, nor it being synced since the beginning of the dispute, which could mean it wasn’t synced by the time the allocation closed happened.

Furthermore, we were able to find evidence that proves the indexer used another indexer’s PoI when closing the allocation:

      {
        "closedAt": 1753969379,
        "id": "0xda7455a0e262e76bb41a0ed70a50f9541e6223a4",
        "indexer": {
          "id": "0xeeeee689aa442c607105f29f06d00d2f748776b2"
        },
        "poi": "0x7a762c6d289f9f883713495c15e3521f8407772213c26bca53734d26628c8b64"
      },
      {
        "closedAt": 1753940722,
        "id": "0x451868d3fcc14a81f4781eb84914758c873f9a0f",
        "indexer": {
          "id": "0x35917c0eb91d2e21bef40940d028940484230c06"
        },
        "poi": "0x7a762c6d289f9f883713495c15e3521f8407772213c26bca53734d26628c8b64"
      }

0x7a762c6d289f9f883713495c15e3521f8407772213c26bca53734d26628c8b64
for both the disputed indexer and the most recent allocation close before it.

With all that being said, this is a clear breach of the charter, and thus the dispute will be accepted.
We’ll share the transaction of said dispute resolution once it goes through.

Thanks!

1 Like
4

Cheers @juanmardefago, I’ve just initiated two more disputes on the same grt.stakecn.eth indexer based on the finding above for cloning POI from streamingfastindexer.eth.

Additionally, there’s one more for using cloned POI from grassets-tech-1.eth. I can provide the details in disputes 42 and 43.

Hope that doesn’t take too long as it’s a clear breach of the charter.

5

Actually, you made me realize I made a mistake. For this particular dispute, it seems the PoI wasn’t copied.
The data I provided is actually from the same deployment, but a newer allocation (which seems to be from one of the two new disputes you just filed, which we’ll soon create the new forum posts for, but as you mentioned, have data to back up the PoI copy theory).

This particular one, with allocation: 0x15fe97853d4a67aa26bcdd90f1c8f38c55fbeff7 doesn’t seem to have a copied PoI, but was indeed manually closed.

6

Dispute accepted, tx hash: https://arbiscan.io/tx/0xfa21794de6227c80a8d5ddf8915695793a75c0f7a03254cdac9beb9adb26bc6e