The Ultimate Guide to Subnets I: Comparing Subnets to Cosmos Zones and Polkadaot Parachains

18 min readOct 11, 2022

If you’re interested in Avalanche subnets and you’ve been looking for a guide to help you understand why institutions, developers, and venture capital firms are so bullish on this incredible technology then you’ve found the right place. This article provides an overview of subnets and compares them to Cosmos zones and Polkadot parachains.

Subnets in many ways are superior to a typical EVM blockchain. They support many types of virtual machines and offer sovereignty over a project’s own ecosystem, allowing entrepreneurs, investors, or creators to create their own native tokens, consensus mechanism, blockchains, and much more.

While there has been media disseminated about subnets, due to the ever changing nature of web3, resources quickly become outdated or obsolete, further adding to the confusion and lack of interest surrounding subnets. Therefore, this guide seeks to outline the current and future state of subnets in an attempt to compile an easily digestible resource for understanding the uses, advantages, and implementation of what we believe is one of the most powerful web3 tools capable of bridging traditional and decentralized systems.

Why Subnets?

One of the most common questions validators ask is; why subnets? What makes them so special?

In order to better understand why Subnets are a unique, powerful tool, its necessary to first understand the structure and function of a subnet.

Subnets are sovereign networks with their own defined rules, tokenomics, consensus mechanism and membership. Their networks are secured via a dynamic group of validators functioning to achieve consensus on the state of one or more blockchains. Within a subnet, Avalanche allows anyone to create their own custom-made application specific blockchain, supporting multiple custom virtual machines such as EVM and WebAssembly (WASM) and written in popular computer programming languages like Go (with others coming in the future) rather than just Solidity, a more recent, complex, and less-used language. This virtual machine can then be deployed on a custom blockchain network, a subnet, where complex rulesets can be configured.

The inherent nature of subnets, segmented groups of validators only having to validate the transactions on chains they are a part of, creates the potential for a powerful technical tool within web3. This model allows for reductions in network traffic as transactions on subnet blockchains are only validated by the validator nodes within that subnet. This also decreases the resources validators need, as they do not validate transactions on other chains besides the primary network and the specific subnets they are interested in. Subnets can also hold specific properties, allowing for considerable customizability, including making them private or requiring validators to be in a specific jurisdiction.

Avalanche’s vision is for thousands of subnets to form a heterogeneous interoperable network of many blockchains. This allows individuals, entrepreneurs, companies, DAOs, and more to take advantage of the revolutionary Avalanche Consensus protocols to provide a secure, globally distributed, interoperable and trustless framework, offering unprecedented decentralization whilst being able to comply with regulatory requirements if needed.

Subnets vs. Cosmos Zones & Polkadot Parachains

At first glance, subnets are quite similar to other web3 networks, namely Cosmos Zones and Polkadot Parachains. Cosmos is a heterogeneous network of independent parallel blockchains, each powered by the classical Byzantine Fault Tolerance (BFT) consensus algorithm like Tendermint (now branded to Ignite). Through the Cosmos SDK framework, developers can easily build custom application specific blockchains, called Zones. These Zones then connect to Hubs which are specifically designed to connect Zones together. Cosmos can also connect to other systems through Peg Zones, which are specifically designed Zones that are custom made to interact with another ecosystem such as Ethereum or Bitcoin. What connects all of this together is the Inter-Blockchain Communication Protocol, or IBC. This protocol is what allows transactions of value and information to be exchanged between different chains.

Polkadot, like Cosmos, is also a heterogeneous network that connects multiple specialized blockchains into one unified network. It achieves scalability through a sharding infrastructure, whereby blockchains are partitioned so that each validator node no longer has to process the entire network’s transactional load. Each validator only maintains information to its specific partition or shard. This technically allows multiple blockchains to run in parallel, called Parachains, that connect to a central chain called the Relay Chain. Decentralized applications (Dapps) wishing to build on top of a Parachain must first go through the Parachain Slot Auction, where projects bid a certain amount of DOT (Polkadot’s governance token) to be able to build on a Parachain. The reason why an auction is held is because projects do not buy themselves a parachain spot. Rather, they are leased to them for up to two years. Those with the highest bid win a slot, bond the DOT they managed to raise and Polkadot validators can begin validating the winner’s transactions.

Developers can easily build custom application specific parachains through the Substrate development framework. The Relay Chain validates the state transition of connected parachains, providing shared state across the entire ecosystem. Interoperability is enabled between parachains through either Cross-Chain Message Passing (XCMP) protocol or via bridges, which are specifically designed parachains or parathreads that each are custom-made to interact with another ecosystem such as Ethereum or Bitcoin.

