IBC: A Core Primitive for Interchain Native Products
The birth of Bitcoin led to a Cambrian explosion of blockchains with different design principles and use cases. While these distributed ledgers serve different purposes, they existed (and still exist to a certain degree) as silos with limited meaningful interaction.
Similar to the Internet which facilitates different types of computers in different parts of the world to communicate with one another, a similar technology that allows blockchains to communicate is a necessity for true value accrual. The Inter-Blockchain Communication (IBC) protocol aims to serve this purpose.
What is IBC?
IBC is an interoperability protocol that allows heterogeneous blockchains to speak to one another in a secure, reliable, ordered, and authenticated manner. Put simply, IBC allows blockchains to interact in a trust-minimized environment.
Unlike a sharded protocol where the topology of a network is known i.e., where there is a given numbered set of ‘shards’ that are arranged in a specific way, IBC makes no assumptions on topology. The network of blockchains connected through IBC can evolve with time and still maintain its security properties.
It is noteworthy that IBC is not native to the Cosmos Network. While the instant finality of Tendermint Core and the modularity offered by the Cosmos SDK are desirable features to implement IBC, they are by no means necessary requirements. Other blockchains embodying probabilistic finality such as Bitcoin and Ethereum can also be connected via IBC using threshold finality gadgets.
At the core of IBC are 2 key components:
- Light clients: an IBC light client is an algorithm that can cryptographically verify the updates made to the state machine on a counterparty chain by verifying block headers. Chain A maintains, and periodically updates, a light client for chain B that it wishes to interact with (and vice-versa).
- Relayers: two blockchains interconnected over IBC do not directly beam messages between one another. Rather, they commit/store (a hash of the) data packets to their state. Permissionless off-chain processes known as relayers observe for such packets and ferry them across to the counterparty chain.
In alignment with the Cosmos vision to create an Internet of Blockchains, the design choices of IBC were influenced and motivated by the TCP/IP specification. Similar to how TCP/IP lays out the standard for computers to communicate, IBC specifies a general set of abstractions that, when implemented allows blockchains to communicate. Just as TCP/IP is unopinionated about the contents of data packets relayed over the network, so too is IBC. And, similar to how applications are built on top of TCP/IP — such as HTTP, and SMTP — the same is true for IBC where applications can use the protocol as a foundational layer to build on.
Data packets relayed over IBC can contain different information depending on the application it serves. For a fungible token transfer, the packets contain information pertaining to the token denomination, amount, sender and receiver addresses. For cross-chain governance — where an account on chain A can vote on chain B — the packets contain vote information.
Taking a step back and viewing the interoperability landscape as it exists today, one recognizes that it consists primarily of cross-chain bridging solutions. While bridges are key to unlocking value transfer across different ecosystems and to leverage different blockchain use cases, their security models have been inadequate.
A significant share of the bridges developed today place trust assumptions on third-party actors that monitor the state of the source and destination chains. These entities are responsible for verifying and signing transactions — usually through a Multi-Party Computation (MPC) scheme or Threshold Signature Scheme (TSS). By doing so, bridges lose the security guarantees of the underlying chains and instead, trust relatively more centralized actors with weaker security models.
As a result of insecure bridge implementations that are custodial in nature, we’ve witnessed a series of exploits where malicious actors gain access to a majority of validators in the network and drain funds (1)(2)(3).
In contrast to third-party bridges, IBC offers a trust-minimized communication environment where the protocol’s security model boils down to the security guarantees of the constituent light clients. There are no trusted third parties in IBC’s architecture.
IBC is not a bridge. Neither is its use case limited to token transfers. IBC is a fundamental paradigm shift in interoperability by paving the way for arbitrary data transfer across heterogenous blockchains in a trust-minimized, secure, and extensible manner.
As of writing, there are 48 active blockchains connected via IBC. And over the past 30-day window, a total of 10 billion USD value was transferred across chains using the IBC protocol.
Since its launch in April 2021, IBC has triggered a host of Interchain native products that leverage the protocol for use cases requiring interoperability as a fundamental building block. These products do not exist independently. By assuming interoperability as a basic primitive, they integrate with one another, complement one another’s functionalities, and amplify their utility.
Not only has IBC paved the way for different products, but also enabled features such as Interchain Accounts, Interchain Queries, and Interchain Security. The former facilitates cross-chain account management where an account on one chain can control an account on another chain. While Interchain Accounts allow an account to write state on another blockchain account, Interchain Queries allow a chain to read data from another chain. Interchain Security (in its initial stage) gives one chain the option to lease security from another chain by sharing the same validator set.
IBC has given birth to a whole new category of Interchain native products. Without IBC as an interoperability solution, these products would be extremely difficult to build using bridges. The section below looks at some of the Interchain products, their features, and how they leverage IBC for different use cases.
Interchain native products
Osmosis
Built using the Cosmos SDK with IBC enabled on Day 1, Osmosis is the go-to DEX within the Cosmos Network. Osmosis serves as a platform for customizable Automated Market Maker (AMM) liquidity pools.
Unlike traditional AMMs, Osmosis has no fixed global parameters for its liquidity pools. Instead, the protocol gives liquidity providers (LPs) the freedom to customize different pool variables such as swap fees, asset weights, and bonding curves. The degree of customizability on Osmosis paves the way for a more capital-efficient DeFi experience by creating robust incentive mechanisms, low slippage, and decreased impermanent loss.
As a protocol built for the LPs and owned by the LPs, Osmosis aims to serve as an AMM laboratory — fostering rapid experimentation for a highly streamlined trading UX.
The native token OSMO, serves primarily as a governance and staking token. The sovereignty-first principle of the Cosmos Ecosystem — embodied in the underlying Tendermint and Cosmos SDK stack — allows the Osmosis stakeholders to experiment, rapidly iterate, and create governance proposals to define the long-term roadmap of the DEX.
Even though the protocol has an active set of 180 validators and the network is secured using the OSMO token, in the future Osmosis plans to utilize Interchain Security from the Cosmos Hub once the feature is shipped.
Since its launch in January 2021, liquidity and transaction volume on the DEX has grown significantly.
The backbone of an AMM is its liquidity. As shown in the chart above and as of writing, the USD value of total liquidity on Osmosis currently is 1.5 billion. Impressively, from June 2021 till March 2022, liquidity on the DEX has increased Month-over-Month (MoM) by 45% on average. Monthly trading volume (in USD) has also grown at a staggering rate of 61% on average.
Osmosis was the first go-to-market application of IBC and the DEX leverages the IBC protocol to facilitate cross-chain fungible token transfers.
On a high level, token transfers between two ledgers involve the following steps: if Alice wants to transfer ATOM from the Hub to Osmosis, then 1) the ATOMs are escrowed on the Hub. 2) A proof that the tokens were escrowed is relayed from the Hub to Osmosis. 3) The light client on Osmosis verifies the proof against the most recent block header to ensure validity of the proof. And 4) an equivalent amount of ATOM is minted on Osmosis.
Note that the ATOM on Osmosis is not native ATOM. But rather a representation of ATOM on the Osmosis chain.
A notable feature of the Osmosis protocol is Superfluid Staking. Perhaps one of the most groundbreaking developments in the Delegated Proof-of-Stake (DPoS) space, superfluid staking allows an LP to use their bonded OSMO tokens as delegated stake in the network. This removes the opportunity cost that exists between providing liquidity (and earning rewards) and staking tokens to secure the network whilst generating staking rewards. Superfluid Staking allows one to do both. Hence a user can accrue rewards from both LP-ing as well as staking.
The Osmosis team plans to take this feature up a notch and transform it into Superfluid Staking-as-a-Service: termed Interfluid Staking. This feature will allow any chain in the Cosmos ecosystem to secure its network using its native token that’s bonded in a superfluid liquidity pool on Osmosis. For example, from the OSMO/AKT superfluid pool, the Akash Network can tap into the bonded AKT tokens to simultaneously be staked and thus add to the security of its network. In short, Interfluid Staking is Superfluid Staking for the non-OSMO part of your LP position.
IBC will act as the rails for Interfluid Staking in order for the Osmosis chain to retrieve data on the active validators and their voting power from the counterparty chain. Staking rewards that are generated will also be transferred over to the receiving chain via IBC.
Umee
The Umee Network is a proof-of-stake blockchain, powered by Tendermint BFT consensus and designed using the Cosmos-SDK. By interconnecting the Cosmos and Ethereum ecosystems for cross-chain borrowing/lending purposes, Umee aims to become an interchain DeFi Hub.
The DeFi vision of Umee is built on the following three pillars:
1. Interchain leverage: using Umee, a user can collateralize assets on one blockchain and borrow assets against it on another blockchain. For example, one could borrow ETH, DAI, or USDT on Ethereum by collateralizing their ATOM on the Cosmos hub.
This unlocks liquidity across multiple chains and also allows users to access the robust stablecoin reserves on Ethereum.
2. Multichain staking: similar to staking derivatives, the idea of multichain staking is to increase capital efficiency of yield-bearing staked assets. This plays in to the fact that staking derivatives can have utility beyond the chain on which it was minted (example: sATOM existing as an ERC-20 to collateralize against a loan on Ethereum). In this scenario, the interest rate on the borrowed sum (from chain B) could be paid off using staking rewards generated from chain A. This could potentially create a new DeFi dynamic surrounding staking yields and interest rates.
3. Cross-chain DeFi rates: this third pillar encapsulates the concept of Time Value of Money (TVM). According to the TVM, a dollar today is worth more than a dollar a year from now. TVM plays an important role within the traditional financial markets for lending and borrowing. Typically, the interest rates generated on government bonds for various time periods (1, 5, 10-year bonds) define what the TVM should be.
As mentioned by Brent Xu — CEO of Umee — the TVM can organically be achieved in a decentralized manner through cross-chain DeFi rather than a centralized actor dictating terms. At the core of this idea are PoS yields. Rewards generated by staking represent an opportunity cost since a staked asset could potentially generate yield through an alternative investment vehicle. This idea could open up the potential to establish a time value for ATOM, ETH, AKT, and so on.
Umee aims to become the first true cross-chain lending and borrowing protocol for Cosmos and Ethereum. By leveraging multiple interoperability solutions, Umee intends to remove the inherent silos that exist which prevent users from accessing interchain leverage and liquidity.
Interoperability between the Cosmos and Ethereum networks is achieved using a combination of IBC and the Gravity Bridge (a non-custodial interoperability solution that bridges assets between Cosmos and Ethereum).
As shown in Figure 2, a user can for example, deposit ETH, mint uTokens which are 1–1 representations of the deposit amount, send the uTokens (or uETH in this example) over to Umee and use it as collateral to borrow ATOM. IBC is leveraged in the final stage of this flow to escrow Umee representation of ATOM on Umee and mint an equivalent amount of native ATOM on the Cosmos Hub.
Apart from cross-chain collateralization and borrowing, Umee supports the unique feature of using staked assets on one chain as collateral to borrow on a different chain. For example, Alice stakes her ATOM and receives staking rewards. As soon as the rewards accrue, it could immediately be liquidated in order to borrow a stablecoin on Ethereum.
Implementing Interchain Accounts will significantly streamline the user experience on Umee. This will allow, for example, an account on Umee to send ATOM from Umee to the Hub, stake the tokens, and vote on governance proposals, all while remaining on a single platform. In essence, any account related action that can be performed on the Hub, can be controlled and executed from an Umee account.
From a user perspective, the ability to use a single interface for engaging in activity across multiple chains significantly reduces operational security risks and complexity, while delivering a smooth user experience. The level of composability that IBC introduces through Interchain Accounts will accelerate development and adoption of current and future iterations of Interchain product models.
Band Protocol
The Band Protocol is a decentralized cross-chain oracle that provides blockchains with APIs and access to real-world data. The protocol is built on top of BandChain, a Cosmos SDK based chain utilizing Tendermint, that acts as a middleware layer between decentralized applications (dapps) and off-chain data sources.
Blockchains in isolation have no access to exogenous information. Given a set of data, they can be a powerful set of computers to agree upon what’s true. But they do not inherently possess the means to access external information. This is the primary value proposition for oracles.
Since its mainnet launch in October 2020, Band Protocol has witnessed widespread adoption. As shown in the chart below (using available data beginning from September 2021), the total number of data requests made through BandChain has been consistently increasing Month-over-Month. The team at Band Protocol has also formed partnerships with institutional-grade data providers such as NASDAQ, Brave, CoinGecko, as well as with protocols like Celo, Injective, and Mirror protocol for various DeFi applications.
Cross-chain data feeds serve a vital purpose for numerous on-chain and real world applications. Some of the use cases seen for BandChain are:
- Real-time price feeds: aggregating asset prices from multiple data sources. Reliable price feeds are a requirement for the smooth functioning of DEXs, futures/options markets, derivatives trading, etc.
- Verifiable Random Number Generation: generating random numbers for NFTs, speculative games, or other randomized selection applications.
- Cross-chain communication: BandChain can act as an intermediary between two blockchains to facilitate communication. For example, while bridging assets between two blockchains, BandChain can be used to verify transactions and to relay proofs between said chains.
Data requests from an IBC-compatible chain to BandChain are made through channels. A channel is a conduit to transfer packets between two modules on different chains. Any IBC-compatible blockchain can create data requests to BandChain over IBC. The channel opening process between a requesting chain and BandChain creates unique channel identifiers which modules on either side of the chains can use to accurately route packets between each other.
As depicted in Figure 3, chain A sends a data request as an IBC transaction to BandChain (blue dotted arrows represent data transferred over IBC). The packet is relayed to the oracle module on BandChain and the corresponding oracle script for the requested data is fetched. After ensuring that a sufficient amount of gas was paid for the request, an acknowledgement over IBC is sent back to chain A. If there is no error in the internal checks (for example, ensuring that the total fee paid for the request is less than the fee limit), then the request is broadcasted to all the validators who fetch the data, aggregate it and send it to BandChain. The packaged data/report is then relayed to chain A using IBC and the packets sent to chain A contain the requested data as bytes.
The use-cases for oracles today are mostly limited to DeFi. Nevertheless, the need for reliable information is unambiguous and increasingly more relevant with each passing day. While consensus on price feeds provided by oracles are important, one can imagine a future scenario where consensus on any general truth becomes vital.
Crescent Network
The concept of an AMM was a breakthrough when it was introduced by Uniswap in 2018. The AMM thesis was that traditional order books are infeasible for DeFi due to high transactional latency and exorbitant costs. Given that Ethereum was the only mainstream, production-ready, general-purpose blockchain at the time, the limitations that Uniswap resolved by building an AMM were the limitations imposed by Ethereum i.e. low latency and high gas costs.
But over the past few years, the launch and success of protocols such as dYdX and Serum proved that DEXs built using an order book system were indeed feasible when launched on blockchains with high transactional throughput.
The Crescent DEX has partially chosen to follow the model of order book-based DEXs by building a hybrid system. In contrast to other AMMs that exist today, Crescent DEX is a combination of an AMM and an order book design. Crescent Network serves as a cross-chain DeFi hub, built with the objective of creating a capital-efficient marketplace for users to leverage seamless trading strategies, a variety of different investment vehicles, and to effectively manage portfolio risk. The three primary product offerings on the network are the Crescent DEX, Crescent Boost, and Crescent Derivatives.
Users depositing tokens into a liquidity pool on the Crescent DEX are simultaneously acting as a LP and a market maker by injecting order book liquidity. In fact, being a LP is only a small subset of how users can route liquidity to the Crescent DEX. Users can also market make in the traditional sense by creating bids and offers through the order book.
The hybrid nature of the DEX implies that each liquidity pool can be considered as a regular user/market participant providing liquidity to the order book. Market or limit orders routed through the different pools are sent to the order book where trades are batched and executed according to different ticks.
Liquid staking is a feature on Crescent whereby users can stake the native token CRE to receive staking derivatives in the form of bCRE (a liquid representation of one’s stake). The bCRE tokens can be used within the network to vote on governance proposals, provide liquidity to a pool where one side of the token pair is bCRE, or can be swapped for supported assets such as ATOM, LUNA or UST.
IBC broadens the scope of liquid staking since bCRE can be transferred to other IBC compatible chains, or be swapped for ATOM. This provides a user with more options to allocate capital than being limited to depositing the derivative into a liquidity pool and earning rewards. Similar to Osmosis, users can also deposit, swap, or withdraw on the Crescent DEX using IBC.
Other notable features on the DEX include batch execution and ranged liquidity pools. The former is a means to prevent MEV by batching multiple transactions together based on their price and executing them simultaneously. The latter are liquidity pools with a predefined token-pair price range that provides multiple benefits such as capital-efficient trading within pools where two tokens are similarly priced, and the option to create one-sided pools.
Crescent Boost, once implemented, will feature a product offering that combines lending, hedging and leverage. This will allow liquidity providers to borrow against their LP positions while hedging balance sheet risk at the same time. Yet another exciting product offering is Crescent Derivatives, whereby a trader with long or short open positions can collateralize those synthetic assets to borrow against.
Quicksilver Protocol
Quicksilver unlocks the Interchain staking model by facilitating liquid staking throughout all IBC-enabled chains.
The primary objective of Quicksilver is to provide a solution to the capital inefficiency that comes with vanilla staking. As noted earlier, staked assets pose a limitation in terms of leveraging one’s capital for other yield bearing opportunities. Liquid staking (as also seen in Crescent network’s suite of features) solves this problem by tokenizing staked asset positions without having to unbond.
Until now, liquid staking has been a feature native to specific chains. Quicksilver proposes a fundamentally different approach by acting as a single platform to move all of one’s Assets (staked positions) and accumulate qAssets (staking vouchers). Using the liquidity staking module built by Iqlusion, a user on Quicksilver can mint liquid vouchers that represent their staked positions on various Cosmos zones without having to unbond assets from these zones and then deposit them onto Quicksilver,. This allows one to receive staking rewards while simultaneously generating yield through the vouchers by way of other DeFi instruments.
Delegators can also delegate to any validator of their choice for a given target chain. This is in contrast to other liquid staking implementations where delegation is only possible to a whitelisted set of validators — leading to a few of them procuring an asymmetrically large voting power.
Upon mainnet launch (scheduled for Q3 2022), Quicksilver is poised to become the first zone that implements all currently existing IBC-level applications such as Interchain Security, Interchain Accounts, and Interchain Queries.
By becoming one of the first consumer chains of Interchain Security, Quicksilver will be secured by the economic stake backing the Cosmos Hub. By acquiring security out of the box, Quicksilver reduces the operational and economic overhead that comes with having to bootstrap your own validator set.
Quicksilver features an interesting application of Interchain Accounts where a single Quicksilver account can, for example, be used to vote on all the chains where a user has assets staked (Hub, Osmosis, etc.). This is possible by wrapping vote information within an IBC packet and executing this data on a host chain. The Interchain Queries feature is made use of to query data pertaining to the user’s voting power on different chains.
Even though Quicksilver launches with Interchain Security, users can still participate in protocol governance using the native token QCK. While the token will initially be used to pay the provider chain (Cosmos Hub) for leasing security, Quicksilver plans to eventually compose their own validator set. After having done so, QCK will act as the staking token for the protocol. Aside from governance and security, QCK is also used to pay for transaction fees on the network.
Conclusion
An explicit goal of IBC has been to push the boundaries of composability to enable interoperability as a fundamental primitive and not just a feature. Applications of IBC such as Interchain Accounts, Interchain Queries and Interchain Security go a long way in achieving said goal.
On the development side, over the past few years, Cosmos has increasingly attracted builders into the ecosystem. Unlike platform-based development, Cosmos offers an array of developer tools to build your sovereign blockchain in a matter of minutes. Tendermint offers the gold standard of BFT consensus engines while the modularity of the Cosmos SDK allows one to import and use pre-existing modules.
IBC launched more than a year ago, and today the Cosmos Ecosystem is starting to experience more nuanced use cases that IBC unlocks. New and interesting applications will continue to be built using IBC and more Interchain native products will incubate as a result. As far as interoperability goes, IBC is poised to become the universal standard that enables the Interchain.
About the author: this post was written by Aditya Ravi Raj, IBC Protocol Analyst at Interchain GmbH.
If you’re a chain developer looking to build your custom IBC light client, and have any questions, comments or feedback on the above, feel free to reach out to us here.
