The core thesis of Cosmos, the one that advocates for application-specific blockchains, horizontal scaling and interoperability, has been largely consistent over the years. While not always clearly expressed, it has maintained its relevance despite changing market narratives around modular and monolithic blockchain designs. In a nutshell, Cosmos provides best-in-class tools for developers to spin up a blockchain with customizable logic (using Cosmos SDK), and a fast-finality consensus engine (Tendermint). Blockchains also can connect to other chains in the Cosmos ecosystem using IBC (we covered it in more detail here) which allows trustless sending of data, tokens as well as smart contract calls, while isolating exploits to a single chain.

So now picture this: You open up your Twitter for another session of doomscrolling on a fine Sunday morning. You read appchains, IBC, light-clients, and Tendermint, and ABCI, and dydx parting ways with Ethereum. ATOM, OSMO and EVMOS are all catching a bid. This time is different, you tell yourself. Nerd inside you is roaring his head and it feels great. Seems like we’re in one of those bright moments when Cosmos captures the hive mind of Twitter again.

We initially set out to cover the scaling methods of Cosmos in depth (thanks to Chorus guys for inspiration), the value capture, and the appchains for whom this tech makes most sense. We realized cosmos has more to it than we can comprehend, so we split this work into two pieces, the first of which we’re presenting today.

Scaling: Overview and Tradeoffs

There will be several ways to deploy an application in Cosmos ecosystem:

• The first method is the tried and true horizontal scaling, where the application sets up its own blockchain (hence the “appchain”) and is responsible for bootstrapping and maintaining its validator set, meaning the economic security becomes the responsibility of an application developer.
• The Interchain Security, introduced by Cosmos Hub, will allow applications to spin up their appchains but without the overhead of bootstrapping the validator set. The validators are outsourced, i.e. “hired” from either Cosmos Hub, or other providers.
• L1s as Smart Contract platforms allow developers to deploy their application in a permissionless manner, just like they would on any other L1 (note: here we’re not considering permissioned smart contracts on a specific appchain).
• L1s providing app-specific execution environments can be regarded as modular blockchains that allow developers to easily spin up their own chains. Some of these encompass features of interchain security, while some resemble roll-ups.

The whole point is that as a developer, you choose between a) level of available customization around your application, and b) how much of the “stack” you outsource to other environments. Many of these scaling solutions are still under development, and the lines between their tradeoffs are blurry. We did our best to visualize it in the graph below, and also discuss each one of these in more depth in the subsequent sections.

What’s not emphasized enough is that these scaling solutions can be both value accretive and destructive to one another. For example, EVMOS and Celestia – both are layer-1 blockchains – intending to offer their validators for Interchain Security dilutes value proposition of Cosmos Hub; Celestia providing data availability to Saga and Dymension (both are settlement platforms) would be valuable to all three of them; and Dymension’s rollup model is challenging the necessity of “true” appchains as introduced by Cosmos Hub.

Zooming In on Scaling

Horizontal Scaling

Up until recently, scaling horizontally has been the sole option to launch in the Cosmos ecosystem. This meant starting your own blockchain from scratch, bootstrapping, maintaining the validator set, and taking care of your own economic security – no surprise this has been detrimental to application developers. As of the time of writing, there are around 50 appchains (or so called “zones”) which have opted for this approach, however, only a handful of them maintain meaningful activity.

The benefits of horizontal scaling and appchains were best laid out by Sunny from Osmosis. As an application developer, you get full freedom to choose how your application runs, as well as how the value is distributed. That is not the case if you deploy on a smart contract platform like Ethereum or Solana. Some of the appchain benefits are as follows:

• Absence of competition for blockspace, which guarantees normal functioning of the application. We’ve seen some instances on other chains, where collateral liquidations were at risk of not being completed because chain was overloaded with other, non-financial activity (e.g. NFT minting);
• Modifying the execution layer (custom virtual machines (VM), parallelized computation);
• Customizing the validator requirements;
• Customizing the transactions fees (what tokens are used to pay fees, how much gas different activities cost, etc.);
• Ordering and prioritization of transactions, MEV capture.

The most successful appchain to date (excluding that big one Terra which blew up) has been a decentralized exchange Osmosis, which leverages all the aspects of an appchain outlined above. For mature applications, appchains are attractive because they allow capture of full value they create (should Uniswap be its own appchain?), as well as help remove constraints imposed on them by a smart contract platform they’d otherwise deploy on.

