Curators Limitations Proposal

Research & Development Protocol Functionality
1

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.

Solutions

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.

Pros

  • 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.

Feedback
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?
2

Some developers can wait days for their subgraph to be ready but what if they are in a rush?*
I can’t edit for some reason :slight_smile:

3

So I definitely like the “freeze/thaw/unlock” concept, as I’ve seen it mentioned in a few discussions before. I myself had suggested a lock period that correlated Shares : Epochs. However, after much thought, I understand that part of the reason people choose to participate in Curation over Delegation is the flexibility of withdrawing their GRT at any point in time. I’ve tried to tell myself to think about this as if bots didn’t exist - I can’t imagine being a real, honest Curator stuck in that first spot, waiting to withdraw my profits & watching them dwindle away as other Curators (possibly :whale2:) pull their signals before me. I think a consistent, predetermined thaw period may cause a domino effect of back to back unsignalling, as well. The idea and intention sounds great, I’m just not sure if it can be managed in a way that offers protection & consistency.

As far as the 2 wallet idea - I would think about this more from a “Maximum Signal” limitation. We all know how easy it is to create additional wallets, so we must assume that people would use this workaround without hesitation. If the first “X” amount of signals were capped at let’s say 5k GRT, it could help to mitigate the risk of a bot/malicious users signal being withdrawn.

I’m with you 100% on not implementing anything that would create hesitation for early Curation. As you’ve mentioned in the Telegram chat, that early signal can be critically important for Subgraphs.

4

I think the reverse auction should indeed obsolesce the bot, and disagree that coding the bot to wait 10 days will provide any benefit to the bot owner. By 10 days in, any subgraph of import will already have sufficient signal, so the bot would have very little edge (if any) by that point. There’s no way to really optimize a bot to deal with a reverse auction because there is so much judgment involved–curation becomes much more of an art.

I didn’t go much further on this proposal because it lost me at the premise. However, I really appreciate that you took the time to give thought to the issue and propose a solution–no idea is a bad idea when you’re assessing options to solve a problem. Thanks Ahmad!

3 Likes