Cosmos: The Evolution of IBC

The Cosmos Vision

How should blockchains scale? Depending on who you ask, you will get a different answer. On one side you have Solana, a monolithic L1 that handles everything on one layer. This means all data availability, consensus, settlement, and execution are on one chain. The benefit is synchronous composability, the tradeoff being larger state growth and more expensive to validate. Ethereum scales with modularity, separating execution from the DA, consensus and settlement layers. Execution is left to rollups like Optimism & Arbitrum while Ethereum’s L1 handles the rest. The benefit is keeping L1 state growth low, thereby allowing end users to run validators, the tradeoff breaking synchronous composability & fragmenting liquidity across various rollups. (For more on L1s & L2s, you can read our previous report on it here.)

This leads us to Cosmos, a network of monolithic app-chains connected through IBC, a trust-minimized communication protocol (“trust-minimized” to the extent that you only need to trust each chain’s validators).

While app-chains of Cosmos are monolithic, handling all parts of protocol DA+C+S+E in one layer, they are often built using a modular software stack including consensus engine Tendermint, execution module Cosmos SDK, and the ABCI interface that sits in between. This gives developers the ability to easily spin up new chains with custom execution environments (eg. CosmWasm, EVM) and leverage IBC for secure cross-chain communication.

The maturity and modularity of the Cosmos software stack have been the biggest catalysts of its growth. While Cosmos is by no means a new ecosystem, its Inter-Blockchain Communication (IBC) protocol went live just over a year ago and there are now 48 active zones/chains. (For more on Cosmos, you can read our previous report on it here.)

State of the Ecosystem

After launching IBC in 2021, the Cosmos ecosystem showed consistent growth of new zones (chains) through Q1-2022 before slowing down a bit in Q2. The slowdown is likely to be temporary, however, as numerous protocols in development and the launch of Interchain Security in August-September will allow chains to deploy quicker.

When thinking about Cosmos & IBC, the Hub (ATOM) is generally what comes to mind. The original thesis for the Cosmos Hub was to be the main zone users would route through in IBC, but that narrative has been challenged heavily over the past year with Osmosis, the Interchain AMM, consistently surpassing the Hub in transfer value as the main liquidity hub in the ecosystem. More recently, Axelar has begun to carve out a place connecting chains outside of IBC like Ethereum, Polygon, Avalanche, Fantom and Moonbeam.

The ecosystem is composed of a variety of chains/zones covering different use-cases, but still lacks one fundamental primitive: stablecoins. The majority of stablecoin liquidity in Cosmos sits on Osmosis as assets bridged from Ethereum; the most liquid stablecoins are not even native to IBC. While Agoric will have a collateralized DeFi stablecoin (IST), these models are hard to scale, and there is still demand for a centralized stable like USDC or BUSD (the USDC on Osmosis is axlUSDC).

So why aren’t there native stables? Deploying centralized stablecoins on Cosmos is not as simple as something like Ethereum where you can just issue on the base layer. If Circle wanted to launch an IBC-native USDC, where would they deploy? They could (i) launch on Osmosis being the “Liquidity Hub”, (ii) as a Consumer Chain leasing security from the Cosmos Hub, (iii) or even their own custom standalone chain with Circle validators. The choice is not a simple one and has some unique considerations due to the way IBC works, which we will dig into now.

IBC Benefits & Limitations

While Cosmos scales horizontally with IBC, there exist some limitations. First, tokens sent through IBC are what we call “path dependent”. What this means is that the same asset taking a different path is not fungible. Let’s go through a quick example: User A routes USDC from Chain A → B → C → D. User B from Chain A → C → B → D. Both of these users now have their USDC originating from Chain A on Chain D, but they are not fungible since they took separate paths. When a chain receives an asset from another chain it issues a “receipt” token, but the more you move these receipts through other chains, the more receipts you end up issuing on top of other receipts. While this hasn’t been a big problem yet, it will be in the future as more connections are made and is why IBC will mostly likely settle around major Hubs: zones where assets route through as their canonical path. Osmosis has already filled a role here, their liquidity pools only accept tokens that have taken direct paths from their respective chains.

