CHIPs discussion phase: Intent-centric Automation Cosmos SDK module on Cosmos Hub

Hub Proposals CHIPs
1

:bulb: Intent-centric Automation Cosmos SDK module on Cosmos Hub: Enabling orchestration of Interchain actions and more :sparkles:

Greetings Cosmos Hub Community!

We’re excited to introduce the Intent-centric Automation (IA) Cosmos SDK module. The IA module enables condition-based automation of Cosmos messages on connected IBC chains. This module allows for coordination and orchestration of interchain actions in an effective, permissionless and trust-minimized manner.

We have been researching and developing automation logic in Cosmos SDK module code since 2021. We are currently developing our automation module to become a generalized framework for handling all kinds of intent-centric blockchain actions. We want to get the community’s perspective on the idea of launching the IA module on the Cosmos Hub. Therefore we encourage you to bring up your thoughts, feedback and any questions you may have.

What is intent-centric automation?

Our definition of intent-centric automation is a combination of an intent: a clearly formulated or planned purpose and automation: an automatically controlled operation. In crypto, we want to perform such actions with no counterparty risk and in a permissionless and decentralized manner.

Goals

The goals of adding the IA module to the Cosmos Hub are to enable intent-centric triggers for blockchain calls, enable interchain coordination directly on the Cosmos Hub and drive ATOM value.

Use Cases

The module offers advanced features like chain-agnostic and interdependent intent triggers, allowing for scheduled actions in the future. In the IA module, a trigger has its own generated “trigger account address”, which can be granted execution rights, allowing a stronger kind of automation. This means that protocols and their end-users can automate complex workflows without locking tokens into an Escrow or Vault account.

We identify the following use cases that are unlocked by the IA module:

Use cases
Scheduled payments Portfolio management
Subscriptions Auto-rebalancing indexes
Swap streaming Time-based trading strategies
Automated payroll services Auto-reinvest after un-bonding
Scheduling governance proposals Auto-compound on any validator
Lotteries and time-based rewards

The IA module enables actions to be conditional, whereby the actions can depend on execution results. For example, a protocol user could set up a sequence of actions such as swapping ATOM for USDC on Osmosis and then paying for a subscription that is settled on Ethereum using the Axelar bridge with General Message Passing. The IA module unlocks these use cases natively in a Cosmos SDK module, abstracting smart contract logic. This mitigates smart contract risks and saves computational resources. Hence, protocols and end-users can automate complex workflows in a seamless manner.

Example Use Cases

  • Wallets like Keplr and Leap could integrate into the IA module to allow for scheduling payment. Thus allowing the wallets to become similar in functionality as banking applications in traditional finance.
  • Staking protocols like Lido, Swell, and EigenLayer could integrate into the IA module for automated token restaking, yielding additional returns. Auto-compounding, traditionally managed by external Vault and Escrow smart contracts, is decentralized and trustless when outsourced to the IA module. Stride, a Cosmos liquid staking Appchain, incorporates auto-compounding through a time-based function. EVM-based staking protocols can now achieve reliable and predictable auto compounding of staked assets, enhancing network security and user confidence.
  • Cosmos Hub Atom Alignment Treasury (AAT) presents a novel use case, allowing governance to execute portfolio management logic such as daily ATOM-to-TOKEN swaps to ensure a constant 10% TOKEN portfolio allocation in the AAT. The IA module offers a generic and trustless approach, making it an easy-to-integrate and complementary solution for automating the AAT. The IA module allows any account, including an AAT account, to create and update triggers. AuthZ grants can be used to perform trustless automated actions for the AAT account, eliminating the need for external smart contracts for performing automation logic. The IA module can also be used for swap streaming to mitigate price impact on DEXes. In this case, the AAT module can act as an agent that expresses trigger conditions, and the IA module can then execute these triggers.
  • Large digital asset issuers like Circle could optimize liquidity across ecosystems by integrating the IA module. Scheduled token burning on one chain can trigger automatic minting on another chain and vice versa. This reduces smart contract and counterparty risks in a trust-minimized manner.
  • DEXs like Uniswap could enhance reliability by integrating the IA module for auto-rebalancing, DCA swaps and for processing limit orders. Auto rebalancing of Concentrated LP tokens minimizes impermanent loss, improving overall liquidity and protocol stability. A trigger with granted permissions initiated from Cosmos Hub can enable these time-based executions to take place without intermediate vault contracts. Thus, this improves efficiency and increases reliability compared to alternative solutions.

Differentiation

Bot Networks

Decentralized scheduled task execution is facilitated by bot networks, addressing challenges of server-based setups and central points of failure. Tasks are registered on an on-chain smart contract, with often the first successful bot claiming a reward. Inefficiencies arise with multiple bots executing transactions simultaneously, increasing network congestion and gas costs. Additionally, critics highlight issues like rewarding agents on a first-come basis, leading to centralization as unprofitable agents exit. In addition, having arbitrary trigger addresses pose limitations, requiring additional smart contract logic for privileged execution, thereby increasing the complexity of an automation workflow.

Privileged Smart Contracts

