FAQs about Interchain Accounts

And why you shouldn’t buy into Interchain FUD

Interchain Accounts V1 is live!
As different chain ecosystems prepare to launch different products based on Interchain Accounts, we wanted to share further details around the usage of Interchain Accounts which we hope will help contribute to smooth and successful rollout across the Interchain.

For users of IBC:

What is the difference between an Interchain Account and an account I had before? Do I, as an end user, need to worry about Interchain Accounts?

IBC Interchain Accounts enables cross-chain communication and chain-to-chain interactions. Interchain Accounts function in the background to end user interaction as something more akin to granting blockchains the power to open up their native functionalities as an “API” or service endpoints to be called by another chain, and then executing the calls to these endpoints over the Interchain Account channel. Most bridges, on the other hand, simply enable the passing of assets back and forth.

One way to think about the potential of this new feature is what it enables for the user experience of Interchain native models. In a traditional framework, the end user would log into an interface representing chain A and pass an asset to chain B via an IBC transaction. The user would then be required to log into another interface, this time representing chain B, and complete the remainder of the product flow. With an Interchain-native product model, a user can complete the entire flow within a single, streamlined user experience where chains pass sets of instructions and execute transactions under the hood — all without the user ever having to leave the first interface. Interchain Accounts enables Interchain-native business models and establishes interoperability as a basic primitive.

For builders in the IBC Gang:

The most important IBC component to understand when it comes to Interchain Accounts are channels. Channels are created between different IBC enabled chains and connect two ports which are namespaced by the IBC application module that they refer to. For example, in the case of token transfers between the Cosmos Hub and Osmosis, the Hub uses channel-141, ‘transfer’ port for ICS20 transfers, to connect to the channel-0 ‘transfer’ port. All tokens transferred over a channel will be assigned the same denomination as other tokens flowing over the channel, which looks like this ibc/<hash of the channel-id & port-id>.

IBC is designed this way because the path that an asset has traveled determines the security of the asset. Because of IBC’s light client based design, there is no need to trust an external party for verification of transaction validity. Instead, the trust we have in the asset is equivalent to the trust we have in the consensus mechanism of the other chain through the IBC light client representation of that consensus. Rather than referring to the validator set of a bridge, you can directly refer to the IBC path that asset has traveled across in order to see the security guarantee of the asset.

This also means that each channel is a different path between two chains. Opening more channels does not increase the volume of traffic that can flow between two chains but can increase the types of traffic that can flow between two chains. Different channels connecting to the same transfer port will result in different token denoms, and different channels will be opened between different future application ports such as NFTs or Interchain Accounts.

What do Interchain Accounts mean for me as an operator?
This has important implications for relayer operators as this means there may be a need to cover multiple Interchain Accounts channels established on IBC connections between chains if multiple chain to chain accounts have been opened. Both Hermes and Golang relayer infrastructures are optimizing for this new flow — Golang relayers by moving from channel-based relaying to connection-based relaying which covers all ICA associate channels and Hermes relayers by providing a wildcard ica* feature to the config file to configure a relayer to cover all Interchain Account channels.

What do Interchain Accounts mean for me as a chain developer?
For Interchain Accounts chain developers, this means that for each Interchain Account opened on a chain, there must be a new channel established for messages flowing over that path. These messages should be whitelisted by governance as parameters of the module. Furthermore, because Interchain Accounts are controlled by separate chains via IBC transactions, developers looking to build upon Interchain Accounts must write custom logic in their own IBC application module, called authentication modules. In order to make sure that the messages are securely sent, the controller chain registering and controlling an account on a host chain — the chain where the interchain account is registered — must have at least one interchain accounts authentication module in order to act as a controller chain. A sample authentication module can be found in this Hub tutorial.

What do Interchain Accounts mean for the entire Interchain ecosystem?
Expect everyone else to start understanding that IBC isn’t “just another bridge tech for token transfers. It’s a general purpose comms protocol for community computers”, already dealing in billions of dollars worth of value transactions every month and growing daily.

In the near future, expect to see projects like the Cosmos Hub, Quicksilver, Umee, Juno, Osmosis, Sommelier, Regen, Secret Network, and many more release exciting new Interchain native products, all powered by Interchain Accounts. LFG!

About the Author:
Charly Fei works at Interchain GmBH and is the product lead of IBC (the Inter-blockchain protocol). Charly is on Twitter.

Thanks to Thomas Dekeyser and Alan Traeger for the detailed review

FAQs about Interchain Accounts was originally published in Cosmos Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.