Smart contracts don't execute themselves, Part 1
Background
PowerPool has been dealing with the problem of guaranteed on-chain transaction execution since the protocol launched in autumn of 2020. Ever since, we’ve been trying to perfect on-chain automation, together with other automation projects like Keeper.network and Gelato. PowerPool’s focus is especially on combining development of structured DeFi investment products with an enabling automation network we call the PowerAgent Network.
Our vision is that it is best to develop an open and trustless automation network like PowerAgent in open collaboration with current and future DeFi protocols, supporting a wide range of use cases, increasing the task load and the reliability of network operation.
This article and the articles that will follow are devoted to sharing our experiences over the last two years and the evolving design of a robust and decentralized on-chain automation solution.
Definitions
Agents, Keepers, and Relayers are autonomous agents executing transactions (conditionally calling smart contracts) with special software that interacts with a smart-contract network.
Introduction
Almost every DeFi protocol requires an ancillary Agent operating outside of the protocol to execute certain transactions, usually conditional transactions, triggered by on-chain events or time conditions. Ethereum and other EVM blockchains do not offer any method for these contingent actions to be done automatically at the appropriate times from inside any given smart contract.
DeFi 1.0 protocols developed on Ethereum were designed to be supplemented by pseudo-anonymous agents (known as Network Keepers). Such agents perform event-triggered actions such as liquidating under-collateralized positions in MakerDAO/Compound/AAVE or re-aligning ever-changing prices across AMM pools via arbitrage. Autonomous agents acting as Keepers were a way to make DeFi 1.0 primitives robust and decentralized. Permissionless actions of such Keepers are generally triggered by economic incentives (significant price differences, liquidation premiums, etc). Therefore, keeper-type agents typically extract a disproportionate value from the protocols and their users.
The evolution of DeFi 2.0 and beyond requires even more autonomous automation to perform routine on-chain tasks, but not necessarily motivated by such large incentives. We expect that going forward DeFi will demand broader, and less costly automation solutions, dramatically expanding the role of keeper-type agents towards becoming more generalized ‘Automation Agent Networks.’ PowerPool believes that automation networks will be critical to enabling the next generation of automated, multi-chain/layer, intelligent yield optimizing DeFi protocols.
Examples of key DeFi 2.0 protocols developing in line with this philosophy include:
- Uniswap v2: you could add liquidity without any mandate to manage a position.
- However, in Uniswap v3, you need to shift the position range according to market movement to increase the efficiency of capital usage and decrease Impermanent Loss risks.
- Balancer v1: AMM pools balanced by arbitrage agents
- However, Balancer v2: AMM pools with asset managers require automation for executing contract calls to perform operations with staked assets (harvesting yield and maintaining reserves)
- Yearn Finance offers automated management strategies to their users - increasingly capable vaults on top of Curve, Convex, and other protocols. Automated strategies involve harvesting, re-staking, and risk management actions.
Decentralized protocols become more complex on EMV-compliant chains, leading to the necessity of auxiliary automated agents to execute specific on-chain activity.
The growing complexity of the protocols and products being built on top of them highlights the necessity to understand automation and the limits of its application.
Part 1 focuses on the following questions:
- What types of transactions require on-chain automation?
- Do we really need automation networks, and if yes, in which particular cases?
- What are the principal approaches to designing robust and decentralized on-chain automation networks?
When is an automation network needed and when isn’t it needed? These are good questions. In most cases, an automation network is not necessary when somebody automates a personal fund management strategy; this is because that type of strategy can be accomplished by a simple bot launched on a centralized server owned by the user himself.
However, when it comes to maintaining and appropriately operating a decentralized protocol, using a centralized bot with a particular owner is a bad strategy; unfortunately, many protocols still use this approach since it is simple and allows the team to monitor and make decisions sure that everything works fine.
From our point of view, using centralized automation for decentralized protocols is like using a centralized bridge for transferring assets between blockchains. Centralized bridges are slowly but surely disappearing and being replaced by genuinely decentralized ones.
Types of transactions to be automated
There are primarily two types of transactions that can be classified by the nature of economic incentives needed to keep the protocol functioning:
Type 1: self-incentivized transactions such as collateral liquidations containing direct monetary incentives for the executor. This means that a transaction is attractive for permissionless execution since it results in certain profits;
Type 2: transactions that are not incentivized by design such as calculating TWAP prices or updating protocol parameters. This means the economic and technical nature of the transaction doesn’t offer any profit for the executor. However, we should note that it is technically possible to add some kind of profit for the execution of any transaction.
Pseudo-anonymous (permissionless) Keepers successfully automate the first type (self-incentivized) transactions since they can receive reimbursement for gas costs and profit due to the mechanics of the transaction. The second type of transaction is not profitable by design but could be made profitable by manually (synthetically) adding gas compensation + some profit that the executor receives.
However, in the case of permissionless execution, Keepers are monetarily incentivized but not obliged to execute transactions. They do this job voluntarily, having nothing at stake. But, what if the transaction should be executed under certain conditions and the absence of execution in proper time would lead to severe losses to the protocol? Or irregular execution leads to poor user experience and problems with protocol usage?
There are well-known examples of transactions that don’t require an automation network or that can easily be solved by a simple synthetic premium offered to anyone who will call a contract. However, there are many important existing examples where automation networks can improve efficiency:
- Automated collateralization ratio maintenance for CDPs and lending markets. For example, the losses in the case of a stETH de-peg could be decreased for looped stETH/ETH AAVE positions;
- Relayers: for example the Tornado.cash relayers service was sometimes unavailable, leading to a very poor user experience. This problem has existed since day one, according to TornadoCash founders. An automation network with guaranteed execution could solve this issue;
- Updating sensitive protocol parameters that should be updated with very narrow conditions, for example, automated capital allocations strategies that could require our proposed solution to exit a position ASAP in extreme conditions
- An example: how automation issues lead to protocol dysfunction https://twitter.com/LefterisJP/status/1525406362762608640
- Limit orders on DEXs
- Automated fund-management strategies such as Vaults/yield aggregation, which account for the major share of the Defi market
- Balancer v2 asset managers require automation to maintain asset reserves in the pool and transfer yield to pool LPs. Balancer v2 was released in Q2 2021, but there are still no v2 asset managers live. We are talking about the ‘classic’ idea of asset managers here, not about famous linear pools or similar implementations that also could be defined as v2 asset managers.
Using Balancer v2 (or similar forks) for AMMs with asset managers isn’t yet widely adopted, largely due to the lack of reliable on-chain automation solutions.
Automation is necessary when a task/transaction should be executed under narrow conditions, and when the cost of no execution is high. Note, the cost of no execution is not only quantified monetarily but also in terms of user problems, the brand's public image, etc.
The main takeaway from exploring these transaction landscapes is that there are different degrees of importance and risk of no execution. If we classify it from 0 (not important at all) to 10 (extremely important affecting a lot of users’ funds and the functionality of a big protocol), then these different degrees of importance and risk require unique incentives and penalty models. For highly important tasks, penalties should be severe and the rewards for executing these jobs should be very attractive.
In our opinion, task-specific and chain-specific automation is a key to creating a successful Keeper network that will balance the cost of execution and risks of no execution with task importance.
Decentralized automation networks are needed (even if centralizers say NO); the only question is the degree of this need.
This idea could be a cornerstone of automation keeper network design and we should keep it in mind as we discuss the general requirements for automation networks.
Design Requirements for on-chain automation networks
The architectural design of an automation network should ensure its fault tolerance while preserving the necessary level of decentralization. Below, we present a set of requirements for such networks:
The principal questions when designing an automation network are:
1. How transaction signers (Keepers) are selected for particular transactions that need to be signed. It’s a classical task of selecting N workers for M tasks.
2. What would happen to ensure that a transaction will be signed if the initially selected Keeper doesn't sign it on time; this is why the network needs to be robust.
3. Which economic conditions are required to keep the necessary amount of keepers working.
We found that existing algorithms for high-loaded distributed network systems (or N servers that need to process M requests on time) can be used as a reference for automation network modeling. The reason to apply loading algorithms is to create defined subgroups of Keepers that will automate particular tasks according to their importance and other execution conditions. The Keepers’ selection algorithms should also be applied to the tasks allocated to each subgroup.
In our next article, we will present our implementation of a generalized automation network or PowerAgent v2.
Conclusion
According to our experience and research, on-chain automation networks are one of the critical puzzle pieces for building efficient and robust DeFi protocols and strategies. Working on this problem for the last 2 years, PowerPool is building the PowerAgent automation network optimized for various classes of tasks differentiated by complexity, importance, and execution conditions.
Efficient automation requires case-specific automation. The network should be able to efficiently automate the various tasks with an optimal reward/penalty strategy and a keepers’ selection algorithm.
We plan to demonstrate the practical application of this approach by automating our own portfolio of structured DeFi products developed on top of major DeFi protocols, and by using progressively improved automation for our existing product operations.
On-chain automation challenges can be solved only by testing and cooperation with other Defi protocols. We plan to work closely with several partners to expand the PowerAgent network to other projects and Defi products. Only a deep understanding of cases and technical requirements for typical tasks can be a solid basis for optimal keepers’ subgroups creation.