In CosmWasm blockchains, smart contracts can run with privileges. These can leverage BeginBlocker and EndBlocker functions for scheduling block-based execution. Several chains have integrated this. This feature may seem similar to the IA module, but the system is permissioned. Privileged smart contracts demand more computational resources per execution. Running trigger engines inside smart contracts increases gas costs for users and makes such a system less flexible. Running a trigger engine inside a virtual machine has fixed computational costs, as a check for scheduled executions needs to be performed on an recurring basis. Thus, this also impacts potential fee revenue of such a solution.

With recurring executions, blockchains have to find a balance for time-based executions and general transactions in terms of blockspace usage. Hence, we also find a necessity for governance for measures like limits per block and fee settings. The IA module offers a protocol-neutral, permissionless platform with integrated governance parameters, allowing the community to find the balance between blnetwork usage and fee revenue.

Fee Mechanism

We have specified 2 main governance parameters for fees:

  • Fixed Fee per execution: To prevent network congestion. Revenue is directed to the community pool.
  • Flexible Fee per execution: To compensate for computational resources. Revenue is directed to validators and their delegators.

Outcome and Value Creation

The project would drive Cosmos Hub and ATOM value in the following ways:

Scheduling Actions: The IA module abstracts the complexities of repeated transactions away from users. The IA module enables conditional automation of both protocols and user assets, empowering protocols and their end-users to control their assets without the need for manual transactions, Escrow or Vault contacts. As more protocols leverage this automation, the demand for ATOM tokens to access and utilize the module increases, contributing to the appreciation of the ATOM token value.

Increased fee revenue: Through the governance mechanism, Cosmos Hub can set fees and implement measures to prevent network congestion. By initially charging higher automation fees to deter spam and ensure network efficiency, the module incentivizes users to hold and stake ATOM tokens to benefit from preventive measures against network congestion. This fee mechanism creates a direct connection between network usage and ATOM token demand, positively impacting the token’s value.

We anticipate that the introduction of the IA module will have a substantial impact on Cosmos Hub fee revenue, potentially increasing it by a significant margin from its current level. Presently, the Cosmos Hub community pool generates an annual transaction fee revenue of approximately 60,000 ATOM tokens (Token Terminal).

Assuming a fixed fee of 1 ATOM per execution, with a trigger integrated into 20 host-chain protocols for daily executions, additional revenue would reach up to 7,300 ATOM tokens annually. This is equivalent to $73,000 at a rate of $10 per ATOM. For local triggers, primarily catering to recurring payment needs, a fixed fee of 0.1 ATOM per execution could be set. With around 4,000 weekly executions, the annual community pool revenue would grow by 20,800 ATOM tokens annually. This amounts $208,000 at a rate of $10 per ATOM. These combined estimates suggest the potential for an additional $281,000 in revenue for the community pool annually.

Interchain Coordination: Actions can coordinated between different protocols on different chains. By enabling permissionless automation and fostering interoperability with Ethereum and other EVM chains, the IA module expands Cosmos’s horizon. Through integration with Cosmos chains over IBC as well as EVM protocols, Cosmos Hub can become a platform for orchestrating automated actions.

Discussion

We believe that the Intent-centric Automation Cosmos SDK module would be a valuable addition to the Cosmos Hub. It unlocks new use cases by enabling permissionless automation of local Cosmos Hub actions as well as actions on connected chains.

What do you think of adding the IA module to the Cosmos Hub? We are curious to hear your thoughts and gather community feedback on this topic.

2

Glad to see you guys move to a fee-per-tx based system. You have our support to bring this module to the hub!

1 Like
3

This is really cool. How far along is the module development?

4

@tknox35 Thanks for your reply!

The core automation logic, covering features like Interchain Account automation, fee structures, execution history tracking, and basic conditional logic, has been successfully implemented. We’ve also conducted thorough testing with both unit and integration tests to ensure reliability.

Currently, we’re looking at expanding the module to include more advanced features. We’ve already incorporated key governance parameters, focusing on fees, and are exploring additional safeguards to limit trigger executions within specific periods. Future developments include introducing sophisticated condition-based logic with conditional operands and enabling the reuse of message outputs for new actions.

1 Like
5

This looks like pretty solid work to me. However, one concern I have is that this will put maintenance and security load on the Cosmos Hub since it is a native Cosmos-SDK module.

Smart contract based solutions (perhaps one running on Neutron) would not have this issue. You compared that briefly and my main takeaway is that a smart contract based solution could use more gas. Is this really an issue? How much more gas is needed? How much impact will this have on users? Are there any other benefits of the native approach?

If we do decide to take the native Cosmos-SDK approach that you recommend, how much maintenance will this need? How big of a codebase will it be, and how tightly will it integrate with Cosmos-SDK internals? I know it’s really tough to estimate this stuff, but I’m trying to get a sense of how hard it will be for someone to update it to new SDK versions.

1 Like
6

