Decentralization of Gelato Network and Coordination of Executors

Hi everyone,

I’ve been digging into the available resources I can find, but haven’t managed to find more in-depth explanations on

  • what criteria qualify the bot network as “decentralized”, and
  • how exactly the protocol coordinates executors / arrange slots.

It’d be great if someone can offer some insights or direct me to the relevant contents.

Gelato CMO (Chief Meme Officer)


Hey @btt,

Good questions! A bot network is “decentralized” if we have guarantees that if one bot crashes or is compromised, the other servers can continue to execute transactions on behalf of users, and the overall network will continue to operate with limited or zero disruption.

How does Gelato try to achieve this in practice today?

Basically at the moment there is a whitelist of who can be an executor and execute transactions on Gelato. You can find the whitelist on our diamond contract here. Go to the ExecFacet and check out the executors state variable.

This whitelist is currently controlled by the Core Dev team, i.e. it decides who can run these bots. In practice we and other parties we trust (which also run infra for other projects) run them. If a bot does not execute transactions at the right time, even though the transaction is in its slot, it will get kicked.

The control over this whitelist will soon be given to the GelatoDAO after the launch of the GEL token so that the Core Dev team is not solely responsible for maintaining the list anymore.

ConcurrentCanExecFacet handles the coordination of bots off-chain, which is done to help them not to collide in each others slots.

Why is there a whitelist you might ask? The answer is twofold:

  1. First, to avoid unnecessary Gas Price Auctions and bot operators racing each other in order to get certain transactions mined. There is really no point in having 100 Executors racing for the same set of transactions and marginalizing each others revenue. The added benefit of having 100 bots over 10 bots is really not that great. In order to ensure a network is resilient and reliable, having 10 highly reliable bots is worth much more than having 100 random ones.

  2. Secondly, having bots automatically execute transactions on your behalf in the future means that you provide those parties with quite a bit of “power”. Our aim is to design a system where transactions always get executed in the best interest of the end user, which often times is difficult to implement in a completely permissionless system because what constitutes a “good” transaction execution is a highly subjective topic. Bots should not frontrun or otherwise extract value maliciously from users. That’s why we think having a whitelist where these operators have some social reputation at stake is beneficial (at least initially), so that we know who they are and can hold them accountable if they actually do extract a lot value from users.

Having said all that, things will change fairly soon:

  • GelatoDAO will take over the whitelist control and decide who can run executors
  • Bots will require to stake GEL tokens in order to have economic stake in the system and not solely social reputation
  • New advancements such as Flashbots provide a different way of getting transactions mined which make Gas Price Auctions redundant. This means it becomes easier and more efficient to have multiple bots monitor and execute the same sort of transactions without risking collisions. We are already investigating how we can utilize these sort of mechanisms to make running Gelato bots even more permissionless.

Hope that answers your questions for now! Let me know if you want to dig deeper into some of these topics!

Also, if you have cool ideas you want to share of how we can make our network more decentralized and permissionless as time goes by, please do share them in here :slight_smile:


Great elaboration @hilmarx !

This certainly adds another layer of decentralization to the network in terms of the top level management of the Executors. My question is more aiming at how to minimize the risk of collusions among Executors, especially that the current design philosophy is “less and reliable beats more and random”.

At the moment the whitelisted Executors are “doxed” and bearing reputational cost for bad actions. I imagine that later anonymous operators may participate once there is more demand. If that’s the case, and also if it’s economically feasible for one entity to set up and operate multiple Executors, there may be a point where the DAO needs to come up with a mechanism that discourages collusions.

Based on the Whitepaper,
the more Transactions are being automated via the infrastructure services of Executors, the less they need to get paid per transaction, in order to cover their fixed infrastructure costs. Executors will justify the costs of running their infrastructure by the increase in Transaction quantity and not the rise of value captured by individuals’ Transactions.

Given the above, could you provide some examples how an Executor in the current network can still rip off users?


1 Like

Given the above, could you provide some examples how an Executor in the current network can still rip off users?

Bots that are eligible to execute a transaction at a certain block height could “censor” that transaction by e.g. waiting until a limit order, even though it could already be executed, moves more into a direction which makes front or back-running that transaction more profitable (not only by the bot itself, but by anyone).

Currently and in the short term future we are using a subjective decision making framework to monitor bots and determine whether they are actually doing this or not. If they are doing it, they get punished (slashed / kicked). Later on, such decision making framework can also be made more “objective” by submitting merkle proofs that prove that at past blocks those orders could have been executed.

However, as bots have no control over how transactions are actually mined and ordered in blocks (malicious miner could always censor that bot), we are starting out with a “light” and “subjective” process to punish these bot operators and later enforce more strict and objective rules.