- Using Gelato v2, web3 developers can build “service” smart contracts that define certain transactions that Executors (bots in the Gelato Network) monitor and automatically execute on behalf of projects and their users.
- Gelato v2 enables a wide variety of operations ranging from limit orders to dollar-cost averaging to refinancing one’s debt position to avoid liquidation.
- Gelato acts as a single entry point for the execution of these transactions. The whole system coordinates a decentralized network of bots and ensures that those bots only charge fair market rate gas fees based on actual gas consumed and the Chainlink fast gas price.
- Bots are coordinated using “slots” and only execute transactions when it is their “turn” in order to avoid racing conditions while guaranteeing maximum efficiency.
When Gelato v1 was launched in July 2020, we had the goal to create a reliable and easy-to-use on-chain API allowing developers to automate their dapps by giving them access to a decentralized network of bots (called Executors) that can monitor and automate arbitrary smart contract functions on Ethereum. Developers no longer had to run and maintain their own bot infrastructure, rather they could just submit a task to Gelato and let the bots that comprise the network take care of the rest.
Our most recent collaboration with Instadapp highlights the beauty of our v1 system, empowering their users to give Gelato permission to execute transactions, such as refinancing debt positions from MakerDAO to Compound or Aave (Aavesome) if the debt position on Maker is close to liquidation. This transformed Instadapp’s system from having users manually interact with multiple protocols to empowering users to automatically transition between protocols based on predefined conditions like the price of ETH / $ while keeping their current proxy-based batched transaction system.
Shortcomings of Gelato v1
Web3 and in particular DeFi have in general experienced a massive boom since last summer. The increasing utilization of Ethereum for activities ranging from providing liquidity to farming led to a dramatic rise in gas prices, leading to many activities becoming uneconomical for the average user. Some of our initial assumptions, especially those hinging on lower gas prices turned out to be false and thus had to be addressed in a new version that aims to provide developers with more flexibility, fewer opinions, and more efficiency. Some of the shortcomings of our old version we had to address in our v2 included:
1. Gelato v1 was focused on users with proxy contracts
Gelato v1 was primarily built for Aggregators that utilize proxy smart contracts for their customers. The benefit here is that once Gelato is set up as an authority on the user's proxy wallet, they can start automating arbitrary transactions without having to whitelist multiple contracts to have permission to execute transactions on their behalf.
However, in recent times gas prices spiked to a level where it became uneconomical for new users to “invest” over $100 at the start of using an application solely to deploy their own proxy contract. Many other projects that relied on proxy contracts probably realized the same.
2. All data had to be computed on-chain
In the v1 we started with a strict approach of being 100% permissionless and trustless which means that anyone in the world could spin up a gelato bot, query the events emitted by the GelatoCore contract, and have all the information to a) identify when to execute transactions and b) execute them when profitable.
This meant that a lot of data had to be read on-chain at execution time making transactions more expensive than they otherwise needed to be if most of that data could be generated off-chain and simply passed to Ethereum via calldata.
3. ETH prepayments
Gelato v1 required users or someone on behalf of users to pre-deposit ETH in order to be able to pay for the execution of transactions. However, we discovered that most users simply just want to pay in the ERC-20 token that is transferred or swapped in a particular transaction, without the need to “lock up” funds beforehand.
To overcome these problems, we designed a new system that keeps the properties of being a) non-custodial, b) decentralized (multiple bots monitoring and executing transactions) and c) easy to create custom automated services. In addition, we wanted to ensure that the entire system was more gas efficient and that users could pay in the token that is most convenient to them.
Introducing Gelato v2: A more flexible, efficient, and reliable automation protocol
What’s New with Gelato Network V2?
1) Each dapp can define its own custom interface
Whereas Gelato v1 imposed a “one size fits all” way of having developers communicate with Executors, v2 is significantly more flexible and opens the possibilities for an infinite number of implementations of how that communication is happening. Developers still do not have to reinvent the wheel and only have to write minimal smart contract code, because we came up with several “Service Standards”, which compose a standard set of functions and modifiers developers can use to automate certain functions on their dapps. More standards, tailored to specific sets of use cases, will be released shortly.
2) No need for proxy contracts
Whether services that are powered by Gelato v2 require a proxy contract or not is completely up to the developers’ to decide. This is no longer a requirement and there are a number of use cases that are already in development that will save users significant gas costs down the line by not requiring a proxy contract per user.
3) Off-chain data generation resulting in significant gas savings
Executors can implement custom logic off-chain that enables them to compute arbitrary data and pass those to smart contracts services, which save a substantial amount of gas that was previously used to fetch certain data on-chain. This capability also opens the door to more interesting use cases like off-chain conditions where data is not available on-chain, but more on that soon!
4) No pre-deposits and pay for transactions with any token you want
Transactions pay for themselves as long as Gelato is paid an amount equal or higher to what it pays out to its network of executors. In practice, a transaction can hence swap e.g. DAI to USDC on Uniswap, and send part of that received USDC to Gelato to pay for the transaction fee and the rest to the user.
5) Ability to submit tasks via Meta transactions
One pain point of Gelato v1 was that tasks had to be submitted on-chain, which meant that before anything got executed, users already had to pay for some gas (even if not that much). V2 supports meta transactions which means that users only have to sign a message off-chain that will be passed to the “Gelato Service Relayer” from which Executors can query the available tasks in order to execute them. This part will be controlled and maintained by the Gelato Core team for now and will be decentralized in the near future.
6) Coordinating bots so they don’t front-run each other
The problem with all “keeper” systems today is that they use gas price auctions in order to decide which bot will end up executing transactions. This results in a significant loss in value that leaks to miners. In the Gelato Network, Executors are coordinated by a soft off-chain coordination mechanism that allocates “slots” to different Executor operators. In those slots, these Executors are the only ones who can execute the tasks of a particular service. If an executor goes offline or fails to serve a specific slot, it will be kicked from the network. In the future, staking and slashing will add even more incentives for executors to abide by the rules and keep a constant uptime for their servers.
We envision Gelato v2 as an ever-changing and improving networked service for developers that will constantly adapt in order to guarantee the automation of transactions in a reliable and efficient manner. Most of the security-related code was externalized into the service contracts and thus services can be assured that even if Gelato is maliciously taken over, their services are safe. For this reason, we choose to implement Gelato v2 using the Diamond Standard, otherwise known as EIP-2535. The upgradable protocol is secured by a multisig controlled by the Gelato Core development team, however, there are already concrete plans to transition this control over to the upcoming GelatoDAO, which will launch in Q2 this year.
We are working with the top teams in the DeFi space, including leading aggregators, wallets, and other projects, to outsource their time-consuming infrastructure development and maintenance requirements and enable them to offer users automated services without becoming the central point of failure — and without sleepless nights.
Several use cases we are actively exploring include limit orders, dollar-cost averaging for AMMs and aggregators, and “stop-loss” for LPs, which would allow LPs to eject from liquidity pools when impermanent loss becomes too great.
Furthermore, Gelato’s v2 was built to complement next-generation protocols like Uniswap v3, which leads to a lot of features open-ended for third parties to build out. For instance, Gelato can automate a variety of functions of Uniswap v3, including reinvesting fees back into the pool, converting LP NFTs into wrapped ERC-20s, and automating LP price ranges.
As demand for smart contracts automation increases in the DeFi ecosystem, there is an even greater need for a cost-efficient and more flexible off-chain solution. That is why we launch Gelato v2 to help and empower the developers to build unstoppable DeFi dapps.
Gelato Network is a protocol that automates smart contract executions on Ethereum. We are building the underlying infrastructure enabling reliable automation on top of Ethereum and with it a key part of the Web3 middleware stack, enabling trustless, automated flows of value between all smart contracts and upcoming Layer 2 networks.