While each of these networks appear quite similar each has their own idiosyncracies creating significant differences across the security, interoperability, scalability, and decentralization of each system.

Comparing Shared Security

Within web3 applications and networks, security has become a major focal point. Shared security takes that concept a step further, whereby various Dapps and projects within the same network/ecosystem share the same kind and level of security with one another. This is important because being part of a shared security means that Dapps, regardless of size, popularity and market cap, all share the same level of security on the network. There is no discrimination.

The Cosmos Hub uses the Tendermint consensus mechanism for its security. At present there are 175 active validators. However, other Hubs and Zones do exist and they do not depend on the Cosmos Hub for their own security. Every Zone and Hub has their own validator set and different trust assumptions. While this allows for significant freedom in the set up and functioning of Zones and Hubs, this decentralized form of security could make smaller Zones, with fewer validators and less resources, more vulnerable to security issues. To offset this, Cosmos will be launching its Interchain Security, where projects on their own application-specific chain have the option to leverage Cosmos’ own security Hub by leasing its validators to validate and secure their own network. This way, projects with less capital and resources will not have to spin up their own validator set and Cosmos’ Hub validators and delegators can earn additional rewards in the form of that chain’s native governance token.

Alternatively, for Polkadot, shared Security is mandatory. Polkadot uses a shared state infrastructure between the Relay Chain and all of the connected parachains. Every parachain makes the same trust assumptions, and as such the Relay Chain validates state transition and enables seamless interoperability between them. In return, projects wanting to build on top of a parachain have to purchase DOT, and win an auction for one of the available parachain slots.

However, Parachains don’t just rely on the Relay Chain for their security. Parachains must also implement censorship resistance measures and utilize some type of consensus mechanism (PoW/PoS) for each parachain. Hence, they cannot simply rely on the security of the Relay Chain, they must also ensure sybil resistance mechanisms are implemented on the parachain as well. While these requirements enhance the security of the protocol, they can also be technically and financially expensive, requiring expertise and capital to implement correctly. This can therefore be quite prohibitive to smaller, less well-funded organizations, individuals, or entrepreneurs.

Unlike in Cosmos where each Zone and Hub has their own validators and Polkadot which has a number of mandatory security requirements, a subnet can validate a single or many blockchains within a single validator set. To secure their network on a subnet, projects must be able to incentivize Avalanche’s validators through a reward system (e.g. robust tokenomics, gas feespaid to validators, help validators validate more blocks by delegating AVAX to them). Moreover, only validators who staked AVAX on Avalanche’s Primary Network (X-Chain) can participate in securing a subnet’s network, ensuring the simultaneous shared safety of the primary network as well as individual subnets in which the validator participates. While projects on both Parachains and subnets can mint their own tokens and even pay transactions with them, subnets are completely sovereign networks, with their own consensus mechanism and validating transactions outside of the Primary Network. This is great because it means subnets do not have to depend Avalanche’s own consensus for security. It gives sovereign security to each subnet. Projects on Parachains do not have that option and rely on the Relay Chain to enforce validities. Additionally, although Cosmos is building their Interchain Security, it only pre-released its version 1 which is not yet available for full adoption.

Interoperability

Interoperability is essentially the ability for two isolated blockchains (e.g., Ethereum and Avalanche) to be able to communicate with each other via exchanges of transaction value and information. In order for a blockchain’s ecosystem to reach mass adoption, it must be able to connect and communicate with other blockchains. This is vital because, due to the diversity and extreme growth of blockchain technology, it has become necessary for information and transactional value to easily transfer from one chain to another, allowing users to utilize information across a variety of chains, such as using alternate cryptocurrencies and utilizing information stored on one blockchain. For example, instead of keeping your Bitcoin (BTC) either in your wallet or on a centralized exchange like Binance, due to interoperability, users can utilize their BTC by transferring it onto other blockchains such as Ethereum or BNB Chain for yield farming, as both WBTC and BTCB respectively. Should the user wish to move their BTC elsewhere, they can use a bridge to transfer it to a new blockchain for further yield farming opportunities, thereby bypassing any centralized exchange and even ensuring the emerging DeFi sector remains decentralized. For mass adoptions of the discussed networks, interoperability is a vital component.

