# Request for information about disputes #GDR-22 **URL:** \ **Category:** Arbitration\ **Created:** [December 12, 2024, 12:54pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278 "2024-12-12T12:54:26Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\ **Post date:** [December 12, 2024, 12:54pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/1 "2024-12-12T12:54:26Z")
The Arbitrators are contacting Indexer address `0xc55c63563efb36f7cc65ac3060c52987c6694b37` (figment-prime.eth) and fisherman `0x1ed0c56b75838e9788ae83b26d80c0c3a353e249` about a new Dispute filed in the protocol. Dispute ID: `0xb84b53f398c075fbb8e0e400e1566ef190cc4459873fd4daf3e5c1d776d12957` Subgraph deployment ID: `QmdjrDs1WFACepLYwCUyMBX9qVR1zdAcjhse3HbkKJtZGM` To the fisherman, could you share the 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). ### Purpose of the Requirement This requirement is related to the following dispute: ```auto Dispute (0xb84b53f398c075fbb8e0e400e1566ef190cc4459873fd4daf3e5c1d776d12957) ├─ Type: Indexing ├─ Status: Undecided (0.39 days ago) [48 epochs left to resolve] ├─ Indexer: 0xc55c63563efb36f7cc65ac3060c52987c6694b37 ├─ Fisherman: 0x1ed0c56b75838e9788ae83b26d80c0c3a353e249 ├─ SubgraphDeployment │ └─ id: 0xe4d0ae2ad8fb04b5e42c7ba094279eecffbb88aa74be7e0d29fe853453835b02 (QmdjrDs1WFACepLYwCUyMBX9qVR1zdAcjhse3HbkKJtZGM) ├─ Economics │ ├─ indexerSlashableStake: 233058.265378413026540301 GRT │ └─ indexingRewardsCollected: 425.075584789261886214 GRT ├─ Allocation │ ├─ id: 0x13722734f9ef698b1a4774922ecd16cde778ca7b │ ├─ createdAtEpoch: 732 │ ├─ createdAtBlock: 0xaa6e3639fa7fbfaba6adf8a7b34183c52d23643d7e754853ac50cced9d783bfa │ ├─ closedAtEpoch │ │ ├─ id: 736 │ │ └─ startBlock: 0x461e9cfd509911337d62189f5be7d36a9db1e8b1699e8a556ff16ef940c95c62 (#21324737) │ └─ closedAtBlock: 0xf2bbd96e5dd2d3ebff802186be2539c098c67a68928db55ab599da9ff70ffb54 (#21330821) └─ POI ├─ submitted: 0xa3da80a275bf91366181a60c6763835070c914fc171e09e54234c3303c572729 ├─ match: Not-Found ├─ previousEpochPOI: Not-Found └─ lastEpochPOI: Not-Found ``` 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](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0009-arbitration-charter.md). For communications, please use this forum. ---
**Author:** ![daviesthomas](https://avatars.discourse-cdn.com/v4/letter/d/9f8e36/32.png) [@daviesthomas](https://forum.thegraph.com/u/daviesthomas)\ **Post date:** [December 13, 2024, 3:02pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/2 "2024-12-13T15:02:55Z")
Thank you @tmigone. This dispute is about POI `0xa3da80a275bf91366181a60c6763835070c914fc171e09e54234c3303c572729` having been used for a third time on a healthy subgraph. This can be verified with this query on the [Graph Network Arbitrum subgraph](https://thegraph.com/explorer/subgraphs/DZz4kDTdmzWLWsV373w2bSmoar3umKKH9y82SUKr5qmp?view=Query&chain=arbitrum-one): ```auto { allocations(where:{poi: "0xa3da80a275bf91366181a60c6763835070c914fc171e09e54234c3303c572729"}){ poi indexer{ id } closedAt } } ``` The subgraph state is healthy, and other indexers active on the subgraph have correctly submitted non-duplicate POIs on this healthy subgraph during the same timeframe: ![image](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/2X/3/336ef161cc1dca332238da1b8b2bdb5c008f91a6.jpeg) Could the indexer please provide information as to why the POI was used repeatedly during the time period from November 24 to December 4? ---
**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\ **Post date:** [December 13, 2024, 4:05pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/3 "2024-12-13T16:05:32Z")
Once again, thank you for the detailed report. We’ll wait for the indexer to respond before next steps. ---
**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\ **Post date:** [December 17, 2024, 4:47pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/4 "2024-12-17T16:47:18Z")
Noting that the indexer has contacted me privately, they are waiting for their forum account to be activated before they can join the conversation here. ---
**Author:** ![ThomasBonnin](https://avatars.discourse-cdn.com/v4/letter/t/b38774/32.png) [@ThomasBonnin](https://forum.thegraph.com/u/ThomasBonnin)\ **Post date:** [December 17, 2024, 5:40pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/5 "2024-12-17T17:40:43Z")
Hi there, My name is Thomas Bonnin and I represent the indexer in this dispute. We have been called out on an issue affecting our allocation process on TheGraph network, which resulted in repeated submissions of the same Proof of Indexing. We understand this is exposing us to potential disputes and penalties within the community. The root cause stems from a combination of automated process failures and temporarily muted monitoring systems. Upon discovery, we immediately initiated corrective actions and are actively working to resolve the situation. Our current focus includes manually addressing allocations to prevent further issues, restoring monitoring systems, and improving our automation processes to ensure this does not happen again. We take this matter seriously and remain committed to maintaining trust and reliability within TheGraph ecosystem. Further updates will be shared as we progress toward full resolution. ---
**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\ **Post date:** [December 18, 2024, 12:52pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/6 "2024-12-18T12:52:12Z")
Hi @ThomasBonnin, > The root cause stems from a combination of automated process failures and temporarily muted monitoring systems. Upon discovery, we immediately initiated corrective actions and are actively working to resolve the situation. Can you expand a bit on this? It would be helpful if you described what your automated processes look like and how it led to POIs being reused. Are you using the indexer-agent to close allocations? ---
**Author:** ![ThomasBonnin](https://avatars.discourse-cdn.com/v4/letter/t/b38774/32.png) [@ThomasBonnin](https://forum.thegraph.com/u/ThomasBonnin)\ **Post date:** [December 18, 2024, 4:16pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/7 "2024-12-18T16:16:40Z")
Hi @tmigone I can confirm that we are using the indexer-agent to close allocations and that it was operational. For the automation script, I will focus my answer on the faulty part we identified. We encountered a problem automatically closing allocations with a 0x0 POI for subgraphs that failed to fully synchronize on our side (IE67 error) The automation tries to force close them which resulted in a loop of error. Now, based on our analysis of the different timestamps (automation changes, automation run, and faulty POI being reused), our understanding is that this would be the cause of the issue. Somehow the automation went through without processing those IE67s and stuck queue actions and that eventually resulted in the faulty behaviour ---
**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\ **Post date:** [December 20, 2024, 8:19pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/8 "2024-12-20T20:19:14Z")
Thank you @ThomasBonnin. I still struggle to understand the details here. IE67 error means you either fully sync and provide a valid POI or you force close with 0x00. What appears to have happened here is a force closure but using a non zero POI, was that what your automation script was doing? Any chance you can share that code snippet? ---
**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\ **Post date:** [January 3, 2025, 6:29pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/9 "2025-01-03T18:29:57Z")
Hey @ThomasBonnin can you please see my previous post? Thanks! ---
**Author:** ![ThomasBonnin](https://avatars.discourse-cdn.com/v4/letter/t/b38774/32.png) [@ThomasBonnin](https://forum.thegraph.com/u/ThomasBonnin)\ **Post date:** [January 6, 2025, 10:06am UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/10 "2025-01-06T10:06:18Z")
Hi @tmigone Sorry I was unavailable the last 2 weeks and just came back today. It’s difficult for me to share exact content of the code, but basically, we’re building the list of IE67s by force closing allocations. We use different commands that generate json that we then parse: ```auto graph-indexer indexer allocations get --status active --network {network} --output json ``` and ```auto graph-indexer indexer actions get --first {last_count} --network {network} --output json ``` then we check the failure reason ```auto if action["failureReason"] == "IE067" ``` then for each of the identified ie67 (i) we run the follwoing ```auto graph-indexer indexer actions queue unallocate {i['deploymentID']} {i['allocationID']} 0x0 true --network {network} --output json ``` We also browse the stucked ones (s) and run the same command then we approve then cancel the stuck ones ```auto graph-indexer indexer actions approve {unalloc_id} graph-indexer indexer actions cancel {s['id']}") # cancel the stuck allocation ID ``` and then we approve and delete the ie67s (i) ```auto graph-indexer indexer actions approve {i} graph-indexer indexer actions delete {i} ``` I hope that helps enough. ---
**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\ **Post date:** [January 6, 2025, 6:09pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/11 "2025-01-06T18:09:05Z")
Are there any logs you can share covering the allocation closures? ---
**Author:** ![ThomasBonnin](https://avatars.discourse-cdn.com/v4/letter/t/b38774/32.png) [@ThomasBonnin](https://forum.thegraph.com/u/ThomasBonnin)\ **Post date:** [January 10, 2025, 3:27pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/12 "2025-01-10T15:27:41Z")
Hi @tmigone I checked with the team and unfortunately we don’t have any logs for this. The script we were using was pretty recent as I mentioned above. The only logging system that was in place when the issue happened was a print to the console and it was lost once the Docker container was restarted ---
**Author:** ![absolutelyNot](https://avatars.discourse-cdn.com/v4/letter/a/5f8ce5/32.png) [@absolutelyNot](https://forum.thegraph.com/u/absolutelyNot)\ **Post date:** [January 13, 2025, 11:15pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/13 "2025-01-13T23:15:06Z")
@ThomasBonnin, we recognize that the closure was likely unintentional and appreciate your efforts in addressing the situation. However, in light of the terms outlined in the charter and the absence of conclusive data to support a draw, **the Arbitrators have decided to proceed with the slash.** Given that indexer-agent won’t continue with an unallocate action if it fails to fetch a POI (unless the user skips past that by specifying a POI value and using the --force flag to skip any checks to confirm it’s the correct value), this situation could only happen due to an issue with manual allocation handling, thus the responsibility of this falls entirely on the Indexer executing said procedure. The decision to carry out manual allocation closing brings the risk of slashing if not executed correctly. If you wish to proceed with such actions in the future, please do so with extreme care and maintain thorough records for accountability and transparency. We would like to additionally note that software bugs on any external piece of software are not afforded any leeway in these scenarios, as they are considered manual intervention. Avoiding slashing in such a scenario would require explicit proof of adherence to official guidelines to demonstrate that the issue was derived from the guidelines and not the software created by the operator. ---
**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\ **Post date:** [January 21, 2025, 2:49pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-22/6278/14 "2025-01-21T14:49:58Z")
Dispute has been accepted with txHash: [Arbitrum One Transaction Hash (Txhash) Details | Arbitrum One](https://arbiscan.io/tx/0x402b2c1e1b69553eb13b5ca9e33c8cccac004468a513e9e15b5c8a3cb7f52e97)