Executors are the decentralized network of entities that monitor the
Requests that can be executed. Running an executor on each blockchain is independent from eachother because the
StakeManageron each only coordinates executors for its corresponding
For example if 100 AUTO is staked on the Ethereum mainnet
StakeManager, and 150 AUTO is staked on the Avalanche
StakeManager, then when an executor stakes 50 AUTO on the Ethereum mainnet
StakeManager, they'll be able to execute on average 33.3% of all
Requests (since they'll have 50/150 AUTO staked), but 0% of all
Requests on the Avalanche
StakeManager. The executor could then also decide to stake on the Avalanche
StakeManager, but it wouldn't increase their % on the Ethereum mainnet
Once the AUTO token is launched on Ethereum, it'll be bridged to every other supported chain (EVM and non-EVM alike) with a chosen secure bridge, and the corresponding token that's minted on the receiving chain will be set as the canonical AUTO token for staking purposes on that chain. Therefore, the total supply of all tokens will be split across every chain. This allows for a dynamic staking market where stake naturally accumulates in the
StakeManagerof the chain that provides the most network revenue to the
Registry. If there are more fees on chain A than B, but the same amount of stake is in the
StakeManagerfor A and B, then rational executors would move some of their stake onto chain A because they can get a higher return per AUTO token staked - until the return per AUTO token staked equalizes on both sides.
Executors are free to either use the soon-to-be-provided bot code to run bots, or create their own, if they think they can optimize it better. Running a bot typically requires running a node and then the bot on the same server. Since a bot will have to locally simulate execution of 1000's of
Requests after every block, the latency involved in using a remote node means that this process takes too long, and the only scalable way to run an executor bot is on the same machine as the node to minimize latency.
Bots operate somewhat similar to nodes themselves, in the sense that when they start up, they have to 'sync' with the
Registryand load all the outstanding
Requests into memory. It can do this in a maximally-decentralized way by looking at all
HashedReqAddedevents in the
Registry, or by using a graph service like The Graph or Covalent. In either case, the executor has to choose how far back in time to go to fetch outstanding
Requests - the further they go, the more
Requests they'll gather and therefore the slower their bot will be.
Requests that haven't executed in a long time, such as a year, are statistically less likely to be executable in the near future compared to more recent new
Requests (and could well never be executable because of an error in creating the
Request, and therefore a prudent strategy would be to only look at
Requests opened in the past 30 days or so. The decision to increase that number will make the bot slower as discussed, but it could also lead to more revenue from old
Requests that do become executable in the future - especially if not all bots are looking further back in time, bots that do would have a chance greater than their stake % to get that revenue, therefore also increasing the proportion of revenue, too.