Cosmos connects Hubs and Zones together through its IBC protocol. Connecting to blockchains outside of the Cosmos ecosystem would either require the connected blockchain to fork their code to implement IBC or, more likely, create a custom “Peg Zone” specifically to work with the blockchain the user is trying to bridge to, such as Ethereum. Each Zone and Hub has different trust levels and thus connectivity between two zones can have different trust assumptions depending on which path it takes. Finality time, or the time it takes for a transaction to be completed, is as low as six seconds, but depending on the number of Hubs, this can increase significantly.

Polkadot’s shared state means each connected parachain shares the same trust assumptions of the Relay Chain validators. As mentioned previously, interoperability is either enabled between parachains through the Cross-Chain Message Passing (XCMP) protocol and/or through bridges, which are specifically designed parachains or parathreads that each are custom-made to interact with an ‘outside’ ecosystem, such as Ethereum or Bitcoin. Finality time between parachains is around 60 seconds, but can be longer if the chain or thread is connecting to external blockchains. This lengthy time delay limits the appeal of connecting two external ecosystems together through Polkadot. The network is also limited in the number of Parachain slots available, thus limiting the amount of blockchains that can be bridged. Polkadot can at most hold 100 Parachains. This is why auctions are also being held on Kusama, Polkadot’s sister chain, which can also only hold 100 parachains. Parathreads could be used for lower performance bridges, but it should be noted that the speed of future blockchains is only going to increase.

A subnet on the other hand can validate multiple virtual machines and blockchains. Because all blockchains within a subnet share the same consensus mechanism and validators, this enables cross-chain interoperability. Interoperability is also possible between other subnets. Each subnet may have a different trust level, but as all validators are required to also validate the primary network, this creates a minimum source of trust. As Avalanche supports many virtual machines, bridges to other ecosystems are created by running the connected virtual machine. Finality time is much faster than other networks, at sub 3 seconds (with most happening under 1 second) with no chance of rolling back, making the subnet model more appealing when connecting to external blockchains. However, interoperability between subnets is still in its infancy. And while Ava Labs is currently developing interoperability, at present, the approach for communication between different subnet and even main net is the utilization of bridges on the C chain bridges.

Scalability

Scalability in blockchain technology simply means the speed of which a blockchain is able to process transactions. For Bitcoin, the network can process around 7 transactions per second (tps), while Ethereum, its current Proof-of-Work consensus, can process up to 15 tps. Clearly this is nowhere near fast enough for mass adoption, especially for Ethereum. By comparison, VISA can process up to 1,700 tps, making the company more suitable for mass adoption.

The Cosmos Hub can theoretically run up to 10,000 transactions per second (tps), although with only 175 active validators, it can more realistically handle around 4,000 tps. However, this is only the Cosmos Hub. Since Cosmos is designed to scale horizontally (e.g., with users adding additional Hubs and Zones), other Hubs and Zones can be created, each with their own scaling capabilities. In addition, Cosmos has been working on vertical scaling solutions that will allow each Hub and Zone to now scale vertically. This means that instead of creating more Zones and Hubs (horizontally), each can increase their speed (vertically), thereby increasing the ecosystem’s scalability as a whole substantially. Interchain Security is one feature, but dYmension and Celestia are also two other vertical scaling solutions that Cosmos is working to implement.

Currently, Polkadot is capable of up to around 1,500 transactions per second. Parachains Slot Auctions are still ongoing, but as more Dapps win slots and their parachains are plugged into the Relay Chain, each parachain will be coordinated by the main chain. As these parachains are their own specific blockchains with specific applications, they run in parallel with each other. This means that if transactions on one Parachain becomes congested, it will not affect other Parachains. While it is not yet determined, Polkadot can theoretically scale up to tens of thousands of transactions, if not even hundreds of thousands transactions per second.

While, theoretically, this relatively large tps for parachains is quite appealing, a portion of the parachain slots on the Relay Chain will be designated as part of the parathread pool. This means the performance of a parachain will be split between many Parathreads, offering lower performance and requiring parathreads to compete amongst themselves on a per-block basis to have their transactions included in the next relay chain block. This means that unless the rewards from a parathread transaction are lucrative enough, some transactions may potentially fail to be included in the block. This can create a significant financial barrier for applications or organizations interested in building on Polkadot. Additionally, as previously mentioned, the number of parachains is limited by the number of validators on the Relay Chain, which only allows for 100 parachains. Both barriers can potentially hinder Polkadot’s scalability performance.