Second, there are some token security implications to this model. Let’s say we have 3 chains: A, B & C. A and B trust each other and have opened channels between them. B has also opened a channel with C, deeming a connection with them to be of value. A, on the other hand, does not trust chain C and so doesn’t open a connection with them. Since B has a connection with C, tokens from A can still end up on C and will accept chains C’s security for the whole time they are there/pegged-in. If chain C validators collude, they can claim all of the pegged tokens on chain A that ended up on chain C for themselves (steal pegged assets on C → route back to B → route back to A and claim). This means that zones in the ecosystem only have so much control over the security of their tokens, as it is not only their connections that matter, but the neighbors to their connections as well (and so on). Ideally, A and B will collectively decide if C is worthy of a connection.

While IBC has some limitations, it enables exciting cross-chain capabilities. To date, IBC has mostly been used to send tokens between chains, but there are some recent & upcoming improvements.

Interchain Security: Solving the Bootstrapping Bottleneck

Interchain Security is Cosmos’ version of shared security, but there are some important differences to what we generally think of when we say shared security. On a smart contract platform like Solana or Ethereum, shared security means applications are deployed as smart contracts, sharing a single state. The biggest advantage here is that apps don’t need to worry about bootstrapping a validator set, a bottleneck present in Cosmos.

Interchain Security is Cosmos’ solution to the security bootstrapping issue. Instead of launching a normal Cosmos chain with its own validator set, projects can instead lease another chain’s validators. This chain is what is called the “provider chain” as it provides the security to the chain that consumes it, the “consumer chain”.

It’s important to note here that the tradeoff space of Interchain Security and smart contracts platforms is different. Dapps in smart contract platforms typically share the same fee market, because they all share a finite blockspace. In the interchain security solution, provider chain validators increase their resources to validate new consumer chains. While this allows consumer chains to retain independent fee markets, it does pose tighter requirements on provider chain validators.

While consumer chains have theoretically no upper bound to scaling, it is a lot more work for validators in practice and thus they may need to invest in more computers to run all these chains in parallel. In exchange for this service, consumer chains will send a portion of gas fees and token inflation to provider chain validators.

One risk here to the provider chain is centralization of validators: if it becomes prohibitively expensive to validate all the consumer chains, larger operators will start to make up a larger amount of total stake and smaller ones will drop out. This can also be a hindrance to consumer chains that do not generate enough gas fee income & may need to compensate with higher token inflation to make validating worth it.

In v1, any consumer chain that gets accepted by governance must be secured by all provider chain validators. In v2 (no timeline), individual validators will be able to opt in/out, and validators outside of the provider chain may be able to opt-in as well.

There are two types of consumer chains: contract and custom.

• Contract consumer chain: these chains run smart contract sandboxed environments (e.g CosmWasm or the EVM). While they are a lot easier for provider chain validators to assess as candidates, they do lose some flexibility. Consumer chains use the provider chain’s token (eg. ATOM) as gas. 25% of fees go to the provider chain and the remaining (~75%) go to a developer DAO, governed by the consumer chain’s own token.
• Custom consumer chain: fully customizable chain developed with the Cosmos SDK. The gas token can be the chain’s own custom token and the chain has a full custom binary, allowing devs to decide things like gas metering and how transactions are assembled in blocks. From the perspective of provider chain validators, these chains are riskier to onboard, as with unlimited possibilities there are unlimited attacks (like any standalone Cosmos app chain). Validators can isolate the risks of these chains by validating them on a separate computer (more horizontal scaling!). These chains look like a standard Cosmos app chain without the need to source their own validators.

If we consider dYdX, they started as an Ethereum L2 app-chain and are now moving to Cosmos. However, since they were built entirely in Cairo rolling up to another ecosystem, their transition to Cosmos will take extra development time. If consumer chains had been live when dYdX started and they launched as one, the transition process to their own Cosmos chain would be a much simpler process. To upgrade from a consumer chain to a standalone one, all they would need to do is get their own validators. Everything else would have already been built. Consumer chains can be seen as a way for applications that want to be their own chain to do so at their own convenience, waiting until they have PMF (and a higher market cap) to make the transition.

Interchain security is a big step for Cosmos, but it is not just a way for new chains to bootstrap. It is a way to scale features for the Cosmos Hub, finally giving it the attention it needs.

The Cosmos Hub: Security as a Service

“ATOM” doesn’t accrue value. This has been repeated ad nauseam but it is not without merit. The Hub is just another chain in IBC, which is the entire point of Cosmos, but leads to a less obvious and direct value accrual mechanism for ATOM. Layer 1 tokens (which ATOM gets compared to but is not one itself) did well in 2021 because 1) they extract rent from all the apps built on top and 2) it’s a simple mental framework to get behind. If we look at protocol revenue for ATOM it leaves a lot to be desired. (For more on L1 value accrual, you can read our previous report on it here.)