@jtremback Thank you for your perspective. There are several factors to consider when it comes to performance.
The ability to efficiently iterate on a queue block by block is important from a UX perspective. There’s a high fixed computational effort associated with calling a virtual machine (VM) on a recurring basis. With the SDK-native approach, the module directly accesses the EndBlock, eliminating the additional effort of calling into a VM to access the logic.
In addition, our SDK approach offers the advantage of making calls directly with native message handling and directly access IBC post-packet handling. In contrast, a privileged smart contract solution would access the Cosmos SDK message handler and route ICA packets by sending messages from the smart contract code, accessing route logic through the wasm VM bindings, and the CosmWasm Cosmos SDK module. ICA packet acknowledgements and timeouts would have to call into a VM again to be added to the trigger history. Thus, the IA module approach reduces complexity and is more efficient in each step in the execution process.

We view having low computational complexity as an important advantage over to a privileged smart contract solution as it determines the amount of executions that can take place in a block. Measuring and comparing gas cost is not possible as it’s part of FinalizeBlock and not calculated in Endblock/BeginBlock functions. However, the longer an execution takes, the less amount of executions would fit in a block. The time to compute impacts planned executions. For an EndBlock-based solution, long computation times would result in actual execution times being later than scheduled and less predictable. With BeginBlock, the impact would be a delay in execution for general transactions.

In sum, our IA module solution requires less computation and can include more (trans)actions per block. These are advantages that make it suitable as a long term solution for protocols and users looking to integrate predictable and reliable automation.

The codebase is intentionally designed as a generalized framework for handling any message, and does not have message-specific logic. This makes it efficient and relatively easy to maintain. While it might be more complex than x/gov, it aligns with other ICA-enabled modules like stride’s x/stakeibc.

In the next phases of the CHIPs process, we could consider providing ongoing maintenance support for the module, ensuring compatibility with new Cosmos SDK releases expected to be implemented in the Cosmos Hub repository for the foreseeable future. For example, for up to 5 years and covering up to 7 Cosmos SDK upgrades. It’s important to note that our maintenance support would include patches and fixes, addressing any unforeseen additional effort that may arise. Drawing from experience, I’ve implemented upgrades before, and while a major upgrade like 0.40 with protobufs took more time than anticipated, I estimate that an upgrade would generally require up to two days of work. With our maintenance support we aim to minimize the effort required by the Hub’s core development team.

1 Like
7

Why isn’t gas cost a factor? Don’t different types of jobs have different resource requirements, and thus require gas metering? (As an aside, I noticed you have something about 1 ATOM above, but I’m kind of confused on whether this is a fixed cost).

If there is gas metering, then isn’t the cost of running jobs of primary concern to the people creating them, and can’t the efficiency of your solution vs. a smart contract solution be evaluated as gas costs to be paid by users?

Given that you are proposing a pretty high 1 ATOM fee, it seems like there is some latitude for computation to be somewhat expensive.

This sounds great, but I would suggest that maybe maintenance not be paid for up front, but instead be contracted on a recurring basis. I’m glad that this module will be low maintenance.

1 Like
8

Good point. Most of the execution sequence is fixed, so the fixed cost could be main cost per execution from a user’s point of view.

Currently the module has a fixed fee per execution, and a flexible fee per execution that is based on the interval. The flexible fee can be expanded to also factor in this logic. This is part of our work around adding comparative functions and message reply-based logic. We can indeed use the gas meter for determining the flex fee.

It’s not possible to determine the differences in efficiency because a such a smart contract system is hypothetical. Also, gas meter consumption can be customized, which is also implemented in the x/wasm module. Gas in CosmWasm is determined by custom metering. This includes a multiplier and gas cost can depend on the smart contract message length. These gas settings differ per chain.

Fee strategy is an interesting discussion point.

Our proposed idea is to have a fixed fee for local messages of 0.1 ATOM and having a higher 1 ATOM fee for interchain actions. One of the main target groups for interchain actions can be protocols. The higher fee accounts for IBC relay cost and and can be offset by the benefits of automation by the IA module for protocols (examples in first post).

For execution on Ethereum, the Gelato bot network charges 20% of ETH gas, which currently amounts to about 2-15$ per execution.

Having a high initial fee makes sense for a new kind of product where customers are willing to pay a premium for. On the other hand, low fees can make the module on the Cosmos Hub more competitive to the current bot network solutions. A lower fee opens up the module for a broader audience. A similar fee to Gelato allows Cosmos Hub to be more of a center of traffic.

That makes sense. This can be contracted on a recurring basis.

9

Fair enough. Maybe someone else can chime in with a real example of a CosmWasm automation system. @Elijah and @JakeHartnell - are you aware of any?

Also, I know that @zaki_iqlusion 's Sommelier is largely based on endblock automation (IIRC?), although I think not CosmWasm. Maybe he has some input here as well.

Why not just charge based on gas metering alone?

10

Gas metering alone (flexible fee) can work. The fixed/flat fee per execution can be set to 0.
We came up with this type of fee as a way to prevent network congestion and at the same time bring value to the community pool, whereas with the flexible fee we aim to reward the Hub’s participants for providing computational resources. This flexible fee per execution is directed to the fee pool.