That being said, there is a reason why so few successful appchains exist in Cosmos today. Given the current state of technology stack, building both a product and a blockchain simultaneously is no easy feat for early stage projects. This has been acknowledged by the Cosmos community, and the Interchain Security proposal was put out. Regardless of technical difficulties associated with running a blockchain, the bigger problem in our view is that there are very few applications in general who can stand and prove their standalone relevance (this is not unique to Cosmos though).

Interchain Security

The Interchain Security model (ICS) was revealed a year ago (although it was not ready for implementation at a time) in order to help smaller projects spin up their appchains without having to bootstrap and maintain the validators, as well as create additional utility for ATOM, the token of Cosmos Hub. The idea, as described below, is ideologically close to the shared security model pioneered by Polkadot.

ICS is going live later this year, with Neutron (we will cover it in a later section), a smart contract execution environment, renting security from the Cosmos Hub. The gist of the model is to get validators of the Provider Chain (e.g. Cosmos Hub) to produce blocks for the Consumer Chain (e.g. Neutron). These validators are incentivized because they will be receiving the block rewards and/or transaction fees from the Consumer Chain (in addition to rewards of the Provider Chain they’d normally get).

Now, it should be noted that there will be several immediate versions of ICS:

• V1, where inclusion of all validators of the Provider Chain is mandatory to produce blocks for every Consumer Chain accepted in the governance process. These Consumer Chains get full economic security of the Provider Chain because they are deemed to be strategically important for the Cosmos Hub, but logically separated for security reasons.
• V2, where the validator opt-in of the Provider Chain is discretionary. Contrary to popular belief, Consumer Chains in V2 will not inherit the full economic security of the Cosmos Hub. However, this allows ICS to support a larger number of chains because not every validator on the Producer Chain is forced to validate every Consumer Chain.

So, what are the benefits for the Consumer Chain? In V1, the benefit lies in being as secure as the Provider Chain – with over 200M of staked ATOM, it equates to >2B of economic value subject to slashing in the event of validator misbehavior. However, the application has to fit the vision of the Cosmos Hub and be enforced through governance. In V2, the Consumer Chain procures “some” economic security – which essentially would depend on a) validation difficulty, and b) economic incentives (block rewards, fees) offered to validators. That being said, we think the value proposition of V2 is watered down compared to V1, but this is necessary in order for the Cosmos Hub to be able to support more appchains.

In addition to the Cosmos Hub, both Celestia and Evmos have hinted at potentially performing the roles of a Provider Chain too. We think they’d likely compete for projects in ICS V2, i.e. those applications who are not looking to procure the full economic security of Cosmos Hub. For applications, the tradeoff here will be between “what is the level of economic security I am getting?” and “how much of the value I am giving away to procure this security?”.

ICS is part of a much broader Cosmos revamp called “ATOM 2.0” (details to be revealed at Cosmoverse conference in late September), where security is just one of the services Cosmos Hub will provide to its chains. Other services will include relayer incentives, multi-hop routing, protocol controlled value (acquiring ATOM LP tokens with ICS tokens), and should have denomination in ATOM. In addition to these services, Cosmos Hub will also act as a fund for the Cosmos ecosystem, and likely have its inflation structure reduced.

In our view, there might be several issues with ICS, however, all of them are theoretical given ICS hasn’t launched yet:

• There is a limit to how many Consumer Chains a single Provider Chain can support before running into resource constraints. Every incremental Provider Chain would have to compensate validators progressively more for them to take on this additional load.
• Validator sets generally overlap across different blockchains, so if there were several Provider Chains, it might not bring incremental scaling capacity.
• Discretionary validator opt-in (ICS V2) might concentrate validation power in the hands of a few, and crowd out the long tail of validators who can’t scale as easily.
• Validator slashing across dozens of Consumer Chains possesses risk to security of the Provider Chain.

We think ICS won’t be the sole approach to scaling in Cosmos. Vertical scaling, like rollups, could offer a superior cost-benefit balance for smaller applications, as customizable properties of an appchain (fee/gas structure, blockspace ownership, value accrual) can be maintained to a large extent, and procured at a lower cost with less overhead.

Layer-1s As Smart Contract Platforms

For projects who don’t require their own blockchain, there are several L1 supporting different VMs and providing functionality native to Cosmos such as IBC, fast finality Tendermint consensus and interchain accounts. For application developers, it’s about choosing the platform that has an adequate level of tooling, infra and support, as well as the preferred VM. We think this is where most early stage projects would land before migrating to their own appchains.

Evmos (EVM)

Evmos aims to combine the benefits of a familiar Ethereum VM with the benefits provided by Cosmos – interoperability, Tendermint consensus – hence “Evmos”. It was launched earlier this year, but so far didn’t build meaningful traction or attract novel applications.

