It’s easy to forget how, not too long ago, web3 tooling felt like a time-intensive, debug-crazy endeavor. As the community grows, new solutions arise to solve the problems devs face when developing on blockchain. One such problem is the lack of auto-execute methods calls by smart contracts.

The awareness of automation has been increasing since 2015, with the first attempt being the Ethereum Alarm Clock project. However, it was the Defi explosion that made clear the imperative need to simplify the adoption of smart-contract automation.

A more in-depth explanation of the smart-contract automation genesis can be found at The DeFi Future is Automated blog by David Liebowitz. David presents the three main solutions:

• Gelato Ops by Gelato Network (production ready in July 2020)

• Keep3r Network (since October 2020)

• Keepers by Chainlink (open beta June 2021)

  
  

We are going to analyze these solutions and include the one provided by Open Zeppelin:

• Autotasks & Relayers, Defender by Open Zeppelin

  
  

Disclaimer: Although this analysis was commissioned by Gelato, all research was conducted independently and the conclusions are my own.

Setting the scene

When you participate in a hackathon and you want to integrate a protocol/solution to your project, you require four things

1) Resources: docs are your best friend- this includes everything from good online documentation to tutorials, and even covers responsiveness in Discord channels or other forums when you have technical questions or are simply looking for guidance.

2) Build & Test- for this experience to be optimal there are a few things to consider, such as:

• Whether you can create the task easily or if you have to first use additional resources that aren’t relevant to your task

• If you can find helpful templates or code snippets

• Whether the payment information is clearly displayed and easy to understand.

• If the solutions are deployed on different testnet

• If specific tokens are required, are faucets available?

• Can you test the full use case in a forked hardhat node or simply deploy it to testnet?

  
  

3) Features- the main question to consider here is not only whether the solution is providing the automation you need for your project (sometimes devs think that is finished when it is coded), but also other aspects that may influence scalability and user adoption when moving to production:

• Are there fees to be paid? If so, how much?
• Can the user pay with different tokens, and are alternative options for paying?
• Does the solution prevent ‘front running out of the box?
• Does the solution notify users when funds are running low?

One crucial aspect of the features is the solution’s ability to provide the executors/keepers in a decentralized manner. Though this isn’t relevant for the job itself, it can impact scalability when moving to production (after all, decentralization is sacred in web3)

4) Dashboard & UI:

• Is there a dashboard where you can track the logs of executions
• How can you track tasks/jobs created by a smart contract?

Showcase Projects

We are going to test the solutions mentioned above in two different use cases:

a) Maintenance Task Examples: Increase counter, a classic hello world smart contract automation example, increasing a counter when a specific time has elapsed (or condition is met).

b) On the Fly: One shot and cancel, dynamically create and cancel the task. As the ecosystem grows, I imagine we’ll see an explosion of different use cases where we’re required to control our tasks programmatically. We will implement this use case only in Gelato and Chainlink Upkeep.

The GitHub repo can be found here.

Gelato Network

How it works

First, users complete registration through the Gelato Ops UI. The UI is pretty intuitive and asks for the contract address and the function you want to automate, in case the contract is not verified, you will have to provide the abi.

We have three choices of triggers, time elapsed (run every n-time), whenever possible, and through a custom logic condition within a resolver contract (it can be the same as the execution contract).

Gelato offers the ability to (if needed) split the execution logic from the condition logic. This is done by creating a resolver contract, which comes in handy for automating tasks of already deployed contracts with custom logic.

Findings

Very clear and to-the-point documentation is available. However, more “target to learn” resources with specific features will speed up the development process.

There are testnets available, and development on a hardhat forked network is very easy, you just have to impersonate Gelato’s contract address.

One very powerful Gelato feature is the ability to have, programmatically, full control over the tasks, which gives users the ability to create/cancel tasks within a smart contract. Gelato Network provides decentralized execution through a whitelisted set of Node Operators and plans to have achieved full permissionless decentralization by mid-2023

For the time being Gelato Network doesn’t add any fee to the transaction cost. Gelato offers the possibility to deposit funds (like ChainLink or OZ Defender) but also the ability to pay independently for each transaction.

Gelato ensures privacy by submitting transactions through flashbots enabling front-running protection. It also provides users with a very simple interface to set up a Discord or Telegram notification bot for when users are running into low balance.

Gelato provides an intuitive UI dashboard for registering and controlling the execution of the tasks. You can find jobs by the connected wallet or “on the fly tasks” by searching the input contract address. The UI also provides the transaction logging to understand when a transaction reverts.

Showcase Contract Increase Counter:

Contract verified on MumbaiGelato Ops Ui with logs

Showcase Contract Create and Cancel Task:

Contract verified on MumbaiGelato Ops Ui with logs

The task has been created with the createTask() and was paused after one execution.

Keep3r network

How it works

At a first glance, Keep3r appears to be similar to Chainlink UpKeep or Gelato. The first step is to, register your job in the Keep3r Network UI, and then implement a specific interface in the contract defining the conditions and providing the execution logic

However, the similarities end here:

1. The way to pay the keepers/executors is very different from other solutions, as users pay the keepers with the yield accrued in a pool where the user provides liquidity.
2. In order for the keepers (Keep3r network provides decentralized execution) to pick up your job, users have to publish an npm package with specific scrips (there is a Keepers-Cli-Boilerplate that you have to fork and merge).

Findings

Although the developer experience is really tough, with almost no detailed docs/tutorials on how to implement a job, within the forum and discord, the Defi Wonderland Team provides excellent support (user wei3erhase supported my tests).

