Curation Bots - 42069 and 1A2da

Yesterday, the issue of front running bots was brought up during Core Devs meeting #8.

Following the call, I received many messages regarding the bots. I believe there is some confusion as to how some of the bots operate. This morning, I looked into two infamous bots: 42069 and 1A2da. The reason I chose these two bots, is threefold: 1. They follow two different methods. 2. In total, they have a total P/L of ~ 400k GRT. 3. They are infamous in the community.

This is how the bots seem to operate:

Bot 42069

Method: Signals immediately after a subgraph is published. They stay in the subgraph, waiting for other Curators, before unsignalling.

Realized P/L : +258,100K GRT

Address : 0x42069e95e14312855bfbba3494915115970dfb88

Graphscan: Link


Example Curve
Using the following query to find nameSignalTransactions by this bot on the Curve Subgraph.

query MyQuery {
  nameSignalTransactions(where: {signer: "0x42069e95e14312855bfbba3494915115970dfb88", subgraph: "0x2382ab6c2099474cf424560a370ed1b1fdb65253-0"}) {
    blockNumber
    timestamp
    tokens
    type
  }
}

Timeline:

  • Block: 12812094

  • Block: 12812095

    • Less than 10 seconds later, the bot signals with 3.1k GRT. Etherscan Link
  • Block: 12813018

    • ~3,5 hours after the subgraph was published, the bot burns their curation shares for 52.9k GRT. The bot made 49.8k GRT in profit on this subgraph alone. Etherscan Link



SmartBot 1A2da

Method: Does not immediately signal on new PublishNewSubgraph. Instead it waits for a Curator to call MintNSignal on the new subgraph. The bot frontruns this transaction. They stay in the subgraph, sometimes days or weeks, before unsignalling.

Realized P/L : +126,400K GRT

Address : 0x1a2da6102a5a4bca8bfa4b57e3236c52b2bd1342 (This is a contract!) Etherscan

Graphscan: Link

Example 1 Sushi-MasterChef:

query MyQuery {
  nameSignalTransactions(where: {signer: "0x1a2da6102a5a4bca8bfa4b57e3236c52b2bd1342", subgraph: "0x4bb4c1b0745ef7b4642feeccd0740dec417ca0a0-1"}) {
    blockNumber
    timestamp
    tokens
    type
    id
    subgraph {
      id
    }
  }
}


Note: The bot’s transaction is not shown under Transactions on the GNS Proxy. But it can be found in Erc20 Token Txns and Event


Timeline:

  • Block 12872226

  • Block 12872228

    • Two Curators tries to signal. They use a Gasprice of 63.11 gwei and 35 gwei respectively. The bot sees this, and frontrun both of them. It sets a higher Gas Price (68,11 gwei - 5 higher than the former Curator). In a single transaction, it swaps 1897 USDC for 3500 GRT on Uniswap, and then uses the GRT to signal on the first subgraph. Etherscan Link
    • The first curator (63.11 gwei) had slippage protection set. The transaction reverted. Etherscan Link.
    • The second curator (35 gwei) did not activate slippage protection. They received ~2 curation shares, instead of the ~15,4 shares they expected. Etherscan Link
  • Block 12978233

    • ~16.7 days after the subgraph was published, the Bot burns their curation shares for 57,183 GRT. The bot made 53,683 GRT in profit on this subgraph alone. Etherscan Link
    • NOTE: The Bot burned curation shares on a total of 10 subgraph on this block, retrieving 129,067 GRT in total.



Example 2 - Eden Network

An example showing how the bot impacts subgraph developers. It also shows how the bot waits until another curator tries to signal, before frontrunning that transaction.

  • Block: 13128580
  • Block 13128617
    • 6 minutes later, A Curator (or bot) tries to signal on the subgraph. The bot frontruns this transaction. Just like last time: It sets a gasprice of 5 Gwei higher than the transaction(s) it is trying to frontrun. (This time 120.55 gwei → 125.55 gwei ). In a single transaction, the bot swap USDC for GRT and signals with 3500 GRT. Etherscan Link
    • The transaction of the other Curator failed due to slippage protection. Etherscan Link
  • Block 13128621
    • The Subgraph Developer themselves tried to signal on the subgraph. They used slippage protection, and their transaction failed at this block. Etherscan link.
  • Block 13128745
    • The Subgraph Developer signals on their own subgraph with 5000 GRT. They only receive ~32.6 curations shares versus ~69.8 had they been the first to signal. Etherscan Link.
  • Block 13332487
  • Block 13332488 —→
    • After the Bot rugged the developer, their shares fell in value. Current signal on the Subgraph is 1054 GRT. Only 1 indexer have allocated towards the subgraph, and it is not indexed. Graphscan Link



Example 3 - Eth Cryptovoxels Collections

Another example showing how the bot is waiting until another curator tries to signal, before frontrunning the transaction.

  • Block: 12865587

  • Block: 12865591

    • 2.5 Minutes later someone tries to signal. The bot frontruns this transaction. Etherscan Link
  • Block: 12865592

    • The curator that initially tried to signal has their transaction included in the next block. It fails due to slippage protection. Etherscan Link
  • Block: 12978233

    • The bot burns their curation shares, retrieving 8471 GRT. Etherscan Link
    • Note: This is the same block the bot burned their curation shares in Example 1 (as well as 8 more subgraphs)



  • Note: During the Core Devs meeting yesterday, I mentioned how one can look for two transactions on the same subgraph in the same block, as a possible way to identify the second type of bot. I got a second to think about it, and what I said would not work: The transaction from the “Honest” curator may be included and fail at a later block. It might also succeed, if they chose to curate without slippage protection.

  • Note: These bots, and all other bots with the same modus operandi, would be overlooked if we only look for mints and burns within a short time period.

  • Note: The block numbers are not telling us when the transactions were initiated. The block number only tells us when the transaction was included on-chain (finalized).

  • CC: @adamfuller @Brandon @Sam @Pedro




Useful Links

Mainnet Subgraph: Legacy Explorer Link

GNS Proxy: Etherscan Link

8 Likes

Nice detective work there, officer :sunglasses:

2 Likes

Great analysis and excellent technical storytelling! Thank you for capturing these examples.

2 Likes

I am thinking about something ?
Can we mint 2 type of share during curation ?
One share without bounding curve : fixed price ratio in grt. (ruin instant profit)
A second one with bounding curve : but only for the % of query fee redirected toward the curator ? (long terme reward for early curator), this token is burnt when the first one is burn.

1 Like

Hi, some sort of IPO period before release I read before somewhere seemed a good idea. A queue could be formed by buying a place. You could raise stakes to move up the queue, could also involve a commitment to a length of time in the contract v place in queue as well as GRT stake. Enjoyed reading your article. Thanks

1 Like

Very nice to see this laid out like this. Thank you!

1 Like