Web3 automation letters. Part 2: in the future, users won’t manually sign every on-chain transaction

Traditionally, users have always signed their transactions manually using their wallets. However, it looks like it will change.

In the future, users won’t manually sign every on-chain transaction

Blockchain is designed to provide self-custody to users and ensure that assets can be transferred solely by the owner’s decision without the involvement of third parties. These principles are Satoshi’s big idea behind blockchain creation and the core values of the web3.

The following questions arise:

1. How is it possible that users will not sign some transactions in the future?
2. Does it mean that some “third party” would have the right to execute transactions on behalf of a non-custodial wallet?
3. If that happens, wouldn’t that compromise the core web3 values?

This article is a follow-up to the previously published 40% automated transactions narrative.
It is devoted to discussing why users need it and how it should work to provide added value to users without compromising their self-custody and ownership rights.

Outsourcing the transaction signing

We named the process when someone (some automated tool or service) signs the transactions on behalf of a wallet owner as a ‘signing outsourcing.’ A few years ago, it could look strange. Still, with the evolving complexity of defi and the need to perform multiple automated actions as a primary way to use some protocols, it has become an essential tool for web3 usage.

Here is our brief analysis of ‘signing outsourcing’:

(1) There are specific use cases where it is much easier/efficient to outsource the signing of transactions instead of signing them by the user.

Examples: limit order execution, routine claim/compounding operations, automated lending and LP position management, and payments streaming.

(2) The “signing outsourcing” should be structured in the following way to add some value without significantly compromising the security and self-sovereignty of the user:

- Signing options should be limited to specific use cases manually pre-approved by the wallet owner.

- Transaction signing should be executed by a decentralized/trustless network of nodes, signing transactions whose scope is technically limited to the use cases pre-approved by the user. No trusted centralized third party should be involved.

The new approach to using blockchain networks

Previously, users directly interacted with the blockchain networks by manually signing transactions and sending them to mempools.

Now, users (sometimes without realizing it) outsource transaction signing to protocols that provide products based on automated actions under the hood. Protocols structure it as the products that they offer to users.

In the future, users will use on-chain automation directly together with a wide variety of fully automated protocols.

Users cannot handle transaction signing themselves, especially when it comes to transactions that require sequencing/bundling, checking execution conditions, and retrieving and tracking on-chain or off-chain data to do so.

The future widespread adoption of Account Abstraction will provide an option to outsource any operation to a decentralized party providing ‘signing outsourcing’ services.

The network of Keeper nodes is an example of such a service. Keeper nodes are servers with software executing users’ tasks for transaction signing and performing all additional operations necessary, such as on-chain/off-chain computations.

Signing outsourcing: Keeper networks vs. standalone bots

Users can run their centralized bots that execute transactions on their behalf. However, there are several reasons why it is much less secure than decentralized networks. The security and scaling are the main points here:

• Reliability. The network's reliability compared to the standalone centralized bot grows exponentially with the number of Keepers. The more Keepers operate, the less chance that the Job wouldn’t be executed.
• Security. For a standalone bot, all of its operations are compromised if any attack succeeds or failure happens. In contrast, in a decentralized network with many keepers and random job assignments, no one can predict which keeper will be chosen for which task. This makes the job of any external malicious actor incredibly complicated.
• Operation cost vs the economy of scale. The operation cost of running its own infrastructure (RPC, keeper bot, and ensuring its uptime) is high compared to the cost of using the shared infrastructure of a large keeper network. The superior cheapness of job maintenance is a natural consequence of the lax individual keeper requirements afforded by the effect of scale.
• Superior ease of onboarding. Suppose a protocol or user needs to automate operations. In that case, integration with a sufficiently developed keeper network will likely have the added benefit of exposing a codebase of standard jobs and conditionals that have already been checked & audited. This reduces the time and effort required to automate a given action (since most actions can be generalized to obey one of a small number of patterns; in fact, this is the basis for the resolver/interval job dichotomy in PowerAgent).
• Benefit afforded to the network at large. The local bots exist off-chain and do not contribute to the network's health and accessibility in any way. Large keeper networks that operate on-chain offer a natural way for any full-node runner to increase his income. It makes node-running more accessible and provides an additional income stream, benefiting independent node runners and the network.
• An ability to use additional shared security. This point can be illustrated by the ability of a large decentralized network to use solutions like the Eigenlayer to gain access to restaking of a chain’s native token, essentially theoretically obtaining a security pool equal to that of the chain itself and thereby bolstering the security of the solution.
• MEV protection. In some cases, outsourcing transaction signing can provide an additional value of MEV protection if Keeper network participants use MEV protection tools.

The way users interact with blockchain networks is evolving, and there are many reasons for this. Our vision is that the automated web3 and widespread adoption of ‘signing outsourcing’ will only be possible if there are proper tools — decentralized keeper networks.

In the next Web3 Automation Letters installment, we plan to dive deep into the mechanism design and economics requirements for a decentralized automated network focused on reliable “signing outsourcing” on the example of PowerAgent v2 developed by the PowerPool protocol.

Twitter | Discord | Telegram | CMC Community | Debank | Medium