Ethereum stands alone and makes this chart basically incomprehensible when comparing other ecosystems, so let’s take Ethereum out and see how ATOM stacks up against some of the others.

So ATOM generates practically no revenue as it stands today, but we also need to be forward-looking. How will this change? To answer the question of how ATOM may accrue value we should start with the philosophy behind the Cosmos Hub.

The Cosmos Hub has always embodied a “Hub Minimalism” mindset; keep the Hub simple with as little technical risk as possible, launching Hub features on isolated chains. To better understand this philosophy we can look to the rejected Prop 69. This would have made development on the Hub easier by enabling support for CosmWasm smart contracts, but at the same time introducing new risks to the Hub as well. By rejecting the proposal and keeping the Hub minimal, it is now 100% focused (and dependent) on Interchain Security to scale, aiming to be the main provider chain in the ecosystem. The first consumer chain for the Hub will be Neutron, a “DeFi Hub” that will bring Lido’s liquid staking to Cosmos.

This is the near and long-term vision for the Hub. Security as a service, enabling feature-rich applications to launch on standalone, isolated chains. Interchain Security is not just a bootstrapping solution for consumer chains, but a scaling solution for the Hub itself, allowing it to start launching specific, more experimental and risky modules on independent blockchains. This goes far beyond what the minimized Hub is capable of. Whether they’re CosmWasm chains like Neutron, an EVM chain, or a custom Cosmos SDK app-chain, they’ll all lease security from the Hub, pushing the limit on experimentation all while keeping the Hub risk-minimized. Some of these chains may end up having more activity than the Hub as they enable a wider range of use-cases, and with that comes higher gas fees, directly accruing value to ATOM. However, gas fees are unlikely to ever be as high as “traditional” L1s, as more consumer chains can easily be spun up to spread the load. It is challenging to come up with a valuation framework for the impact consumer chains will have on ATOM before we see them live, and in the beginning, the majority of value accrual to ATOM will come not from gas fees, but from the individual consumer chain tokens themselves (i.e. airdrops to ATOM stakers).

One of the main open questions to this model for ATOM is if chains end up using the Hub for bootstrapping and then launching their own validator set in the future. If this were the case, once consumer chains developed vibrant, fee-generating economies, they would cut off from the Hub and stop paying ATOM for security. In crypto-native terms they would be “rugging the ATOM community”. This is not a near-term concern, and one that some apps will not even pursue, but it’s something to keep in mind as we see this model play out.

Over the last few years the Interchain Foundation prioritized the Cosmos SDK over the Hub, making it easy for others to launch chains and focusing on the larger vision of the Cosmos network. More recently, the pendulum has shifted with a greater emphasis being put towards the Hub, and no better way to exemplify this than the push towards launching Interchain Security. Value accrual in Cosmos will always be fairly fragmented, that is the deliberate architecture of the ecosystem, but the Hub can play a major role by being the leader of Interchain Security and by leveraging the next standard, Interchain Accounts (ICS-27).

Interchain Accounts: Bringing Composability to Cosmos

Apps being standalone chains helps with congestion and scalability, but it has a tradeoff, and that is synchronous composability: interactions between two or more different apps that occur in the same block. Smart contracts on a single chain will have synchronous composability, and this is required for certain actions like flash loans because the loan must be repaid within the same block. But how many apps actually require synchronous composability? dYdX and their perps work well on their own, and Cosmos’ asynchronous composability will work well enough for many use-cases.

One of the challenges with IBC in the past was limited cross-chain functionality. IBC uses application standards when doing specific interactions like token transfers (ICS-20) and NFT transfers (ICS-721), but what if there is no standard for an application-specific transaction? Say one chain wants to do a cross chain swap or open a loan position on another. There is no ICS for this. You would need to develop a new standard, but creating ICS takes a lot of time to develop and comes with its own risks and cannot reasonably keep up with every app-chain’s specific requirements.

This is where Interchain Accounts (ICA) come into play. ICA give chains the ability to open and control an account on another chain, allowing them to do any transaction native to that chain without needing to develop a new standard.

The analogy frequently used is that an Interchain Account transaction is a letter inside an envelope inside a box.

1. Chain A sends the box to Chain B through IBC
2. The IBC module on Chain B will open the box and send the envelope to the Chain A controlled account on Chain B
3. The Interchain Account will open the envelope, reading the letter and completing the Chain B-specific task that is required

