Introducing the Autonomous Keeper Service

Valory, the creator of Autonolas, the open-source stack for decentralized, autonomous agent-based applications, has launched the Autonomous Keeper Service (AKS) – a novel extension to the decentralized, permissionless task-based network: Keep3r Network. AKS can augment Keep3r Network’s decentralization, scalability, and transparency, extending it to more developers and use cases than ever before. The Keep3r Network connects blockchain developers who require jobs to be executed with keepers that can execute them. One of the key benefits is that Keep3r allows anyone to become a keeper (operator) in a fully permissionless manner.

Autonomous Keeper Service: Decentralized, Scalable, and Transparent

First, we outline how the Autonomous Keeper Service builds on the permissionless, decentralized nature of the Keep3r Network, increasing its job execution guarantees, scalability, and UX. Job owners can confidently rely on the dependable execution of their tasks, as a cooperative fault tolerance method is facilitated, making it easier for Keepers to earn.

1. Configurable Fault Tolerance

The fault tolerance of the Keep3r Network relies on there being sufficient people willing to run jobs, i.e. become operators in the Keep3r Network. The Keep3r Network v1/2 can provide no guarantees around job execution.

The Autonomous Keeper Service (AKS) is an autonomous service with a configurable number of (software) agents, that runs continuously and executes all jobs registered in it (see figure 1). Hence, jobs operated by the AKS inherit the fault tolerance assumptions of the AKS. Initially, we are running the AKS with 4 agents, meaning up to 1 agent can be faulty at any time. Over time, we intend to increase the number of agents in the AKS.

2. Cooperative vs Competitive Keepers

One of the primary advantages of the Autonomous Keeper Service is a new model of keeper cooperation. The AKS consists of a multi-agent system controlled by multiple operators, each operating one or multiple agents in the AKS, that are collectively maintaining the service. Jobs are executed by the service as a whole and rewards are accumulated at the service level. Operators of agent instances are rewarded for their gas spend as well as a premium. This means, operators avoid so called gas wars in which they drive up gas prices when competing against each other.

3. Better UX

The AKS improves the UX for both job owners and keepers. Job owners do not have to hope for keepers to pick up their job or go as far as implementing sample keeper bots for their jobs. Job owners can simply create a contract package in Python (see an example here) that is compatible with the AKS i.e. it provides the off-chain logic to check for job readiness and prepares the job (work) transaction. Keepers have a lower barrier to entry. They can simply become an operator in the existing AKS, without having to do any coding, or fork the AKS and set up their own. This means we lower the high level of technical expertise required to become a Keeper and further democratize and decentralize the network.

4. Transparency: AKS code is publicly accessible

The Autonomous Keeper Service also increases transparency for the network since all its code is publicly accessible and the Autonolas stack guarantees that the running AKS uses this code.

Architectural details

Autonomous services that use Autonolas technology are implemented as Finite State Machines where transitions between rounds (states) occur based on consensus among the agents about the outcome of the previous round. During each round the agent performs an associated type of behaviour, such as requesting data, performing computation on data from a previous round, or submitting a transaction on-chain.

Rounds

• PathSelectionRound: This is a decision-making round in which the agents decide what path to take based on their current state.
• ApproveBondRound: This round is responsible for approving the bond used in the following round.
• BondingRound: The bond for the keeper is predefined as a service parameter. In an MVP we may assume it is zero, and work only these jobs. In a more sophisticated setup one might want to manage this dynamically, based on job availability and earnings accrued.
• WaitingRound: A round used for simply waiting when a keeper is not ready to activate yet. This is only used when a fresh AKS is deployed.
• ActivationRound: Activating as a keeper after the bonding period has passed.
• GetJobsRound: Retrieving the latest joblist and selecting one that is workable.
• PerformWorkRound: For a MVP we assume that performing a job only requires a call to .work(). The final transaction will be submitted in the form of a Gnosis Safe multisig transaction. Rewards are given in bonded keeper. A rebalancing (e.g. to refill gas) may be considered at a later stage.
• AwaitTopUpRound: If we run out of funds, we enter a sleeper state. We can check the balance periodically and restart when refunded. Costs are reimbursed on successful completion of work, however we might not complete a job, waste gas, and run out.

Fig. 1: The Autonomous Keeper Service (AKS) runs off-chain. The Job Registry (https://github.com/valory-xyz/contracts-aks) is a custom contract and conceptually part of the AKS. The AKS owner, a smart contract, is initially owned by Valory but later the Autonolas DAO or Keeper DAO can whitelist the jobs which the AKS is working at any time. Whitelisting is essential as jobs could be malicious and aim to exploit the AKS.

What are the key roles of an Autonomous Keeper Service?

• Service developer: implements the rounds and its business logic, API integrations, FSM chainings, chain integrations and any other capability needed for the service to run.
• Agent: single instance of the service logic that runs the rounds.
• Agent operator: runs one or more agent instances as specified by the service owner. Updates to new versions when required by the service.
• Service owner: ultimate responsible for the service. Decides the service needs, the number of agents and operators and registers the service in the Autonolas protocol.

Conclusion

In conclusion, the Autonomous Keeper Service is adding value to the Keep3r Network today, providing numerous benefits for job owners, operators, and the network as a whole. Its emphasis on cooperation over competition, simplified Keeper experience, transparent implementation, and configurable fault tolerance, meaning it can help the network serve an increasing number of protocols and users.

Learn more

• Check out the live Autonomous Keeper Service here
• Sign up to operate the Autonomous Keeper service via Propel here
• Learn more about building your own autonomous services independently here
• Explore the Autonomous Keeper Service’s live metrics on Dune here