Key Terms
Key Terms | |
---|---|
Subnets | A dynamic set of validators working together to achieve consensus on the state of a blockchain or set of blockchains. |
DAG (Directed Acyclic Graphs) | A data structure that gives a partial ordering of decisions. |
App-chain | An L1 blockchain focused on a specific vertical. For instance, Crabada is an app-chain focused on a crab-themed play-to-earn game. |
Shared Security | Refers to when all apps on a chain inherit the base security of the layer 1. On Ethereum, apps such as Aave inherit the security assurances of Ethereum. On Polkadot, parachains such as Moonbeam inherit the base security of the relay chain. |
Snow* family | A family of consensus protocols used by Avalanche. Avalanche, Snowball, Snowman, and Frosty all belong to the Snow* family. |
Inter Blockchain Communication (IBC) | A generalized messaging protocol that allows for blockchain to blockchain interoperability. Made up of many parts: Base layer - Tendermint BFT consensus chains. Transport layer - permissionless relayers from source to destination chain. Authentication layer - light client verification. Interface layer - IBC Data packets |
What is the core thesis on Avalanche?
Avalanche is a network of networks consisting of subnets, that came into the scene in order to provide a high-performance, scalable, customizable and open-source platform for launching public and private decentralized applications.
It focuses on three main use cases:
- Building application-specific blockchains (app-chains), spanning permissioned (private) and permissionless (public) deployments.
- Building and launching highly scalable and decentralized applications (Dapps).
- Building arbitrarily complex digital assets with custom rules, covenants, and riders (smart assets).
It all started when in 2018, a pseudonymous group calling itself Team Rocket introduced a novel family of consensus protocols; this became the foundation of the Avalanche Consensus Protocol. An improved version of this paper was then published (Scalable and Probabilistic Leaderless BFT Consensus through Metastability ), which introduced the Snow protocol family, demonstrating that the system can achieve a high throughput of 3400 tps, a low confirmation latency of 1.35 sec and much better scalability compared to other existing systems.
Consensus
The Snow* family of protocols, introduced by Avalanche, combine the best properties of classical consensus protocols with the best of Nakamoto consensus. They achieve low latency and high throughput via a lightweight network sampling approach that eliminates the requirement to agree on the system's exact membership. They can scale well to thousands of participants with direct participation in the consensus protocol.
Nakamato | Classical | Snow* | |
---|---|---|---|
Robust (Suitable for Open Settings | + | - | + |
Highly Decentralized (Allows Many Validators) | + | - | + |
Low Latency and Quick Finality (Fast Transaction Confirmation) | - | + | + |
High Throughput (Allows Many Clients) | - | + | + |
Lightweight (Low System Requirements) | - | + | + |
Quiescent (Not Active When No Decisions Performed) | - | - | + |
Safety Parameterizable (Beyond 51% Adversarial Presence) | - | - | + |
Highly Scalable | - | - | + |
Source: Comparative Charts of Consensus - describes the differences between the three known families of consensus protocols through a set of 8 factors. Avalanche, Snowball, Snowman, and Frosty all belong to the Snow* family.
The Snow* protocols operate by repeated sampling of the network. Each node polls a small, constant-sized, randomly chosen set of neighbors, and switches its proposal if a supermajority supports a different value. Samples are repeated until convergence is reached, which happens rapidly in normal operations. When conflicts exist, honest validators quickly cluster around conflicting transactions, entering a positive feedback loop until all correct validators prefer that transaction. This leads to the acceptance of non-conflicting transactions and the rejection of conflicting ones.
In more detail, it works as follows:
- A validator is presented with a set of transactions that have been issued and asked to decide which transactions to “Accept."
- The node client presents the virtual machines (“VMs”) with their transactions, and the VMs will provide information to help the client determine which transactions are acceptable.
- The validator selects a subset of these transactions that do not conflict, marks them as preferred, and attempts to accept them over the network.
- Any nodes that query this validator receives its latest preferred choice for this decision.
- This validator selects K nodes from the entire validator list (probability of selection is weighted by stake amount) to query for their preferred decision.
- Each queried validator responds with their preferred decisions, the validator’s votes are updated accordingly, and confidence is built.
- Meanwhile, other nodes are also selecting random validators from the validator set to be queried for their preferred response and updating their answers accordingly.
- This continues for at least M rounds or until a sufficient confidence threshold is reached, whatever comes last, with K validators selected randomly each round (without replacement).
- Once a confidence threshold is reached, the decision on the transaction is locked in as final.
- If “Accepted”, the transaction is sent to the VM to be handled; if “Rejected”, the transaction is removed from consensus.
More info can be found here.
It is also important to note that both Bitcoin and Ethereum, for example, have a linear chain where every block has one parent and one child. Avalanche uses a DAG (Directed Acyclic Graphs)to store data rather than a linear chain. Each element of the DAG may have multiple parents. The parent-child relationship in the DAG does not imply an application-level dependency.
The following image shows a graphical representation of how the consensus works.

Furthermore, the Avalanche protocol uses a proof-of-stake consensus algorithm instead of PoW mining. According to a study by the Crypto Carbon Ratings Institute, it consumes the equivalent energy of only 46 US families annually, compared to 1.6 million US households for Ethereum. The Ava Labs team also purchases carbon credits to offset the emissions.
Platform
Avalanche features 3 built-in blockchains: Exchange Chain (X-Chain), Platform Chain (P-Chain), and Contract Chain (C-Chain). All 3 blockchains are validated and secured by the Primary Network.
- X-Chain: (Exchange chain) for creating and exchanging digital smart assets e.g. a representation of a real-world resource like equity and bonds, with a set of rules that govern its behaviour (like "can’t be traded until tomorrow" or "can only be sent to US citizens").
- P-Chain: (Platform chain) enables the creation of subnets, coordinates validators, and manages metadata of the entire Avalanche ecosystem.
- C-Chain: (Smart contract chain) EVM-compatible smart contract chain where the majority of Avalanche applications are built on.
More information on subnets is covered on the scaling section below.
Lastly, due to the recent advances of quantum computers, a lot of concerns have been raised about the cryptography used to build blockchains.The concern with quantum computers is that they can break some of the currently deployed cryptographic protocols, specifically digital signatures. Avalanche’s design is able to support various types of VMs, as a result, it would be able to extend the architecture with a new virtual machine that provides quantum secure cryptographic primitives, if/when that scenario plays out.
Scaling Roadmap
Subnetworks or subnets are a scaling solution which were introduced to Avalanche, in order to allow the chain to scale horizontally. These can be compared to different scaling solutions implemented by various chains (e.g Polkadot’s parachains or Cosmos’ Zones).
A subnet is essentially a dynamic group of validators that collaborate to reach consensus on the state of a set of blockchains. Each blockchain is validated by one subnet, but a subnet can validate an unlimited number of blockchains. A validator can belong to as many subnets as they want. Also, all validators must validate the primary subnet (which consists of the P, X and C chains). Additionally, a subnet has the power to determine who is allowed to join it and may impose specific requirements on its constituent validators.
The Avalanche platform allows you to create a new subnet or join an existing one (as long as you meet the requirements), by charging you a fee denominated in $AVAX.
Chain | Transaction Type | Transaction Fee (AVAX) |
---|---|---|
P | Create subnet | 1 |
P | Create subnet | 1 |
P | Add Validator | 0 |
P | Add Delegator | 0 |
P | Import AVAX | 0.001 |
P | Export AVAX | 0.001 |
X | Send | 0.001 |
X | Create Asset | 0.01 |
X | Mint Asset | 0.001 |
X | Export Asset | 0.001 |
C | Simple send | >=0.001575* |
(*) C-Chain gas price varies. See below. Source: Avalanche Fee schedule
At present, it is also necessary to stake at least 2000 AVAX on the Primary Network to be a validator.
Furthermore:
- Subnets are free to choose which virtual machine to build their blockchain with. This can be the EVM, Avalanche Virtual Machine (AVM), or any other custom VM the blockchain desires.
- There can be multiple VMs within a subnet.
- In addition, subnets can choose which token(s) are required for transaction fees, including their own token (which should drive additional value to it).
- Subnets may be public or private blockchains. In addition, subnets can have requirements for validators such as KYC/AML and even hardware.
Security
- Subnets do not receive shared security like Polkadot. They can decide and execute their own level of security.
- Subnets will have varying security assumptions (similar to Cosmos Zones). All security is not created equal.
- Subnets need to incentivize Avalanche validators to validate their subnet. Subnets have complete control over how they would like to incentivize validators. This will likely be the native token in many cases.
- Validators (who validate multiple subnets), will therefore be able to receive revenue streams from multiple tokens, enhancing their APR. This is important, as the more validators each subnet receives, the greater the security.
- That said, subnets are not optimized for security (although they can still attain it). Subnets introduce some centralization risk. Subnet creators can add malicious nodes and remove benevolent validator nodes to gain control of the subnet. This risk will be greatest when the creator is anonymous. Doxxed and well-known administrators will have a much lower risk.
- It will be interesting to see how pertinent these risks are in practice, and what the Avalanche ecosystem does to address/mitigate them. It appears that although it is relatively easy to set up and deploy a subnet, those that do will require the necessary resources to ensure its security.
- It is likely that there will be a marketplace(s) for matching validators with subnets.
Interoperability
- For blockchains within a subnet, a general cross-chain mechanism exists, as demonstrated in the Primary Network with the interaction between the C-Chain and X-Chain. However, custom VMs would need to implement this. Further, smart contracts can not access it (given it is outside of the EVM).
- EVM subnets should be able to communicate using trusted bridges.
- There is no stated method for subnet-to-subnet interoperability yet. It has been speculated that the Avalanche Primary Network may act as a bridge between subnets, although this is not confirmed.
- Subnet-to-subnet interoperability is problematic due to no shared security and various trust assumptions required. Bridges between various subnets will vary on their security depending on the # of overlapping validator sets of the two connected subnets - the more overlapping validators, the more secure due to economic incentives.
- IBC adoption speculation. There is no official confirmation about this, however, Kevin Sekniqi (COO and Chief Protocol Architect) arguably hinted that this is something Avalanche are considering/planning for.

Quick Comparison with other chains
Avalanche | Polkadot | Cosmos | |
---|---|---|---|
Model | Subnet model - requires incentivizing a subset of Avalanche validators. | Sharded model - shards are called ‘parachains’. Relay Chain validators independently verify parachain blocks | Zones are responsible for securing themselves - security varies for each Zone. |
Security | Each subnet is responsible for incentivizing its own security. | Parachains all share the same security. | Each zone (a chain on Cosmos) is responsible for its own security - connecting to other chains introduces additional trust assumptions of the other chain’s state. |
Interchain Communication | Subnet-to-subnet communication is unclear as of now. Communication within a subnet is enabled. However, custom VMs need to implement Avalanche’s general cross-chain messaging. | Polkadot will use XCMP for messaging between parachains. Supports messaging between arbitrarily different blockchains. | Zones communicate with each other via IBC, allowing data packets to be sent between zones that allow for multiple modules: token transfers, Interchain accounts, NFT transfers and more. |
Incentives
Avalanche has launched a $290m Incentive Program to incentivize the adoption and growth of subnets, across all ecosystems including gaming, DeFi, institutional, NFTs and more.
A comprehensive report on subnets can be found here.
What are the tradeoffs in its design/approach?
The Avalanche model presents various advantages in comparison to solutions implemented by other chains. The flexibility allows validators to pick and choose which subnet to validate for example. This is in contrast to some other chains where each validator is required to validate every single transaction. As a result the resources required by validators validating only one subnet will be different than one validating numerous ones.
An additional benefit of this flexibility is the ability to create private subnets, as each subnet will have the power to decide who may join them. So blockchains within a subnet can be validated by a set of trusted validators if they wish to do so. Of course there could be many instances where certain projects will prefer this set up for compliance reasons or as it will fit their business model better. For example, a subnet could require its validators to meet certain requirements (e.g. be located outside a certain jurisdiction, hold a certain license etc.) or be bound by some real-world contract.
Furthermore, the lack of shared security between subnets is good in one part as different projects require different security levels/guarantees, but it also means that each subnet is responsible for securing its own chain (through a native token) and must be able to attract a diverse set of validators.
The main worry is of course the level of decentralization these subnets will have. This will depend on many factors such as the number of diverse validators, staking incentive structure, token distribution etc.
It is also important to note that if IBC is implemented for interoperability, connected subnets will have to trust the security assumption of each other. So if a subnet is compromised, its assets on any other subnet will be worthless. Thus, each subnet will have to evaluate and decide on the level of interoperability they allow, which could potentially hinder the development of composable applications and services. The good thing is that subnets that are not connected to the compromised subnet will not be affected, hence the wider Avalanche ecosystem will continue running as usual.
It is also worth mentioning that this model supports various types of VMs to be implemented, as a result, it would be possible to extend the architecture with new types of virtual machines as the tech develops. For example, a VM that provides quantum secure cryptographic primitives as mentioned earlier.
AVAX Token
The AVAX token is the native token of the primary network. Unlike ecosystems such as Polkadot and Cosmos which have an inflationary supply, AVAX is hard-capped at 720,000,000 and all transaction fees are burned which should make it a deflationary asset in the future. While capped, AVAX emissions is still governable. The rate at which the maximum cap is reached is subject to governance.
One purpose of AVAX issuance is to reward nodes that secure the chain. By initially putting up a stake and then actively engaging in the consensus process, a node receives AVAX rewards. The uptime and response latency of nodes are directly related to their payouts. In other words, in Avalanche, rewards are distributed according to proof-of-uptime and proof-of-responsiveness, giving everyone a fairer method at receiving reward distributions. Additionally, unlike PoW mining, participants are not subject to any "luck" factors. Such a reward scheme prevents the creation of mining or staking pools, allowing for greater decentralization and network participation.
The transaction fee in Avalanche is determined by a globally verifiable fee-function rather than by the transaction issuer. Fees increase as the network becomes more congested. The function is updated at the end of a set period of time to account for any increases in network transaction volume.
Transaction fees in Avalanche also vary depending on the type of transaction. The most expensive fees are for the creation of new subnets. Other forms of transactions, such as basic AVAX payments, on the other hand, have a much lower cost. Transactions in other subnets may pay fees in the native token of that subnet, as well as a portion in the AVAX token. It is up to the creator of the subnet to choose a fee structure that incentivizes validation for open, permissionless subnets.
ELI5 the Avalanche Ecosystem
Avalanche is a modular blockchain platform where builders can build highly customizable blockchains on top of it. Builders can choose to create subnets to meet their requirements - be it permissioned or permissionless with complex rule sets, or they could simply join a subnet and utilize the shared security within that subnet (security is not shared across different subnets). Avalanche promises powerful scaling potential with fast transaction times thanks to its subnets and Snowball algorithm which is a building block of Avalanche consensus.
Avalanche’s subnets are not a single blockchain. Instead, it is a set of validators that decide on the state of one or more blockchains built on the respective subnet. Each subnet can have multiple blockchains, but each blockchain can only belong to one subnet. These subnets can validate blockchains with different virtual machines - Avalanche X chain uses Avalanche virtual machine, while the C-chain uses Ethereum virtual machine. Subnets can include multiple blockchains, different virtual machines, rules, and requirements.
Avalanche is also extremely scalable as there are no limits to the number of subnets. Hence one can create multiple subnets in order to scale the network. The only resource needed in creating additional subnets are validators on the primary network.
Top market participants and protocols
As gas fees were starting to become unaffordable for most users on Ethereum during the summer of 2021, people started flocking into Avalanche for its cheap gas fees, high throughput, near-instant finality, and of course the juicy liquidity mining incentives. The announcement of a $180m DeFi incentive program titled Avalanche Rush in August 2021 successfully kickstarted the beginning of a flourishing Defi ecosystem on the Avalanche network. Besides Avalanche native DeFi protocols participating, blue-chip protocols like Aave, Curve, and Sushi also joined in. Check out the comprehensive list of projects building on Avalanche here.
In March 2022, the Avalanche Foundation launched Avalanche Multiverse - an up to $290m incentive program to accelerate the growth and adoption of its novel “subnet” functionality. The program will be focused on supporting ecosystems like blockchain-enabled gaming, DeFi, NFTs and institutional use cases. In fact, both DeFi Kingdoms and Crabada have already launched their respective sub-nets. Additionally, Ava Labs will be collaborating with Aave Companies, Golden Tree Asset Management, Wintermute, Jump Crypto and others to build the first horizontally-integrated blockchain, specifically engineered for Institutional Defi with native KYC functionality. This will enable regulated institutions to leverage the power of subnets to access DeFi primitives at scale and accelerate the institutional adoption of Defi.
DeFi
Trader Joe (Website /Twitter)
Trader Joe is an Avalanche native AMM DEX with lending/borrowing capabilities (Banker Joe), Launchpad (Rocket Joe), and NFT marketplace (Joepegs). At the time of writing, the protocol has $381m in TVL.
Platypus Finance (Website/Twitter)
Platypus Finance is an AMM for swapping stablecoins with tight spreads and low slippage. The protocol achieves this by having single-sided open liquidity pools that enables higher capital efficiency compared to its competitors like Curve.
Yeti Finance (Website/Twitter)
Yeti finance is a decentralized borrowing protocol built on Avalanche. Users can borrow against their staked assets, LP tokens or base assets up to 97% LTV in YUSD (protocol’s overcollateralized stablecoin pegged to USD) interest free. Users can therefore continue earning their farming and staking rewards while unlocking further liquidity with YUSD.
Benqi Finance (Website/Twitter)
Benqi FInance is a borrowing and lending protocol with AVAX liquid staking capabilities. This allows users to stake their AVAX for yield and in return receive sAVAX where they can freely utilize it within other DeFi protocols. At the time of writing, the protocol has $376m in TVL.
Yield Yak (Website/Twitter)
Yield Yak is an auto-compounder that automatically sells your farmed reward tokens and compounds it into your principal asset. The protocol charges 5-10% of the reward tokens as fees. There are however no deposit or withdrawal fees.
NFTs/GameFi
Crabada (Website/Twitter)
Crabada is a fully decentralized play-and-earn idle game where players need to first acquire 3 crab NFTs and can earn the in-game currency TUS by either mining or battling other players. The game has launched on the Swimmer subnet where the native gas fees are denominated in TUS.
DeFi Kingdoms (Crystalvale) (Website/Twitter)
DeFi Kingdoms is a play-to-earn MMORPG with fantasy pixel art built on a DeFI protocol. The game features DEXs, liquidity pools, and a market of rare, utility-driven NFTs. The game has also launched its own subnet known as the DFK chain and uses CRYSTAL as its native gas currency.
NFTrade (Website/Twitter)
NFTrade is a decentralized cross-chain NFT platform, marketplace, and aggregator.
Onramps
Because the Avalanche Network is EVM compatible, default wallets like Metamask can be used seamlessly. The easiest fiat onramp is to buy USDC or AVAX off of a CEX like Binance or FTX and send them to your Metamask wallet via Avalanche C-Chain withdrawal. Don’t forget to visit Chainlist to add the Avalanche C-Chain RPC too.
Bridging from Ethereum
There are many bridge options when trying to move funds between Ethereum and the Avalanche Network but the native Avalanche Bridge is the most popular. If users bridge more than $75 worth of any token, they’ll receive an AVAX faucet airdrop for gas too. Additionally, the native Avalanche Bridge now supports bridging native Bitcoin. However beware that BTC bridging is only currently available through the Core Browser Extension wallet and Metamask is NOT supported. One can also use Synapse, allbridge, or Multchain.
Bridging to Swimmer Network (Crabada)
The native token used on the Swimmer Network will be TUS. Users can easily bridge over CRA or TUS tokens via LayerZero or cBridge (Celer Network).
Bridging to Crystalvale (DeFi Kingdoms)
In order to bridge to Crystalvale, users need to visit the native bridge here that allows you to move from the Avalanche chain to the DeFi Kingdoms chain. A small amount of gas ($CRYSTAL) will be airdropped for free too.
Trust/Security assumptions
All blockchains within a subnet share security. However security is not shared between different subnets. The more overlapping validators between two bridged subnets, the higher security guarantees given the economic interests of both subnet validators to not act malicious.
What would cause Avalanche to fail?
If the market returns to a single-chain environment dominated by Ethereum 2.0, alternative networks like Avalanche and Solana would likely lose prominence. This is assuming, of course, that Ethereum 2.0's launch and scaling plans (Sharding / Rollups) are a huge success. The highly acclaimed subnets of Avalanche are a crucial feature. If these subnets fail to provide as expected, Avalanche's primary advantage may be compromised.
As Avalanche scales with the addition of subnets, the value accrual back to AVAX becomes more convoluted. The play to earn game Crabada used to burn a lot of AVAX as gas prior to launching its own Subnet (Swimmer Network). But since the release of Swimmer Network, C-Chain transactions have fallen off a cliff and gas usage has been significantly reduced.

In return, Swimmer Network will be running 12 validator nodes and each validator node will require 2000 AVAX to be staked. This results in a one time buy pressure for the AVAX token while long-term value accrual is largely unknown.
Furthermore, not implementing a proper solution that allows for interoperability between subnets could be detrimental to the project's long-term success.
What would cause Avalanche to succeed?
Avalanche's success is dependent on the success of its subnets; therefore, for the platform to succeed, these subnets must be as good as Avalanche has been promoting them. Similarly, in the future, the modular blockchain narrative must play out. If these two requirements are met, along with Avalanche's low time to finality (“TTF”) and high transaction throughput per subnet, Avalanche will be the ultimate platform of platforms comprised of many blockchains.
How Avalanche could expand its subnets deployment:
Expansion of Avalanche Gamefi Projects
- Avalanche’s subnets are its core competitive advantage over its incumbents. These subnets are highly advantageous due to their high levels of flexibility and customizability. Coupled with low TTF and interoperability with other subnets, this design is extremely attractive to enterprises and projects that require such levels of customization. - For example, GameFi projects will be drawn to Avalanche as they can set their own parameters for their own chains. Also, by leveraging Avalanche’s modular blockchain design, projects will be able to reduce on-chain congestion and improve the final user experience. Examples of high quality games that have been built on Avalanche include [Crabada](https://www.crabada.com/) and [Ragnarok](https://twitter.com/avalancheavax/status/1495805690241331204?lang=en).
Onboarding of institutional projects
- Since the start, Ava Labs have always had enterprise adoption in their sights. Institutional projects are likely to require higher levels of customization with sub-second TTF that are unlikely to be provided by the usual L1 monolithic blockchains. Thanks to Avalanche’s highly customizable subnets, enterprise level clients can develop their own parameters and requirements as they deem appropriate. [Deloitte established a strategic agreement](https://www2.deloitte.com/us/en/pages/about-deloitte/articles/press-releases/deloitte-ava-labs-blockchain-state-local-government-natural-disaster-recovery.html) with Ava Labs in November 2021 to develop a new disaster recovery platform that uses the Avalanche blockchain to help state and municipal governments demonstrate their eligibility for federal emergency financing. Similarly, Ava Labs announced their first Litigation offering (ILO) using the Avalanche blockchain in December 2020, in collaboration with Roche Cyrulnik Freedman LLP and Republic Advisory Services, to provide individuals who lack the capacity to litigate or arbitrate a civil claim.
L1 Monolithic blockchains fail to scale adequately
- During the previous DeFi summer, we have seen L1 blockchains like Solana and Ethereum struggle to meet the spike in network activity, especially during NFT mints that are plagued with massive bot activity. While monolithic blockchains can adapt to increase their capacity, ultimately they are still bound by the limitations associated with the blockchain trilemma. - Avalanche allows projects to leverage subnets to scale horizontally effortlessly. For example, one can create multiple subnets as side chains to scale the network. Compared to Polkadot which has a limit of 100 parachains, Avalanche has no cap on the number of subnets possible. The only resource needed in creating additional subnets are validators on the primary network.