The letter sent from Chain A is in the same format as any other Chain B transaction, thus negating the need for a new ICS and allowing Chain A to control accounts on Chain B, all without leaving Chain A. This transaction is a non-IBC transaction wrapped inside an IBC transaction, greatly increasing the composability between chains/zones and allowing for a much more scalable solution than creating new standards.

Zones can be hosts, controllers, or both. Hosts will harbor accounts from other zones, listen for IBC instructions and then execute the transactions. Controllers create accounts on host chains and manage/control them. In the graphic above, Chain A is the controller zone and Chain B is the host zone. Some examples of cross-chain composability that will be enabled with Interchain Accounts are:

• Multi-chain DAOs: DAOs can manage all of their assets from one chain but partake in activities in other ecosystems like native staking, providing liquidity with treasury assets, launching NFTs, etc.
• CDPs: users could take a loan on one blockchain using collateral on another.
• Cross-chain governance: the liquid staking platform Quicksilver will utilize Interchain Accounts to allow users who hold qAssets (liquid staking tokens) to vote on the chains where users have staked assets. Users usually give up voting rights with liquid staking tokens, but IAs can retain them.
• DeFi vaults: in a later version, Sommelier will launch on Osmosis, utilizing IAs to send strategies computed off-chain to an account on Osmosis.
• Token swaps: swapping assets on different zones using Osmosis in the background.

Really, anything we do in DeFi today, outside of some interactions that require synchronous composability, can be accomplished. Interchain Accounts also just enable a more seamless end-user experience; users don’t need to leave a chain to do activities on others. This creates a better UX and mitigates potential operational and security risks like manually transferring assets between chains, managing different wallets for different chains etc.

Interchain Accounts and Interchain Security are the two biggest catalysts in the Cosmos ecosystem to date, and composability in Cosmos has barely scratched the surface. We’ve touched on the Cosmos Hub, but there are some other potential Hubs in the ecosystem that are likely to be adopters of one or both of these primitives.

• Osmosis: The “Liquidity” Hub
• Axelar: The “Non-IBC Assets” Hub
• Juno: The “WASM” Hub
• Evmos: The “EVM” Hub

Other Potential Hubs: Osmosis, Axelar, Juno & Evmos

Osmosis

Osmosis was one of the main drivers of IBC adoption over the past year. Launched in June 2021, it quickly became the “Liquidity Hub” in IBC and amassed a TVL near $2B at peak. As a refresher, Osmosis is an AMM app-chain and we have an in-depth piece on it here. It has consistently been not only the chain with the most liquidity locked, but the chain that facilitates the most activity throughout IBC. While it was hit hard by the UST depeg, it has still facilitated more than 2x the $ volume of the next zone and the most # of transfers over the past month, handling 4x that of the Cosmos Hub.

Osmosis is likely to be a major Hub with direct connections to the majority of chains throughout the ecosystem. It is currently connected to 45 out of 47 other zones, the most in the eco and more than the Cosmos Hub at 40. If we think back to the limitations of IBC, all of the assets on Osmosis will end up being direct paths from their native chains. Why? Single path assets from their native chains will be the only pools that will be incentivized on Osmosis. Thus, this is where all the liquidity will sit and where all trading will take place.

Osmosis also has its own spin on Interchain Security coming up: Interfluid Staking. Assets deposited from IBC chains into Osmosis liquidity pools will be able to be staked and help secure their native chain.

Osmosis has more coming in the future besides being just an AMM. There are NFTs coming, order books and borrowing/lending. The first iteration to come is from Mars protocol (a Delphi Labs incubation), launching CosmWasm smart contracts on Osmosis to allow users to leverage their LP positions. While Osmosis supports CosmWasm smart contracts, they are not permissionless, but rather whitelisted by validators. More recently, Osmosis voted to onboard Axelar as its canonical bridge for non-IBC assets, and pools with Axelar assets now make up 4 of the top 6 on the chain. These are non-IBC assets bridged from Ethereum: USDC, WETH, WBTC & DAI.

Axelar

Axelar is a Tendermint-based “overlay network” built on the Cosmos SDK that supports cross chain transfers, composability of applications and general message passing between any blockchain eco. This means it can translate messages from any network to another, like an IBC message to an Ethereum message and vice versa.