Avalanche’s Primary Network is capable of around 4,500 transactions per second (tps). This is based on modest hardware requirements to ensure maximum decentralization with a validator size capability of over 2,000 nodes, although around 1,300 validators are active at the moment. However with subnets, there are no specific rules (and thus no limitations) on how much a subnet can scale. It is up to the project to mold a subnet in a way that meets its scalability needs. Unlike with Cosmos, there is no need to wait for a specific upgrade from Ava Labs to allow a subnet to scale. Projects can even utilize certain tools, such as ZK & optimistic rollups, to upscale its speed. Additionally, unlike with Polkadot, there is no limit on the number of Subnets that can be created and the timeline deployment for one is only around 30 seconds! Watch an actual deployment of a Subnet here.

Decentralization

In blockchain, decentralization refers to the transfer of control and decision-making from a centralized entity (individual, organization, or group thereof) to a distributed network. Unlike a centralized network, a decentralized network has no single point of failure, making it that much harder to corrupt. In addition, decentralized networks strive to reduce the level of trust that participants are required to place in one another, and deter users ability to exert authority or control over one another in ways that degrade the functionality of the network.

A major proponent of decentralization is the consensus mechanism found in PoW and PoS cryptocurrencies. Theoretically, anyone can buy PoS cryptocurrency, stake it and set up a validator node and process transactions to earn rewards. This is further facilitated by the relatively minimum hardware requirements needed to setting up your own node, at least when compared to PoW networks like Bitcoin. Yes, the minimum staking threshold needed to connect your node can be very high, but this is offset by the ability for validators to attract delegators to delegate their PoS crypto with them, increasing their staked threshold, for a share in the rewards. Taken together, this is an integral component to web3 development, and, by extension, the networks discussed within this guide. Supporting secure, trustless, and fair interactions without limitations is a concept web3 applications continually strive for.

Tendermint (Ignite) consensus is limited to only around 200 validators before performance starts to degrade. Although this makes the Cosmos security Hub rather centralized, this limitation is only confined to the Cosmos Hub itself and not the entire ecosystem. The Cosmos Hub is one of many hubs in the network and there is no central hub or limit on the number of Zones or Hubs that can be created. Moreover, projects that utilize the Cosmos SDK framework to build application-specific blockchains allow them to retain their own sovereignty. This means that Dapps can have their own consensus mechanism, governance token, and can run their own set of validators and delegators without limits.

As previously mentioned, Cosmos will be introducing its Interchain Security, giving Dapps on their own chain the option to leverage additional security. However, this is a double-edged sword. While it benefits Dapps in small Zones with fewer resources to bootstrap validators to leverage Cosmos Hub’s for more security, this can make Cosmos Hub’s a potential central point of failure. Should the Cosmos Hub ever suffer an attack/exploitation, it could endanger Dapps on other chains who depend on it for their own security for validating transactions.

Polkadot has 297 validators in the Relay Chain, all of which are tasked with supporting all connected parachains & parathreads. As such, this makes the Relay Chain the de facto securer of Polkadot’s entire ecosystem. This centralization of security can be a potential point of failure since all parachains are essentially dependent on the main chain. Further, Polkadot’s small number of active validators can further hinder its efforts to be decentralized as the chances of a coordinated, malicious attack by a few validators is more pronounced. While there is no specific minimum amount of DOT validators needed to stake, the minimum requirement is dynamic and can change over time. The staking requirement is largely dependent on not only how much DOT each validator is currently staking, but also on the size of the active set of validators and how many validators are waiting in the pool. In other words, as more validators nodes are set up and/or those already active accumulate more DOT, the amount of DOT necessary to set up a validator node can increase over time, further hindering Polkadot’s ability to become decentralized. Additionally, Polkadot only plans to house 1,000 validators in total to secure its ecosystem. While that number is significantly more than 297, it is still much smaller than what many may consider to be ‘sufficiently decentralized’.

Further, due to the limited number of parachain slots available, Dapps wishing to win a parachain slot need to collect significant sums of DOT in order to outbid its competitors. Acala Network for example, raised a total of 32 515 980 DOT (worth $235 090 537 at the time of writing this article) to win a parachain slot. Litentry had to raise 943 842 DOT ($6 805 101 in today’s prices) in order to win its own slot. These are significant sums that few projects are currently able to raise.

Adding to the concern, parachains are not bought, but leased for up to 24 months (2 years). After that timeline, projects will need to go through another auction round in order to collect the necessary amount of new DOT should they wish to continue working on their respective parachain. Should the project fail to raise the necessary DOT, they could see their Dapp being kicked out of their parachain and given to a new project that outbid them.

