The Arbitrators are contacting Indexer address 0xf6a9bad58e74b5165dc31ef24be4377b192f274a and @InspectorPOI about a new Dispute filed in the protocol. This dispute has been filed over the same issues as GDR-18 and GDR-19, closing subgraph QmYrEJKHphWBGkqPkEVKSZR9gsoD6RtJs3g3R8iWVhH66Z multiple times with the same POI used for months. This POI has been reused again.
Disputed indexer, we are reaching out again to give the opportunity to provide any information on this dispute, as we will move to slash after 7 days if we have not heard back. This is a repeat offense but we believe in following the charter in an effort to provide fairness to all parties involved.
@InspectorPOI, this is a continuation of the offenses proven in GDR-18 and GDR-19, but please feel free to add any relevant information as always.
This requirement is related to the following disputes:
The Arbitration Charter regulates the arbitration process. You can find it in Radicle project ID rad:git:hnrkrhnth6afcc6mnmtokbp4h9575fgrhzbay or at GIP-0009: Arbitration Charter - HackMD 3.
Hello Team , I am shocked to see slashing on my node. I have not done anything different and my indexer node setting did not change at all since beginning . My indexer agent was closing normally with no issues? What details do you need to take this further and help do corrective actions on my side ? I have also opened an indexer support case last week but no help received.
Could you help to check my system to understand what went wrong .Those allocations closed by the agent. Please let me know if I could get on a call or a meeting.
For the past six months, you have been closing this ENS subgraph with a failed status and the same POI (0xdf1d1d2a861bbc890ddac6650d500394a763ce87885bcf9f56550721aca0e47b). However, at one point, you closed it with 0x0(Allocation ID: 0xd57745b9559677eb4b5a38355c561d344c1e0fb2). Afterward, you reverted to closing it with the same POI again. Additionally, you closed another allocation (Allocation ID: 0xbc0ec2024d8ec731c9ec2ea9c3b304b424da0961) with the same failed status but a different POI (0xef31e8ea7ad1e53f467bddbb0ecf04bc7372486612d3603551aac2f18ab27daa). According to The Graph Explorer, your sync status shows as failed, and the Query Tool indicates your public POI has not advanced, suggesting you are still on the same block, yet your POI has changed. Could you explain this pattern? (Refer to Request for Information about Disputes GDR-18).
Is there a specific reason you allocate solely to the ENS subgraph instead of diversifying across multiple subgraphs, even those with better APR?
Do you regularly monitor your indexer’s status, subgraph sync status, or logs?
Your indexer has served zero queries since its creation. Could you clarify why this is the case?
First of all , I would like to apologize to all the indexing community and The Graph family.
I was not aware untill this morning that all these days my node was sending same POI’s from past few allocations. I would have corrected it if i know this earlier and also not being active in the forums.
0xdf1d1d2a861bbc890ddac6650d500394a763ce87885bcf9f56550721aca0e47b – This POI was auto sent by my Indexer agent when allocation was closed.
0xbc0ec2024d8ec731c9ec2ea9c3b304b424da0961 - This allocation was stuck in queue . I have tried restrating agent and later followed the below query and closed the allocation manullay.
Is there a specific reason you allocate solely to the ENS subgraph instead of diversifying across multiple subgraphs, even those with better APR?
– Earlier when checked few months ago this was one of the sub graph with high APR compared to others. I should have spent more time to do better reasearch and allocate more subgraph’s for better APR’s
Do you regularly monitor your indexer’s status, subgraph sync status, or logs?
– I used to do it regulary in the past but from past few months i missed to check regulary
Your indexer has served zero queries since its creation. Could you clarify why this is the case
– Node served some queries in the past with cost models but from past few months i am not seeing any queries.
Are you aware that your indexer has been failing to sync on the ENS subgraph since the very beginning?
Could you provide the current versions of your graph-node, indexer-service, and indexer-agent?
You mentioned that your node served some queries in the past. Were these on Ethereum or Arbitrum-One? (Your indexer history shows your first allocation was on September 18, 2023, on Arbitrum-One, but it reflects zero queries served to date.)
You mentioned that your node served some queries in the past. Were these on Ethereum or Arbitrum-One? (Your indexer history shows your first allocation was on September 18, 2023, on Arbitrum-One, but it reflects zero queries served to date.)
– Serverd in Ethereum but not very sure if node received any quesries after switching to Arbitrum-One
My sincere apologies, I am in state of shock knowing same POI’s were sent from agent and not realizing this earlier.
@crypto0243 thank you for the response. We appreciate all corrective measures being taken here. We can point you to channels and resources in the event you need feedback or help with operations from the community going forward. As a reminder, it’s the indexer’s job to ensure their indexing stack is running smoothly. It would be unfair towards the rest of the indexers if we were to waive this responsibility.
@InspectorPOI, thank you for your diligence here, as always.
Due to the duration and therefore extended risk of serving incorrect data to the network, in accordance with the Arbitration Charter, the arbitrators resolve to accept the dispute and slash the indexer.
Thanks for your response . I have already got impacted with significant slash to my self stake and lost so much of GRT on [GDR-18 and GDR-19} . I kindly request to help consider not slashing in GDR-21
Dear Arbitration Team, I currently have no further information to provide.
The disputed indexer has acknowledged the POI duplication mentioned earlier.
They are using an outdated software version, and it is recommended to upgrade to the latest release.
There have been additional allocations prior to dispute #18 with duplicate POIs being closed without being slashed, despite exceeding the epoch limit as outlined in the Arbitration Charter. It is reassuring that the disputed indexer is now aware of these issues; otherwise, this situation might have continued unchecked.
@crypto0243, while we understand the impact to your operations, it is important to be consistent in our expectations of operations across the network of indexers. It would be unfair to the rest of the indexing community if we were to dismiss this responsibility. The decision is based on the duration of this action and risk imposed by accepting this kind of behavior.
I would not request myself to dismiss if it’s one slash. Multiple slashes already happened earlier related to same POI /same subgraph and lost significant amount. I honestly not aware of the agent sending same POI else I could have done 0X0 to close the allocation and do necessary corrections on indexer node.
Dear all, as stated before the arbitrators resolved to accept the dispute and slash the indexer. The transaction hash will be shared shortly.
To the affected indexer we ask to review their setup to ensure their operation is running as expected and meeting the demands from the network. We recommend keeping the indexer components up to date and instrumenting some form of monitoring, whether automated or manual, to prevent situations like this one from happening again. If you have any questions or need guidance the indexing community can be very helpful, feel free to reach out on our forum or discord channels.
@InspectorPOI once again thank you for your input.