Blog

The IBC transport layer, which handles the transport, authentication, and ordering of data packets, serves as the foundation for a robust application layer with a wide range of features for teams that choose to build with IBC.

IBC applications offer a diverse set of features from token transfers and cross-chain account management to data queries. While this extensive feature set is useful, it can be a source of confusion for new developers who are unsure about which features to implement on their chain and why.

This blog post clarifies this issue by highlighting the various features supported by IBC and offers guidance on whether to incorporate them into your product. 

We start with a decision matrix to help you identify which features to enable. Following that, we’ll go through an overview of each feature, outline their use cases, and discuss their pros and cons. To conclude, we'll examine case studies to observe how current projects are leveraging these features.

Interchain Standard (ICS) 20 fungible token transfer is an application module that allows one chain to send tokens to another.

As of December 2023, IBC processes about $1.8B in token transfer volume per 30 days. Nearly all of the 100+ IBC-enabled chains use the transfer module.

Use case scenarios:

• To send and receive tokens from different chains. Examples: DEX applications including Osmosis, Crescent Network, or for other DeFi primitives, e.g. dYdX v4.

• For payment apps to be able to send stablecoins or other non-native assets from one chain to another.

This feature is for you if…: You need to facilitate cross-chain transfer of tokens between one or more counterparty chains.

Interchain Accounts (ICA) facilitate cross-chain account management by allowing a ‘controller chain’ to create and manage accounts on a ‘host chain’, where the controller chain is the chain that registers and controls an account on the remote host chain.

ICA-enabled chains can create accounts on other ICA-enabled chains and manage them through IBC transactions, removing the need to sign transactions on the remote chain with a private key. Therefore, an application on your chain can provide a single interface for your users to perform cross-chain actions, without ever leaving your chain.

An interchain account maintains all the functionalities of a standard account, such as staking, sending, and voting. However, it is managed by a separate controller chain via IBC, ensuring that the owner account on the controller chain retains full control over any interchain account it registers on a host chain.

It's important to note that using ICA involves two components: you can enable either the controller functionality, the host functionality, or both. Activating the controller functionality allows your chain to create and manage interchain accounts on a host chain. Conversely, enabling host functionality allows other chains with controller capabilities to create and manage interchain accounts on your own chain.

Use case scenarios:

• For using tokens as collateral on the controller chain to borrow assets on a host chain. Example: Neutron

• Optimize yield opportunities through concentrated liquidity provisioning on other chains. For example: Quasar vaults on Osmosis

• Send tokens from one chain to another and liquid stake them. Examples: Stride, Quicksilver

This feature is for you if…:

• You want users on your chain to remain on your chain while leveraging functionality specific to other chains.

• You have automated processes that require cross-chain interactions.

An implementation of Architectural Decision Record (ADR) 008, the callbacks middleware is an IBC module that allows core IBC to execute callbacks to any execution environment. It enables an underlying application, such as transfer or ICA, to execute callbacks to secondary applications, like the Wasm or EVM execution frameworks. See this blog post to learn more about the callbacks middleware. You can view our documentation to learn how to add it to your chain.

Use case scenarios:

• Send tokens from chain A to B. If the transfer was successful, then send an ICA packet to stake/LP/swap tokens.

• Execute arbitrary smart contract logic upon receiving an ICS-20 packet.

This feature is for you if…: Your chain has use cases where you need to receive callbacks, on the source or destination, regarding the success/failure of a token transfer/ICA packet and perform subsequent actions based on this information.

This feature allows for a querying/source chain to read data from a queried/target chain. In order to leverage this feature, only the querying chain needs to implement the cross-chain query (CCQ) module.

Use case scenarios:

• Liquid staking protocols such as Stride and Quicksilver use this feature to query the staking rewards accumulated on an ICA host chain. With this data, they’re able to specify a certain percentage of the rewards to be restaked or used for other purposes.

This feature is for you if…: Your project's use case requires reading state from one or more other chains.

Similar to CCQ, Interchain Queries (ICQ) also allow a chain to read data from another chain. But unlike CCQ, ICQ requires both the querying and the queried chain to implement the ICQ module.

Use case scenarios:

• Query token prices from LP pools to perform logic based on the data, such as portfolio rebalancing. Example: Quasar uses ICQ to query the Time Weighted Average Price (TWAP) data from Osmosis.

This feature is for you if…: Your project's use case requires reading state from one or more other chains.

At the time of IBC's launch, the protocol lacked an in-built mechanism to financially incentivize relayers for relaying IBC packets. As a result, relayers had to cover the costs themselves. The ICS-29 Relayer Incentivisation Middleware, also known as the fee middleware, was developed to resolve this issue, introducing an in-protocol feature that compensates relayers on a per-packet basis.

The relayer incentivisation middleware can be added to any existing and future IBC applications as part of an application stack. Hence it can be used alongside token transfers, ICA, etc. Learn more about the fee middleware here.

Use case scenarios:

• Use fee middleware with token transfers to incentivize all packets such as MsgRecvPacket, MsgAcknowledgement, and MsgTimeout.

• Use fee middleware with ICA to incentivize packets.

• One of the main pain points of using IBC with smart contracts is that relayers don’t always relay such packets. By attaching a fee along with these packets, one can incentivize smart contract-to-smart contract relays.

This feature is for you if…: 

