Executors

Staking as an executor

Executors are the decentralized network of entities that monitor the Registry for Requests that can be executed. Running an executor on each blockchain is independent from eachother because the StakeManager on each only coordinates executors for its corresponding Registry.

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

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 StakeManager of 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 StakeManager for 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.

Running a bot

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 Registry and load all the outstanding Requests into memory. It can do this in a maximally-decentralized way by looking at all HashedReqAdded events 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.