Deploy & Signal - Solution to Curator Bot

Research & Development
1

While this has been mentioned while discussing other ideas on how to address the front running bot, I wanted to have a single place where we could present and push through the deploy & signal idea.

This has pretty consistent support from what I’ve seen. The concept is that as a subgraph developer or a DApp is publishing their subgraph, within the same transaction they can also signal to their subgraph (GNS).

From a developer position the benefits of this are:

  • It assists helps indexers immediately see that there is something to sync.

  • By maintaining a self-signal, your subgraph is never at risk of having 0 signal and being dropped by all indexers

  • You stand to earn a portion of your query fees back

  • If your subgraph produces query traffic others will signal and your share value will increase.

From a curator perspective:

  • The developer who made and published the subgraph likely deserves the 1:1 position.

  • A DApp is the least likely person to unsignal since they benefit the most of having a secure subgraph. In other words, if someone is going to signal before me they are the safest for me to signal after.

From a Graph development position

  • Since this utilizes two functions that are already built (mintNSignal and publishNewSubgraph) coding this should be much faster compared to other solutions that have been discussed.

While others address additional pain points, this one specifically addresses the front running bot.

The bots behavior:
Scanning a transaction that came from the bot we can see how it currently operates:

Specifically the below line we can see that he has a slippage parameter so that if his 3,500 transaction does not mint 55 shares, the transaction fails.

(delegate) GraphProxy[GNS.mintNSignal](_graphAccount=0xde910777c787903f78c89e7a0bf7f4c435cbb1fe, _subgraphNumber=1, _tokensIn=3500000000000000000000, _nSignalOutMin=55000000000000000000) => ()

This primarily occurs when gas is volatile. After setting his transaction, if another comes in with higher gas before his transaction is confirmed the bot’s transaction will no longer mint 55 shares and thus will not take a position on this subgraph (as occured with sushi mainnet exchange).

With deploy & signal, the bot will be prevented from entering anything that self signals more than 17 GRT with his current parameters. While there is still room for minor exploits the reason why this is the best initial defense is as the bot opens up his slippage tolerance, it can be exploited. Or it can be happy with the funds that it managed to gather thus far and look for a new project to attempt to exploit.

8 Likes
2

Derek has done his due diligence on this. His proposal provides security for all parties involved, and has received favorable support from the network’s participants - myself included. I have personally lost roughly 900 GRT since Curation began, mainly due to predatory manipulation of the current system.

Let’s make this happen folks.

3 Likes
3

Just writing to support Derek’s proposal to solve our bot problem. As a curator, I’ve lost share value because of a bot, and overall, bots are adding significant risk and chaos to the already risky and time-sensitive endeavor of curating. Would very much appreciate it if The Graph put this deploy & signal strategy into action.

1 Like
4

I support this solution, I see it as a solid approach to ridding the curator community of the bot exploit

5

Thanks for the hard work and thorough explanation! I support this also.

7

I give my full support. I’ve personally lost funds to the bot in Curve’s subgraph. Great idea.

8

I’m strongly in support of Deploy & Signal. I would suggest we put a limit on the self-signal, perhaps something in the 5-10k range. I believe that would still substantially address the bot exploit and also ensure curators still have an opportunity at a desirable entry point for newly-deployed subgraphs.

1 Like
9

Hello! I think the implementation of this is unlocked by the changes described by @ari in this thread: Batch GNS transactions

1 Like
10

I will link this post in Batch GNS transactions to provide visibility. Please provide any feedback directly to @ari 's GIP draft to consolidate responses there. Thank you!

1 Like