As mentioned, it was voted in as Osmosis’ canonical bridge for non-IBC assets, meaning it is the default front-end for bridging to/from Osmosis from ecosystems outside IBC, and all incentivized non-IBC pools on Osmosis are Axelar assets. Meanwhile Axelar is IBC enabled by default, meaning it can connect to other chains in IBC seamlessly (currently 13 IBC peers). And now that it has been onboarded as the canonical bridge for Osmosis, it is likely it becomes the main issuer of non-IBC based assets in the entire eco. In other words, it is the current front-runner to be the “Hub for non-IBC assets”. It supports 15 chains, has done >200k transfers and ~$815M volume, the majority of which was Terra and $124M of which was the Osmosis<>Ethereum path. Axelar’s most issued asset on Osmosis is USDC, and so if Circle launches USDC as an IBC-native asset then Axelar’s position here would take a hit, but it would still be well positioned to bring in other non-IBC crypto assets and of course passing messages between ecosystems.

Juno

Juno is kind of the antithesis to Cosmos Hub minimalism. Launched as a “Sister Hub”, it is designed as a CosmWasm smart contract network. Juno had no VC raise and airdropped 47% of the genesis supply to ATOM stakers, similar to Osmosis (new chains airdropping tokens to IBC users is a common theme in this ecosystem). The right mental framework to put Juno in is a traditional smart contract/general purpose L1 using IBC to connect to Cosmos chains. Juno has been one of the pioneers to adopt Interchain Accounts. While Juno has some apps launched, it is still an extremely nascent chain (and has had some growing pains), but is trying to carve out a niche as the “WASM Hub” of IBC. While Juno will enable Interchain Security as well, it will be tough to compete against the Hub in this regard.

Evmos

On the other side of the coin we have Evmos, aiming to be the EVM Hub of IBC. This is similar to what Juno is trying to become, but with the EVM instead of CosmWasm. Evmos aims to be the EVM Hub, not just an EVM chain. This means not only having their v1 standalone EVM chain, but securing EVM consumer chains as well.

Rounding out the Ecosystem

Other notable projects in the ecosystem, both current and upcoming, are below.

• Quicksilver: liquid staking protocol, will launch with its own validators but become a consumer chain of the Cosmos Hub when Interchain Staking is live. ATOM, JUNO & OSMO will be the first chains onboarded and stakers will receive a QCK airdrop.
• Agoric: smart contract chain built on JavaScript for the 10 million+ JS devs in the world. The first application to launch on Agoric will be the Inter Protocol, a collateralized stablecoin native to IBC that works very similarly to Maker’s DAI. This will be the first major app to use ATOM as collateral in IBC.
• dYdX: derivatives exchange that migrated from an Ethereum L2 ZK-rollup to a Cosmos app-chain. Other derivatives exchanges in the ecosystem are Injective, which is live today, and Sei Network, which is not live yet but launched their incentivized testnet on July 11th.
• Saga: protocol for automatic deployment of app-specific blockchains called chainlets; smart contracts running as isolated chains. Similar to what the Cosmos Hub will offer with Interchain Security but with a focus on gaming and entertainment.
• Sommelier: automated DeFi yield vaults. Their first cellar will be an Aave stablecoin strategy, allowing users to deposit stablecoins into the cellar and then have strategists on Sommelier come up with strategies privately off-chain. In the future, Sommelier will leverage Interchain Accounts to create strategies on IBC zones like Osmosis.
• Penumbra: shielded cross-chain private by default network. Penumbra accepts any asset originating from IBC chains, acting as a shielded pool for the entire ecosystem. Penumbra is one of a few chains in the eco that do not actually utilize Cosmos SDK, instead being based on their own rust implementation.
• Stargaze: NFT chain with their own launchpad and marketplace using CosmWasm smart contracts for artists to launch collections. If we think of Ethereum, OpenSea is routinely the top gas guzzler, Stargaze isolates all of this activity to their own chain while utilizing IBC for asset transfers and communication to other chains.
• Neutron: launching as the first contract consumer chain to be secured by the Cosmos Hub. It will be a CosmWasm enabled “DeFi Hub” with its first application being liquid staking. The Cosmos Hub recently approved a 150k ATOM budget for consumer chains and 1/3 of this will go towards Neutron’s development.

The Future of Cosmos

Cosmos is entering its third phase thanks to new primitives like Interchain Security and Interchain Accounts. These are fundamental steps for cross-chain applications that not only utilize functionalities of distinct zones but also abstract away a lot of the UX complexity from users. Cross-chain composability is the new game in town.