• Your chain wants to incentivize relayers in-protocol, without needing to create off-chain agreements with relayer firms or other organizations, or without needing to request delegations to your validator as a form of indirect payment.

• You want more control than what the fee grant offers in terms of how the funds are utilized

The Packet Forward Middleware (PFM) is an IBC middleware for multi-hop routing of IBC packets. PFM enables an IBC token transfer to automatically forward tokens to another chain by triggering another IBC transfer. 

Use case scenarios:

• Move tokens between any two chains even if a direct connection between those chains does not exist.

• As mentioned earlier, tokens native to A, sent from A->B->C are not fungible with the same tokens sent from A->C. By using PFM, the tokens can be sent back to A from B and then forwarded to C, allowing the same token to be fungible regardless of where the user sends it from.

This feature is for you if…:  You want to route packets to chains without having to open IBC connections with those chains.

The Wasm client module is designed to simplify the addition of new light clients. It includes a Wasm VM capable of hosting light client bytecode, allowing for the development of new light clients in any Wasm-compatible language like Rust, C/C++, JS, or Go. Essentially, the Wasm client acts as a proxy light client, enabling interaction with actual light client contracts deployed as Wasm bytecode.

It's important to clarify that the Wasm client is not a client type in itself. Instead, it serves as an interface between the ICS-02 client handler and smart contracts, typically written in Rust, that implement specific light client logic, such as the GRANDPA or Near light clients.

Note: this feature is still under development. We anticipate a final release in December. We’ll be publishing a blog post explaining in more detail how the Wasm client module works and how you can use it on your chain.

Use case scenarios:

• Deploy a new light client written in any Wasm-compatible language without needing a coordinated validator set upgrade.

This feature is for you if…:

• You want to write IBC light clients in any Wasm-compatible language.

In addition to the features mentioned above, the following features are newly released or will be available soon.

ICS-721 facilitates the transfer of NFTs. This app module is in use by Stargaze and Iris, with a handful of other users, such as Gravity Bridge and Omniflix, expected to adopt the feature soon. This app module was co-developed by Stargaze and IRISNet. The Cosmwasm implementation of the module was developed by Ark Protocol.

An IBC middleware built by Omosis that allows ICS-20 transfers to initiate contract calls. IBC hooks enable use cases of the form ‘transfer + action’, eg. send tokens, swap, and send back, all in one user flow.

Built by Osmosis, the rate-limiting middleware imposes governance-configurable rate limits on IBC transfers as a safety measure to protect on-chain assets. This module is primarily implemented in Go and CosmWasm.

Channel upgradability allows chains to upgrade existing IBC channels in order to leverage new features.

Currently, upgrading an existing IBC app or adding middleware to both ends of a channel cannot be done without opening a new channel; at the same time, existing channels contain accumulated state and network effects which would be lost if a new channel was opened. For example, a chain wishing to implement relayer fee middleware would need to open new channels to do so.

Channel upgradability will fix this issue by allowing chains to upgrade their channel ends in order to make use of features like the fee middleware, sending multiple tokens per packet, adding path unwinding, etc. Channel upgradability is now live.

Examples of these features in use in production.

Given that cross-chain token transfers are the bread and butter of interoperability today, nearly all of the 100+ IBC-enabled chains use the transfer module. This feature is particularly beneficial for DEXs that depend on liquidity flowing in from other chains. Osmosis is the quintessential example here. As the Interchain liquidity hub, Osmosis integrates with nearly all IBC-enabled chains, allowing users to transfer their assets to its platform for the purpose of contributing liquidity to Automated Market Maker (AMM) pools.

Stride is a cross-chain native liquid staking protocol that leverages both Interchain Accounts (ICA) and Cross Chain Queries (CCQ). When a user opts to liquid-stake ATOM through Stride's front end, the protocol uses the transfer module to send the tokens to the Cosmos Hub via IBC. Stride, acting as the controller chain, stakes these tokens on the Cosmos Hub using ICA.

The staked ATOM generates rewards that are stored in a separate interchain account, known as 'Withdraw ICA.' To ascertain the amount of accrued rewards, Stride employs CCQ to query this account, subsequently taking actions based on this information, such as restaking a specific portion of the assets. For a more detailed explanation, refer to Stride's documentation.

Evmos aims to utilize the callbacks middleware for various use cases, including liquid staking combined with Liquidity Provision (LP), as well as token transfer coupled with staking, all within a single user workflow. This middleware enhances the user experience by consolidating multiple steps into a single action, eliminating the need for users to sign multiple transactions to achieve their objectives. For an in-depth explanation of how Evmos plans to take advantage of the callbacks middleware, refer to this blog post.

Selecting the appropriate IBC features for your chain's specific use cases is crucial for your project's success. However, for a new team leveraging IBC, gaining the necessary context to make informed decisions can be challenging.

The aim of this blog post has been to serve as a comprehensive guide to help you make well-informed choices tailored to your project's unique requirements. By implementing the right IBC features, you can enrich your product's functionality, offer a seamless interchain UX, and ultimately attract a wider user base to your platform. 

If you have any questions, comments, or concerns about which IBC features to use on your chain, feel free to reach out on the IBC Discord.

Footnotes

1. Multiple tokens per packet is under development. See the open spec PR for this feature here.

2. The spec has been adjusted to support unordered channels but not the implementation.

3. Once channel upgradability is launched, the fee middleware can be added to existing channels as well.