Neutron (CosmWasm)

Neutron is the first appchain leveraging the ICS of Cosmos Hub with planned mainnet launch in 1Q23. This permissionless smart contract platform will be oriented towards interchain DeFi apps, and support CosmWasm VM. Neutron could be seen as an extension of Cosmos Hub because it will inherit the full economic security of Cosmos validators.

Rust-based CosmWasm doesn’t have as much developer adoption as EVM, but now we’re seeing it spread to ecosystems even outside Cosmos given it’s a more secure, scalable and, when combined with Cosmos SDK as its module, a more customizable VM. If a project decides to launch its own appchain using Cosmos SDK later, having used CosmWasm is better for portability than EVM.

Juno (CosmWasm)

Juno was the first permissionless smart contract platform to support CosmWasm, and has over a dozen applications deployed following its launch in 2021. Unlike Neutron, Juno doesn’t have the ICS of Cosmos Hub, so for that reason applications deployed on it won’t be as economically secure. However, Juno is leaning towards experimentation which makes it a good playground to test features, economic assumptions, etc.

Archway (CosmWasm)

Archway is another smart contract platform supporting CosmWasm, with specific focus on developer incentives. In this model, applications (and their developers) will be able to earn a significant part of the transaction fees and the inflation rewards, whereas in other networks 100% of this value would go to miners or stakers.

Other VMs

While at present there are no other mainnet VM leveraging Cosmos SDK, we think it is an interesting area to explore and something that will prove to be valuable to new types of applications. Agoric was one of the first to go in this direction, whose VM is based on Javascript, and thus accessible to a broader range of developers. A more recent example is GNO Land, a recently announced smart contract platform supporting code written in Gnolang (a form of Go).

Modular Blockchains in Cosmos

One of the more exciting developments we see in Cosmos is the launch of settlement platforms that allow developers to spin up their custom execution environments. In some way it can be likened to appchains discussed in the horizontal scaling section, and while this method does not provide an exact level of sovereignty as horizontal scaling or ICS, we think it will be a viable alternative. Also, it will have the benefit of faster deployment than ICS which is permissioned and only provides the validator set, but still requires application developers to run all other associated processes.

Dymension (settlement layer)

Dymension presents itself as a layer-1 for settlement, whose blockspace is exclusively reserved for posting state updates and data to the data availability layer. Just like on Ethereum, roll-ups inherit the security of the base layer-1 – in this case it’s Dymension.

Source: Dymension

In our view, Dymension might be the most sensible alternative to ICS. It allows roll-ups to maintain the fee logic (how and in which token they’re paid), and set economic and decentralization parameters for transaction sequencers. This method would also allow better scaling compared to the horizontal model, where validators are responsible for execution, settlement and data availability / consensus. Instead of using Osmosis, Dymension will have a native AMM embedded at the settlement layer which will facilitate swaps and oracle services for all the roll-ups built on top.

The tradeoff for developers deploying on Dymension is that the sequencers of a roll-up would have to stake Dymension’s native token to participate, and the bigger the stake, the higher the chance of being elected as lead sequencer. The MEV and fees would be kept by the sequencer, which means the more activity on the roll-up, the more incentive there is to acquire and stake Dymension’s token. This resembles the shared-security model of Polkadot, and should achieve better value capture than Cosmos Hub did in the past.

Saga (settlement + execution layer)

Saga has a similar proposition like the ICS, but it’s targeting projects that want to be on their own dedicated chains without having to go through the Cosmos Hub’s governance process to procure ICS. Saga’s validators would be validating permissionless execution environments (so-called Chainlets) that initially will support EVM, CosmWasm, and later other custom VMs (e.g. Solana’s). While it will initially start as a chain with its own execution, settlement, data availability and consensus, it might in the future outsource some of these from Celestia, or other data availability providers.

Theoretically, launching a Chainlet will be cheaper on Saga than using ICS from Cosmos Hub because the cost of deploying a Chainlet will be proportional to the infrastructure expense validators pay to run that Chainlet and not proportional to the cost of it’s shared security. However, we think Saga’s security model may still be subject to theoretical scalability limitations of ICS. Moreover, Saga’s validators will be expected to validate thousands of Chainlets simultaneously, which may require specialized infrastructure capabilities, and so potentially leading to the centralization of validators. That being said, Saga plans to address validator inclusivity by introducing variable uptime requirements for smaller validators.

For now, applications would be paying validators in Saga’s native token – not the application’s token – which is an important difference for applications deploying on Saga vis-à-vis ICS. In the future, Saga will likely allow applications to use their own tokens and directly convert them to Saga’s native token for payment to validators. All that said, Saga could be a platform for permissionless and fast iteration, especially for gaming and entertainment applications as seen in other ecosystems like Avalanche and Polygon.