This solution is focused on maintenance/pre-programmed tasks. For very dynamic scenarios (although feasible) I don’t believe that the implementation of this solution is fit for purpose as the infrastructure of keep3r requires off-line manipulation.

Guided tutorials and “easy to find” test addresses would be beneficial.

The key feature of the Keep3r network is the implementation of the payment option by the yield accrued into a pool. This allows users to provide liquidity one time and doesn’t require any funds in the future.

Keep3r is a pure decentralized network and encourages every user to join. Though it may appear complicated at first, in the frame of this post, I’ve been able to understand the structure and how it works, and have simulated a task execution with the CLI (I could join the network as a Keeper)

Keep3r ensures privacy by submitting transactions through flashbots enabling front-running protection.

Keep3r Network could increase user adoption by improving the Ux experience with more documentation targeted to “no pro” developers.

Increase Counter:

Contract verified on goerliNpm Package with job

Chainlink Keepers

How it works

First, users will need to register an “Upkeep” (task/job) within the Chainlink Keepers Network in the keepers UI, and then connect their wallet.

We can define the time interval to trigger the Upkeep or specific custom logic with a condition, for this later case we are required to inherit the KeeperCompatible interface into our contract (it’s a very simple interface with two functions and the required addresses). Within the UI we will need the contract address and if it isn’t verified we will be prompted to input the method’s abi.

In order to finish the registration, you can input your email for notifications. You will be notified when funds are low.

Findings

The Chainlink ecosystem is also very well documented and there are a lot of resources, tutorials, and posts. However, it would be helpful if there were more documentation and tutorials for “on the fly” tasks.

Implementing recurrent automation is quite straightforward and easy to understand.

The fees on mainnet amount to 20%. As in other applications within Chainlink, you will need LINK to operate. More flexible payment methods would be beneficial.

Both testnets and faucets are available. If you want to develop locally with a forked network, although this is feasible (you will have to deploy it locally using a Chainlink node), it can be cumbersome if you haven’t done it before.

Chainlink Keepers have started to provide the ability to control the tasks programmatically. So far the functionality only allows users to create a task within a smart contract with specific custom logic. If a use case requires a time interval or only one run of the job, users will have to code it within the condition or execution logic. As developments occur very quickly in web3, I will have to review this post in the coming weeks to update the available features.

The way to set multiple Upkeeps to the same contract is by passing custom checkDataparam to the checkUpKeep(bytes checkData) and performData into performUpKeep(bytes performData), in very dynamic use cases this architecture doesn’t help devs like me to have cleaner code.

On the other hand, this architecture allows the offsetting of some gas-intensive calculations off-chain and only passing within the performData the required data for the performUpKeep() execution.

Gelato Network provides decentralized execution through a whitelisted set of Node Operators.

Chainlink provides a very intuitive dashboard UI for registering/controlling the execution of the tasks.

The dashboard shows the UpKeeps registered by the connected wallet. Moving forward it will help devs to implement a search functionality by contract address for “on the fly” created tasks.

ChainLink summary

Official feedback from Chainlink is still pending, therefore my comments and analysis may change in the future.

Showcase contract increase Counter:

Contract verified on MumbaiUpKeep UI & Logs

Create and Cancel Task:

Contract verified on RinkebyUpKeep UI & Logs

Open Zeppelin

How it works

Users need to register a relayer in charge of the execution and an autotask. Within the autotask, define the conditions under which the task has to be triggered (by time or webhook) and any custom logic needed to define the execution.

The relayer and autotask registration (shown below) are done through the defender UI where you’ll need to create an account (web2 email/password), the autotask can also be created, updated, or deleted through a POST API call.

Open Zeppelin Findings

Starting to learn and build with the Open Zeppelin is very rewarding, as guidance is concise, easy to understand and very well documented.

The proposed solution makes it very easy to create recurring tasks that are triggered every n- time.

One very interesting feature proposed by Open Zeppelin is the ability to trigger the autotask by a webhook, which fits very nicely with the sentinel ability to be notified when events on-chain happen.

Open Zeppelin does not allow “out of the box” to create and cancel a task on the fly from a smart contract. The minimum time between two triggers is one minute, a smaller interval can be achieved by a never-ending loop.

The solution does not provide a decentralized execution.

Open Zeppelin summary

Official feedback from Open Zeppelin is still pending, therefore comments and punctuations may change in the future.

Showcase contract Increase Counter:

Contract verified on MumbaiLogs screenshot (required login)

Summary

Averaging the different punctuations we could create the following representation:

To conclude, there is a healthy and performant automation ecosystem in web3.

All solutions provide the automation as expected, the overall numbers of automation transactions are increasing and communities are growing very quickly.

After my personal experience testing the four solutions, the above picture accurately represents my view of Gelato Network being one step ahead in UX.

It is important to mention that some of the solutions are under heavy development, and therefore some of the features and punctuations may change in the coming weeks and months

Thank you for reading!!

If you have questions or comments, please connect with me on twitter @donoso_eth

Resources

Gelato UI

Gelato docs

Gelato web

Keep3r Network Frontend

Keep3r docs

Keep3r Job Status

Chainlink Keepers UI

Chainlink Keepers docs

Chainlink Keepers web

Open Zeppelin Defender UI

Open Zeppelin Defender docs

Open Zeppelin Defender web

Showcase Contracts

Increase counter:

Gelato: Contract verified on Mumbai

Keep3r Network: Contract verified on goerli

Chainlink Keepers: Contract verified on Mumbai

Open Zeppelin Defender: Contract verified on Mumbai

Create and cancel task:

Gelato: Contract verified on Mumbai

Chainlink Keepers: Contract verified on Rinkeby

Github repo: link

Also Published Here