Okay, we would like to give some clarifications and explain why this thing happened.
Part 1
Actually, we are also not sure about why the POIs are incorrect. After faced the subgraph failure, we did the exactly the same steps shown below to retrieve POIs and close allocations manually.
Before generating the POIs, the node is synchronized to the last valid block. That part can be confirmed by comparing the dumped poi_table and entities with the reference.
Part 2
In our case, it seems like community members are more concerned with the motives and ethical standards of this behavior, rather than whether it complies with the Charter. We fully respect the opinions of the community, and hope that everyone can understand our experience and thoughts before drawing conclusions.
First, we will not deny that some of our actions in this case are not decent and inappropriate, but please do not assume that we are malicious at the beginning. We have been actively participating in the protocol all the time trying to interact with new feature and contributing to the community. After the new Graph explorer and subgraph studio launched, we immediately migrate the HOPR subgraph we made to enrich the ecosystem. When we tried to signal it, we realized there was a curator bot taking advantage of it. That was super annoying, and somehow discouraging legit curators to signal subgraphs. We deployed Dummy Subgraphs at that time to consume the bot’s token, and named Dummy to prevent new curators accidentally signal on them and lost just like other subgraph developers who created bot bait subgraphs.
Then, the evil parts came in, we did think that the exception rule can be used to create an exclusive environment just like described below.
We definitely didn’t think about baiting other indexers to index on the failed subgraph, or letting them do something wrong. Also, before seeing the replies this case, we thought our behavior was kind of in the gray zone, although it’s not decent, still under the exception case. Thus, we did not consider it as an malicious intention, and we had no plan to hide the relations between the publisher, indexer, and curator addresses. Just in case someone can DM us if they think that’s not cool.
Overall
We think the major issues are
- How to determine whether the indexer is abusing the exceptions or not in a clear definition? And which degree are we located.
This is still a very blur area for all of us. Apparently, there are some indexers indexing on failed subgraphs, and prepare to close allocation at the very last moment with the last valid PoI. How bad we are comparing with them, and how to judge the degree of abusing in a quantitative way, and give an appropriate slash.
- How malicious are we?
We did bad thing, that’s not deniable, and we apologize for that. We are absolutely willing to take punishes as warning. It also can prevent other indexers to do thing like that, so that is 100% necessary.
The question followed up is, are we purely malicious in this case? We think this case is still defining the boundary of the exception rule. Slashing for each allocation is really harsh for us. We can promise that we won’t do things in gray zone anymore, and sharing the potential risks we find with the community in time. Please give us a chance as the active participant.
Appendix
Failed Subgraph Trick Disclosure
Maybe some people have interests in how we control the subgraph failure, so we will reveal it, and the community can figure out the best way to prevent subgraph developrs do things like that.
The trick is quite straight forward, in the subgraph, we track token transfer count from a specific address to another, once we send couple of transactions, mapping.ts gonna throw an Error and fail the subgraph.