This makes the process not only quite expensive, it also squanders a project’s limited resources, which can be used elsewhere, while potentially putting its security at risk. While Parathreads can be an alternative for investors or entrepreneurs who do not have the funds to secure a parachain, they typically have lower and more varied performance when compared with parachains which limits the allure of this option.

Overall, Polkadot’s limited number of validators, Parachains dependence on the main chain and expensive process to obtain a spot in their ecosystem limits their decentralization and can push a lot of projects to seek alternatives elsewhere.

Fortunately, subnets can provide a simpler, cheaper solution. Avalanche’s consensus protocol can scale to tens of thousands, potentially millions, of validators, all participating in consensus through repeated sub-sampling or Gossiping. The more validators there are, the faster the network becomes as the load can be easily split between all available validator nodes.

With more modest hardware requirements, anyone can run a node and there is no limit on the number of subnets, blockchains, or virtual machines that can be created. However, the requirement to stake at least 2,000 AVAX tokens on the Primary Network to run a validator node can be expensive (although less so than winning an auction on Polkadot).

At the time of writing this article, validators will need to stake $41,120 USD worth of AVAX. As only validators who staked on Avalanche can help secure a subnet, this can limit the number, frequency of creation, and reach of the subnet model. With the implementation of protocols like GoGoPool, however, which provide liquid staking opportunities to validators, this financial burden can be significantly decreased.

Nevertheless, subnets can be constructed with a vastly diverse array of capabilities and independence. They can be coupled with Avalanche’s Primary Network, or be completely sovereign, public or private, and although validators are required to first stake on Avalanche’s Primary Network, projects on subnets can set their own standards and requirements validators need to meet before they can participate.

Additionally, whereas Cosmos SDK allows the development of one specific blockchain per Zone, subnets can validate more than one blockchain. This means that a subnet can grow to be composed of many blockchains, potentially becoming an entirely new and independent ecosystem.

Avalanche provides subnets with a ready supply of validators who can easily plug their node on to a subnet to begin validating transactions, unlike dapps building on top of Cosmos who have to bootstrap validator nodes.

Unlike Cosmos’ structure, Avalanche ensures that subnets, its validators and the Primary Network are all interconnected and benefiting each other while not sacrificing a subnet’s sovereignty.

Finally, unlike Polkadot’s burdensome requirements, Avalanche’s only requirement for a subnet is to utilize validator nodes who have staked AVAX on its Primary Network.

This is where protocols like GoGoPool can become crucial players within the subnet sector. Similar to Lido Finance, GoGoPool is a decentralized liquid staking protocol that specializes in offering liquid staking solutions for subnets.

GoGoPool aims to solve three recurring problems. First, it can help validators who are struggling in meeting the 2,000 minimum required AVAX by matching half of that amount from liquid staker funds. GoGoPool essentially becomes the go to ‘meeting place’ for validators and retailers/delegators. This can increase the reach and availability of validators, which, as previously mentioned, will enhance the interoperability, decentralization, and security of Avalanche’s ecosystem.

Second, GoGoPool offers to help build crucial open-source tooling needed to make all the plug-ins on Web3 work as smoothly as in Web2.

Third, it directly contributes to the creation of a lively and decentralized community to participate in and further enhance the current ecosystem for subnets.

GoGoPool aims to be the linchpin that is going to not only secure and interconnect Avalanche’s entire subnet ecosystem, but become the launchpad for subnet’s mass adoption.

Summary

To summarize, Avalanche’s subnets offer a far more robust, limitless, and sovereign regulatory compliant network. While Cosmos’ SDK, zones and hubs offer many of the same features as subnets, Cosmos’ application-specific blockchains are meant for each project/Dapp to have their own blockchain.

Subnets can hold and validate multiple blockchains, becoming an entire ecosystem to themselves. In addition, subnets can be as completely independent from Avalanche’s Primary Network as they need to be. The same cannot be said with Polkadot’s parachains, whose whole ecosystem is reliant on its Relay Chain validating and securing them. Plus, subnets already offer sovereign flexibility whereas Cosmos is only now just in the midst of pre-releasing its Intechain Security. Most importantly, by making it a requirement for all validators to stake on its Primary Network, Avalanche is providing subnets with a pre-established pool of validators who can easily connect with subnets to begin securing their network. Very little bootstrapping is required and while parachains, zones and hubs are also customizable, they offer little in the way of making their ecosystem regulatory compliant.

Avalanche’s subnets are so flexible that projects can mold their network to make them compliant with regulations, even making them permissioned/private, should it be required.

For more helpful information about subnets check out the links in the section below.