Three solutions have been proposed to solve the problem of the front-running bots but I don’t think they will solve the problem, because:
From a developer perspective, it is very easy for the bots to set a timer for 10 days when a new subgraph is deployed before signaling it, they will un-signal after us and still in a high % of profit. In fact, this will only give them some time to evaluate that subgraph and decide if they want to signal or not.
The Dynamic Curation Tax solution will raise up some problems while trying to solve what we already have, which are:
- Some subgraphs can wait days for their subgraph to be ready but what if they are in a rush? I personally know a subgraph needed to be deployed & indexed on the same launching day of their Dapp.
- That solution will also conflict with the Batch GNS transactions. The developers will lose 90%, 50% or any other % on the first day if they self-signal, then they will not self-signal and will wait for the 10 days to be passed. When they try to signal after the 10 days, the bot will be there before them.
I have some solutions and I want to share them with you:
2 per wallet
We can only allow the curator to signal on 2 subgraphs in 48 hours. For example, if 5 subgraphs are deployed in the last 2 days, I can only signal on 2 subgraphs and wait for another 48 hours to be able to signal on another subgraph.
This is not the PERFECT solution but will limit the bot activity. It will not be able to signal on every subgraph and the next solution will integrate with this one to limit its activity even more.
24 hours lock
When a new subgraph is deployed, anyone can signals it (even the bots), but no one can un-signal for the next 24 hours, till the “Judgment” has been made.
Now the Judgment is a system that will rank when you can unsignal:
- If you signaled in the first 1-10 min, your funds will be locked for 3 months.
- if you signaled in the next 10-60 min, your funds will be locked for 2 months.
And so on. If you signal after 24 hours then you will be able to unsignal whenever you want.
- This obviously will limit the bot activity a lot, prevent it from rug pulling, and make it stuck in the fake subgraphs for 3 months.
- The subgraph developer can be the first one to signal because he is the only one that 100% that his subgraph is legit.
- This will give us (Curators) 24 hours to check whether this subgraph is legit or not, check the code, etc… So no one will FOMO in anymore. NO one will signal a subgraph randomly without making sure it is legit and will generate query fees because they don’t want their funds to be locked for months in a fake/not-good subgraph.
I encourage you to publish your feedback on this approach below.
- Do you think this approach can help solve the challenges the curators are facing?
- What are some of the drawbacks you see with this approach?