Celestia (data availability + consensus layer)

Celestia has already received its fair share of accolades this year, so we won’t go into its full value proposition here. Suffice it to say that both Dymension and Saga (and Evmos) are ideologically aligned with the modular blockchain thesis, and could use Celestia (or other providers) for data availability and consensus. For appchains built on top this would make sense, as in any case, they’re only owning the execution part in the modular blockchain stack.

From Celestia’s point of view, Dymension and Saga would be “sovereign roll-ups” on Celestia, whereas execution environments on top of them would be non-sovereign roll-ups because they have “enshrinement” in the roll-up beneath them. Unsurprisingly, the Cosmos ecosystem, which has embraced sovereignty from the start, has been more receptive to Celestia’s ideas than the Ethereum community.

Different Scaling Phases Reinforce Each Other

When thinking of blockchain application’s lifecycle and deployment decisions on Cosmos, a fitting analogy would be how traditional startups develop. You don’t start a venture with an objective to own everything in-house from day 1. Speed of launch and product iteration is valuable, therefore vertical growth and integration of more processes comes progressively. It makes sense if you can make a case that it accrues value, strengthens the network effects, and makes the business more defensible.

We think we won’t see many successful appchains within a single category (e.g. concentrated liquidity AMMs or liquid staking), with the exception of consumer-ish categories like gaming or different social verticals. That’s because Cosmos appchains allow much better value capture, and it could reinforce the network effects at the expense of long-tail of projects. We can already see this at play with Osmosis and smaller DEX’es, and the same argument could be extended elsewhere – for example, to CosmWasm smart contract platforms (why would all Cosmos Hub validators risk slashing to produce blocks for two identical platforms?). This dynamic is not as acute on general smart contract platforms where applications share blockspace.

So, if you’re just another fork of something looking to drown plebs in liquidity mining incentives, why bother paying for security out of your own budget? Even if the application is building something unique, it still would be wise to save the security budget UNTIL the product-market-fit is found, rather than spend it outright. We think this is where most of Cosmos projects should start, and most of them will never move past this (that’s okay).

Next, the V1 of ICS is not designed to capture all the applications and provide infinite value to ATOM (not possible, and more importantly, not needed as we’ve seen to date – ecosystem is big and active despite direct ATOM value accrual), so in our view this leaves ICS V2 in a position where its value proposition (cost vs security) has to compete with Dymension, Saga, Celestia, perhaps EVMOS, and other modular blockchain visionaries. At the end of the day, all of these approaches aim to provide customizable blockchains to applications with a good cost-security balance. The benefits of Cosmos – IBC, interchain accounts, Tendermint consensus – are available in all instances. The decision really should come down to crude business logic around cost, and fragmentation among these approaches is inevitable, in our view.

We think the end state for the most successful applications using ICS or comparable solutions is switching to horizontal scaling (i.e. owning your validators). This allows greater flexibility around validator requirements (and thus better value capture), and predictability of security costs. Visions of Osmosis and dydx illustrate this well, and we’re bullish on appchains as a concept. However, as mentioned earlier in this article, we’ve seen very few applications, even on Ethereum, that have standalone relevance.

Burying The Cosmos Meme In The Soils of Medellín?

We don’t think ICS works as a blanket solution for all new applications, and for most that it does, not all Cosmos Hub validators will be required to participate which effectively invalidates “as secure as Cosmos Hub” proposition. There could also be unintended side consequences when validators are shared and slashed simultaneously across multiple environments. This leaves doors open for roll-ups, data availability and other solutions to compete with Cosmos Hub. Inevitably, economic security gets fragmented across security providers, as opposed to consolidated to a single point (à la Polkadot’s relay chain), which at some point might come into question and require consolidation.

That being said, we think the “great tech, bad value capture” meme of Cosmos is poised to change, but the magnitude of it is to be seen. Historically the tools available on Cosmos were always available to every appchain, which essentially means monetization of these valuable features can be enforced at the appchain level, and not Cosmos Hub. This will change at least to some extent and we look forward to the reveal of “ATOM 2.0” at Cosmoverse in Medellín on September 28. Concepts of ecosystem funding, revision of tokenomics (inflation) and discretionary Hub services denominated in ATOM (ICS being one of them) are directionally positive.

In the second part of this article, we’ll look at the most interesting applications and appchains building in Cosmos, as well as review the implications of “ATOM 2.0”.

Disclosure: Zee Prime holds Osmosis.