Hi all,
As the fisherman in these disputes, I felt I should share evidence on why I have disputed the MinatoFund indexer.
Reasons for Disputes
- Incorrect POIs
- Malicious and unethical intentions
Part 1 - Incorrect POIs
POI comparisons per Allocation ID:
0x5037caea050b4dda604ef5efe908715e5cb71103
- POI actual:
0xb429cb40d26ffa8aec1f0ec31eb6bd5d97ccf0e6062559a4570a521c97a5caac - Provided:
0x82d3c31866310dceefbad6dd5e4c0721f32b7c16bd93ea16f89be91c870f4ff0
0x30740c34017407cc939e559b2bbe96b711e3d088
- POI actual:
0x5bdf4c32ef9498197f087e4c570a98eefa7a83de65818445434e311259939be2 - Provided:
0xc2d56a308c3560a511a0ca06ab4bf8d8f3c9891687c21980507e3a97c9ace7a6
0x0b089eeed8cf24c41f9e74cc750fc654eb5f0fc4
- POI actual:
0xa2a9fae6226689dbb9755a9cbeed0b8c274d68f48e4ad16c5866f0bd29048cdf - Provided:
0xb751485346603a1d165b822499aeb1bd2a5122542c5f40ae3720d666be18126c
0xd9036a08e37d0810451a2da60056c1cc935069e7
- POI actual:
0xe11d7fe5fc7b7d0701976c793336732c83bbb2ac9c4b5dfd5e8c2b071f478972 - Provided:
0xf9cb11c4cec2e710d80c8e1770a75b2a502c795c9b75b6836853738f3d26b6a2
0x73f3810a241d4966f18d0427d5244afec9f2ecf1
- POI actual:
0xd39937dea78486c35c1127cee227487d72ff6bfdadf93dd3c7c926241bef932f - Provided:
0x02911d0e46f521bc791524d6aa9d858db2d82688a7ffdecde3caac0ff8f53a38
0x347032a87c92a79f3eacbf2f4262dbb7eba5165d
- POI actual:
0xeeac889fb37dac0b0cc1ed25a157d60f3ecbca4856bf9d844720b7eab13c97c0 - Provided:
0x367e3cb4ab168ef8231ab1228a51cc6399bca1c17545515573a91b8ddd9cf532
0xac8773569201ffa1674072b877ce2ce627b5ed83
- POI actual:
0x00a4abb1b26ef2ce6ea7e1a9273de044698ed03aa3b82969f0e07a95be427b0a - Provided:
0x726c200d523918e2dfee10b3d2bf8178c9886960fb994b543acbb8968620136f
0x15380014b3313e172b363c707b8bb961110ecbb1
- POI actual:
0x3b66fde5a41e0a4fc8d6b4241c40c01d0b8cbc7f40fb05c816f9cf67e5642f4b - Provided:
0x8323030fba1dd60a4eba0af9bc9aafb385035a9d529348f7049a1ef4150ced42
The reasons for the POI discrepancies are due to the MinatoFund indexer either using the incorrect epoch block and block hashes to calculate the POI, or due to other various unknowns.
Part 2 - Malicious/Unethical Intentions
After digging deeper into the above discrepancies, I uncovered what appears to be a scheme of Creating, Publishing, Curating, Indexing, and Intentional Deterrence by the party in question, which ultimately led to filing these disputes.
It appears the MinatoFund indexer is involved in a scheme where they will create a bad subgraph, deploy it, curate to it, and allocate to it just before it fails. Based on their post above and on Discord, it is clear that the Indexer is exploiting the following which can be found in the HackMD document outlining the Arbitration Charter https://hackmd.io/MMHefHW5TxOOLtqqutP-VA?both#9-Valid-Proofs-of-Indexing-for-a-given-epoch:
An exception to this rule is if the allocation being closed was opened before the subgraph bug occurred. In this case, the Indexer may submit the last valid PoI they produced for the subgraph and collect indexing rewards for the allocation.
I believe the intentional creation of a soon-to-be-failed subgraph was acting maliciously by creating a barrier to entry for other indexers in order to seal a larger share of the pool for the MinatoFund indexer. As time went on and the barrier was proving to be successful, the curation on said subgraph also increased dramatically from the 2000s to the 18000+ range. One could also say the malicious party was also attempting to bait other indexers into closing without a 0x0 if they unknowingly found themselves on one of these failed subgraphs after the failed block passed.
The following table shows the specific subgraphs in question (Dummy Subgraphs 2 and 3) and how soon each subgraph fails from creation, allocated, etc in blocks:
| IPFS | Subgraph Failed at Block | Subgraph Created at Block | Indexer Allocated at Block | Subgraph Created to Failed (number of blocks) | Subgraph Created to Allocated (number of blocks) | Indexer Allocated to Failed (number of blocks) |
|---|---|---|---|---|---|---|
| QmYLnK6HwxTn3qPe2tURFUQYcxa4VVxLLvdbt6hVpBXmzd | 12855677 | 12849955 | 12849963 | 5722 | 8 | 5714 |
| QmbVGE6Ma2AqzVzKQip6S81dAiSuHeQLny47jzFTLa3DAq | 12860424 | 12856901 | 12856913 | 3523 | 12 | 3511 |
| QmQEGuJtXiwWni2bsmDDPPor9U1nfQ8s2kbQ6XYCwNjojG | 12862507 | 12862491 | 12862500 | 16 | 9 | 7 |
| QmUxkM4kkYDyVEcUcBGWrvhj5Y6f2uvUTkPTmPjtm76A6k | 12869144 | 12869077 | 12869137 | 67 | 60 | 7 |
| QmafMrc51kqWZdBF9u3XzerN2gYAb8wUPU7dHiHuxWewjK | 12876871 | 12876790 | 12876866 | 81 | 76 | 5 |
| QmVTUfdp5sJR4uNLq8jM1zR6TLyepejz9gd38YpNT9We5Q | 12876877 | 12876836 | 12876853 | 41 | 17 | 24 |
| QmUqXdxB5f9f6EuDPYcSEASCwUCQTBMU1LbsVntuQjamkc | 12883374 | 12883340 | 12883358 | 34 | 18 | 16 |
| QmZUrJSbDpVSGQemAnq2dHq4LyEXX7YQDvEm6vh2weoEej | 12946174 | 12946155 | 12946165 | 19 | 10 | 9 |
The table shows how the scheme was honed as time passed, especially given how quickly the last 6 subgraphs failed after launch and allocation.
I believe the entire party involved in the scheme to be that associated with the MinatoFund indexer or they themselves due to the above data and due to simple block explorer analysis. Here are the addresses involved:
Subgraph Publisher: 0x210c43953bad387654fb4c997ccc1609a6b1125e
MinatoFund Indexer Rewards Address: 0xf3d2BaE54313a3991b086D93576d953D0baE7241
Subgraph Curator (Funded by MinatoFund indexer rewards address): 0x520F7445286cC4140Be54e9FBfE8Aa80a2B3F60E
The curation pool on these subgraphs as they are deployed is funded by the MinatoFund indexer’s reward address.
Given the information provided along with providing invalid POIs, I believe this indexer to be acting dishonestly within the protocol and should be judged accordingly.