);
```
### Purpose of the Requirement
**This requirement is related to the following disputes:**
```auto
Dispute (0xbd7a4f1161630edbe505f8df605e4c60e73256687cf5de144f037da6ea614273)
├─ Type: Indexing
├─ Status: Undecided (2.45 days ago)
├─ Indexer: oraclegen (0x4fedde33607cfda2c82a999accb427d1170987d9)
├─ Fisherman: 0xb25813a23c3cb8852133416ba6adc30552880dc3
├─ SubgraphDeployment
│ └─ id: 0xe5dcb1e44a93ed102fc85a44fa43f9495ad2d0c9ec6146eaf03361d7477de640 (QmdowFoTBBCd5t6PXAtTVBPY5BFgJxMhCbN9gwuKT4REb9)
├─ Allocation
│ ├─ id: 0xdd7b735a064b2fcafa9bda6641bfcc965e639dfd
│ ├─ createdAtEpoch: 216
│ ├─ createdAtBlock: 0xe73e101fba5d9290d46edb381988b6c4c4e407507716237b90ec3631cceb160c
│ ├─ closedAtEpoch
│ │ ├─ id: 243
│ │ └─ startBlock: 0x7a8f423cc53b06e9ca8e7275ececad4a79b3bead291864a84358aca671aa3d48 (#13061746)
│ └─ closedAtBlock: 0xf3480247f823f5e363f74969caed8c1cdad6e0e4d57c95ba360ad84a5b25c53e (#13068107)
└─ POI
├─ submitted: 0x83f27fa1cecd3d074346288855c3abe85882cb7952b096484617f6b4ec78f13a
```
### About the Procedure
The Arbitration Charter regulates the arbitration process. You can find it in Radicle project ID rad:git:hnrkrhnth6afcc6mnmtokbp4h9575fgrhzbay
For communications, please use this forum. Additionally, please monitor _Graph Protocol’s Discord #arbitration_ ([https://discord.gg/9gg7XvfggW](https://discord.gg/9gg7XvfggW)) for any arbitrator reaching out for more information.
---
### Author:  [@86b](https://forum.thegraph.com/u/86b)
#### Post date: [August 27, 2021, 8:25am UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-9/2464/2 "2021-08-27T08:25:37Z")
Hi @ari ,
The following links include the requested information above:
- Graph Node version: `v0.23.1`
- ETH versions: Geth archival `v1.10.8` and OpenEth archival `v3.3.0-rc.7`
- Config info found [here](https://gist.github.com/86b/fbb58c328e9f9c3e1a94d1a846e7be5c)
- Table of POIs and call cache [zip](https://drive.google.com/file/d/1hgA-ny7pt6kGdn_a74U7jYCaBoSGjLkj/view?usp=sharing) download
Subgraph: `QmdowFoTBBCd5t6PXAtTVBPY5BFgJxMhCbN9gwuKT4REb9`
Block used for POI (Epoch-equivalent block): `10768876`
Hash: `0x27e40f55ad191b23cde6fdcb42a878ddf53285472968c7b357083c7494aef8ea`
POI: `0x83f27fa1cecd3d074346288855c3abe85882cb7952b096484617f6b4ec78f13a`
Last block prior to subgraph failure: `10773149`
Hash: `0xe1dba4b161ba614aded6309b726506738eb3cb60c4ca77a729fe06eaf36dbebe`
POI: `0x63a61a4bf6d11aee1028a0c12d2d9cdc64673a1b7ebc90f811f7726ade83250e`
**Part 1**
I’m assuming the reason for this dispute by FIsherman `0xb25813a23c3cb8852133416ba6adc30552880dc3` is related to clarity surrounding closing out an allocation with a non-zero POI on a broken subgraph, in this case the first version of the **Synthetix - Mainnet Mega** subgraph.
The allocation in question was opened by me on July 23rd at 19:17 UTC. Some days later Leo confirmed in the chats the subgraph was in fact broken with the Synthetix team on the 26th at 12:38 UTC. I was able to confirm the same about 2-3 days later. Fast forward to August 2nd and the subgraph was updated to the new and current version `QmZLFFChgZu6j4q8twaJn8xF74WgGgZ1WKEG6Cigesr49R` . After the subgraph was updated I decided to do research into what to do with regards to closing my allocation and was eventually informed of the Radicle updates regarding broken valid subgraphs and closed out my allocation on August 21st - 19 days after the old subgraph’s curation migrated to the new one, rendering my allocation rewardless for 19 days.
Just recently, Ariel confirmed that we are allowed to close allocations with a non-zero POI on a broken subgraph in a post on GDR-5 which can be found [here](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-5/2354/8) .
The Synthetix subgraph in question was:
- Valid
- Had many curators
- Was providing a service to the network
Due to the reasoning above, I do not believe I should be slashed for closing this allocation with a non-zero POI because I was acting in good faith, was within the rules, and fully synced the subgraph to the failed block and produced a good epoch-equivalent POI.
**Part 2**
While following the discussions here in similar disputes regarding Opyn, there was something that stood out to me particularly in [GDR-8](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-8/2380/9) where @Fattox mentions:
> There is quite a sensitive balance of power when it comes to disputes. The role of an Indexer involves attempting to cover every consideration that a Fisherman has, in order to avoid getting disputed, and then some. But the risk presented to the Fisherman is rather low compared to that presented by the stake of most Indexers.
>
> For this reason, i feel that Fishermen should be held to the absolute highest standard. Not only because of the `risk:reward` often being slanted in their favour, but because any invalid disputes present ‘noise’, and demand a lot of time and effort for the Indexer and the Arbitration Council. I feel without having high expectations of our Fisherman, we could attract opportunists.
The last part is spot-on in that many of these disputes the Fishermen themselves are playing pin-the-donkey with little to no expectation of taking a Loss, and in some cases aren’t even arguing their case, for example on [GDR-5](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-5/2354/15) which looks to have been ruled a Draw. This does in fact lead to the indexers’ time being consumed on top of the Charter’s where individuals in the Charter’s time is very valuable.
Naturally, I completely understand the reasoning behind declaring a Draw on things where there’s a miscommunication of rule updates and such, which is more than fair. However, this led me to do some digging after noticing that I was disputed for the same reasons as these Opyn-related disputes.
Interestingly enough after simple chain analysis, the Fisherman in this dispute is @inflex `decisionbasis-inflex 0x040a8ae130b5fbac973074aa1bd2c69773c5fbc2` and/or `decisionbasis-bestake 0x81dd719fd7efb19d12740b8057c0e363bee35b4a`. Here are the tying addresses:
inflex:
- origin: 0x040a8ae130b5fbac973074aa1bd2c69773c5fbc2 (inflex vesting)
- sent to: **0x2c452073377ec65b4b8c7dfa995624d60028cd53** (inflex rewards address)
- sent to: 0x673b6e9fe607f6ddf4a4f25b386b846c5c82995e (pre-migration fake sub publisher)
- sent to: **_0xde28fA99375CC746995061d872DC148b1F6b9121_** (Binance deposit address)
bestake:
- origin: 0x81dd719fd7efb19d12740b8057c0e363bee35b4a (bestake vesting)
- sent to: 0x09ccaA023d2B2dAF3C23273ABDdE64ceC3a01781 (withdraw surplus)
- funded by: **0x2c452073377ec65b4b8c7dfa995624d60028cd53** (inflex rewards address)
Fisherman:
- origin: 0xb25813a23c3cb8852133416ba6adc30552880dc3
- sent to: **_0xde28fA99375CC746995061d872DC148b1F6b9121_** (Binance deposit address)
You can see above how there are related addresses connecting the indexer(s) above to the Fisherman, most notably the Binance deposit address.
Ironically enough this person/group also submitted disputes against themselves for the following three indexer addresses with regards to Opyn:
`0x81dd719fd7efb19d12740b8057c0e363bee35b4a` - bestake
`0x63c560997b8338f2b033f3ffdcc0f7c680feec45` - inflex 2
`0x040a8ae130b5fbac973074aa1bd2c69773c5fbc2` - inflex 1
As was mentioned above via the quote from @ari regarding GDR-5, the Fisherman of that dispute (inflex) wasn’t found to be in the Loss column because it was assumed that the Fisherman was accidentally acting on outdated/unclear information when **clearly** based on @inflex’s defending argument in the dispute, he was fully aware of the current rules before that dispute was created, meaning the dispute _should_ be categorized as a Loss resulting in _his own_ recommendation of:
> please, rule the dispute in my favor, and take 10k from the slashing entities without return.
and from GDR-8:
> I think slashing person ought to be competent and be aware of the latest version of the charter. Thus, you shall be punished for your dispute and lose 10 grand.
Having said that and given the circumstances surrounding the Fisherman of my case being fully aware of the updated rules, I do think that they should have each of their 4 disputes ruled as a Loss instead of a Draw, as he himself personally recommended.
Lastly, I would like to hear from the Charter regarding disputing yourself. It’s clearly a bit iffy, but at the same time there’s truly no way to enforce it unless you have a situation like this above where the chain data can be easily connected. As for the “risk:reward” @Fattox mentioned, I’d imagine there will be discussions going forward about how to find a better balance between indexer and Fisherman risk.
---
### Author:  [@inflex](https://forum.thegraph.com/u/inflex)
#### Post date: [August 27, 2021, 9:02am UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-9/2464/3 "2021-08-27T09:02:59Z")
I would say we should differ between Opyn (GDR-5,6,8) and Synthetix (GDR-4,9) in terms of “broken subgraphs”.
Opyn became broken during the active indexing phase, on a new block. Subgraph had curators and was serving queries, a situation is clearly described by the arbitration charter.
Synthetix’s failure block is timed August 2020, even before The Graph protocol was launched. Opening an allocation towards such subgraph and using POI from almost a year ago doesn’t seem as straightforward as Opyn situation. According to the Charters, both recent version and outdated, POI shall be calculated for the first block of the epoch, which is impossible to determine. Also, I highly doubt you served any queries (some logs could be appreciated).
On the other hand, there are similarities between these two situations: presence of curation signal, and POI’s are not some bogus random numbers, but correctly generated taking failing block into account.
Eventually, it’s up to Arb’s Council to decide the outcome.
As for ruling the situation in a loss for fisherman, I would say that dispute tx was sent before Ariel ruled out GDR-5, thus the decision should be consistent in case of justification of indexer’s actions.
---
### Author:  [@ari](https://forum.thegraph.com/u/ari)
#### Post date: [September 2, 2021, 5:36pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-9/2464/4 "2021-09-02T17:36:05Z")
How is the epoch-equivalent block calculated to get to `10768876` ? I’m wondering because there were no epochs at that block. Are you calculating epoch slots from protocol genesis back?
```auto
Block used for POI (Epoch-equivalent block): `10768876`
Hash: `0x27e40f55ad191b23cde6fdcb42a878ddf53285472968c7b357083c7494aef8ea`
POI: `0x83f27fa1cecd3d074346288855c3abe85882cb7952b096484617f6b4ec78f13a`
```
---
### Author:  [@86b](https://forum.thegraph.com/u/86b)
#### Post date: [September 2, 2021, 6:15pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-9/2464/5 "2021-09-02T18:15:02Z")
Correct - counting backwards by 6646 blocks until arriving to the “epoch-equivalent” block prior to the failed block.
---
### Author:  [@86b](https://forum.thegraph.com/u/86b)
#### Post date: [December 22, 2022, 9:09pm UTC](https://forum.thegraph.com/t/request-for-information-about-disputes-gdr-9/2464/6 "2022-12-22T21:09:10Z")
**Previous Notes** :
Related to broken subgraph indexing related to the Opyn subgraph discussion, which was determined to be allowed.
Along with statute of limitations, this dispute has been settled as a draw by the Arbiters:
> **[Ethereum Transaction Hash (Txhash) Details | Etherscan](https://etherscan.io/tx/0x51dfbd174377be4b0d087c9058d2bca93aad186e6a8134250af82687aeb950c3)**
>
> Ethereum (ETH) detailed transaction info for txhash 0x51dfbd174377be4b0d087c9058d2bca93aad186e6a8134250af82687aeb950c3. The transaction status, block confirmation, gas fee, Ether (ETH), and token transfer are shown.