Avalanche is a platform that provides the infrastructure to create highly optimized blockchains that are connected via a native interoperability solution. Today, Avalanche is well-known for the C-Chain (Contract Chain), a general-purpose EVM L1 home to 37 DeFi applications that each have over $1M in TVL, including popular applications like Trader Joe, Aave, and GMX. However, it is built under the premise that a single chain optimized for global, shared state cannot scale to meet the demands of the modern world. Instead, many high-performance chains will exist and need to seamlessly interact with each other.

Emin Gün Sirer, Ava Labs Founder and CEO, recently released the team’s roadmap, and the emphasis on creating a platform to launch heterogeneous blockchains with asynchronous composability is clear. The roadmap has three focal points around proliferating Subnets, scaling throughput, and hardening consensus. Avalanche aims to give developers a framework to customize a blockchain for a specific use case. 

A blockchain built on the Avalanche tech stack is validated by a Subnet, which is just a collection of validators. Subnets are not blockchains, but rather the validator sets that control the design, operation, and economics of the chain(s) they validate. Each Subnet can validate one to many blockchains, while each blockchain can only be validated by a single Subnet. The collective blockchains validated by Subnets form the Avalanche Network. 

Primary Network, the First Subnet 

In line with the now-popular modular thesis, the Avalanche Primary Network separated its core functionalities into individual blockchains to improve resource allocation. The C-Chain, X-Chain, and P-Chain were the first three blockchains in the Avalanche Network and are collectively validated by the Primary Network – the first Avalanche Subnet.

All three chains use the Snowman Consensus protocol pioneered by the Ava Labs team. It uses repeated subsampling to provide high security, fast finality, and scalability. While many consensus engines are limited by all-to-all communication between nodes, Snowman Consensus enables verification without having to communicate to every node. The result is a powerful consensus engine that can quickly achieve finality even with a large validator set.

Similarly to other popular L1s, C-Chain offers a permissionless platform to build EVM-based smart contract applications. The C-Chain saw meaningful DeFi experimentation during the previous cycle with TVL topping out at $21B, driven mostly by the lending markets Aave and Benqi and the DEXs Trader Joe and Curve. The C-Chain also has key integrations that help facilitate DeFi activity. Both Tether (USDT) and Circle (USDC) support minting and redeeming on C-Chain, and there is currently $1.2B of combined USDT and USDC value onchain. Additionally, oracle providers are a common prerequisite for DeFi applications like lending markets where price feeds play a critical role in operation. Chainlink, the largest oracle provider with 53% of the total market share, supports 116 applications on C-Chain today.

In December 2023, C-Chain sustained an average of 40 transactions per second (TPS) throughout the month and peaked at 106 TPS within a single minute. While the activity surge was caused by inscriptions, which are lightweight transactions and generally regarded as low-quality usage, it gives credence to the performance of the Avalanche tech stack relative to other EVM chains. However, C-Chain transaction throughput appears limited relative to other high-throughput chains like Solana, which regularly averages 100x more TPS. The platform intends to improve network performance by adding support for high-throughput chains built with the HyperSDK.

The X-Chain is only used to create and transfer Avalanche native assets, but the P-Chain plays a critical role in the broader Avalanche tech stack. It acts as a subnet registry that tracks validators in the active set and their stake weight. The validator information recorded on the P-Chain enables cross-Subnet communication.

Today, all Subnet validators must also validate the three chains in the Primary Network. There are currently a total of 1,821 validators with 259M AVAX (59%) staked on the Primary Network. Nodes must stake at least 2,000 AVAX to validate for the Primary Network, but token holders can delegate a minimum of 25 AVAX to participate. Roughly 82% of the total stake is from nodes with the remaining 18% of stake from individual delegators. Relative to other PoS chains, Avalanche liquid staking has not seen as much adoption. Benqi and GoGoPool, the two largest Avalanche LST providers, account for just 3% of the total stake today. 

Reducing Reliance on the Primary Network

ACP-13 (Avalanche Community Proposal) was proposed to the community by members of Ava Labs in an effort to reduce the overhead of launching a Subnet. The proposal would create a new type of staker, a Subnet-Only Validator (SOV), that no longer has to sync and validate the entire Primary network. Instead, SOVs would only verify the P-Chain, dropping the requirement for C-Chain and X-Chain, as P-Chain verification is required for cross-Subnet communication. This proposal decreases the upfront fixed cost to deploy a Subnet, improves resource allocation for validator hardware, and reduces the regulatory risk for institutional clients while maintaining Subnet interoperability.

Subnet validators are currently required to validate the Primary Network, which requires a 2,000 AVAX minimum stake. The large upfront cost has been viewed as a barrier to entry for prospective Subnet developers since it costs ~$88,000 per validator at the current AVAX price. ACP-13 would deliver a 75% cost reduction by allowing SOVs to lock a 500 AVAX refundable deposit. Since SOVs will not validate the Primary Network, the 500 AVAX deposit is no longer staked and does not accrue network rewards. While this is a meaningful reduction in the fixed cost to launch a Subnet validator, it remains to be seen how price-sensitive potential Subnet validators are. It would still cost ~$22,000 per validator to launch a Subnet in the Avalanche Network at the reduced cost proposed in this ACP.

The proposal improves efficient resource allocation by removing the need to validate the C-Chain and the X-Chain, so Subnet validators can make better use of their hardware for running their own chain instead of dedicating resources to the Primary Network. While the Primary Network hardware requirements are modest today, some in the community are calling for increased hardware to improve performance. If resources must be spent on an auxiliary network, it is hard to say the tech stack is fully committed to being a higher-performance platform.

Additionally, there are regulatory risks around validating a permissionless smart contract platform like the C-Chain. For example, the US government maintains a list of OFAC-sanctioned Ethereum addresses, forcing regulated validators, builders, and relayers to omit certain transactions from blocks to remain in compliance. ACP-13 removes the regulatory risk of requiring Subnet validators to participate in Primary Network consensus, which is an obvious deterrent for US-based, risk-averse entities that are interested in building a blockchain. 

Subnet Architecture 

The end goal of Avalanche is to be the premier destination for building customized blockchains, but this is only possible if the infrastructure is interoperable, flexible, and performant. 

Avalanche Warp Messaging

In a world of many chains, interoperability is essential. Avalanche Warp Messaging (AWM) is the native solution that allows Subnets to communicate with each other. The validator sets of two chains can use AWM to communicate directly, eliminating the need for third-party bridges to transfer data or assets between blockchains in the Avalanche Network. AWM is flexible enough to support messaging between any chain that is registered with the P-Chain, whether it be a permissionless base layer like the C-Chain, a fully permissioned application-specific chain, or anything in between.

Messages are passed between Subnets using relayers, and the messages are verified using a BLS multi-signature. The receiving Subnet verifies the signatures by querying the P-Chain, which acts as the central registry for Subnet validators. For example, imagine Subnet A sends a message to Subnet B. After some user action triggers AWM, the Subnet A validators co-sign a message that is relayed to Subnet B. Subnet B validators then verify the message to determine if it was signed by a preset threshold of stake on Subnet A. Importantly, messages are sent, received, and verified without trusting external parties.

AWM has been live since December 2022, but significant engineering work was needed for it to be EVM-compatible. ACP-30 established a standard implementation and enabled cross-Subnet messaging on C-Chain and every EVM-based blockchain in the Avalanche Network. The ACP was implemented with the Durango Upgrade that took place on March 6, 2024, and users can now seamlessly bridge assets between chains via Teleporter. It is built on top of AWM and acts as a simple interface to send and receive cross-chain messages, enabling ERC-20 transfers between blockchains in the Avalanche Network. Teleporter is designed to ensure a smooth and reliable UX with features like duplicate transaction prevention, a relay whitelist, and an optional fee. The standard introduced in ACP-30 will soon be extended to the HyperSDK, increasing the number of chains connected to Teleporter. 

Subnet VMs and the HyperSDK

A virtual machine (VM) is the software that defines the behavior of the blockchain by specifying things like the transaction format, state access, and the gas mechanism. VMs can vary greatly and have implications on how applications built on top of them function. For example, the VM deployed by Ethereum (EVM) has a different set of tradeoffs than that of Solana (SVM). The EVM has a larger developer community and stronger developer tooling, but the SVM is built for performance with multi-threaded runtime that enables parallel execution and an enhanced transaction fee mechanism.

Blockchains built in the Avalanche Network can run prebuilt VMs like Subnet-EVM, a Subnet-compatible version of the EVM, or custom VMs of their choosing. Building a custom VM is a tall order, so most Avalanche Network chains run the Subnet-EVM today. The HyperSDK was built to simplify the process of creating a custom VM, giving developers the benefits of customization without starting from ground zero.

The HyperSDK is a framework for building customized VMs (HyperVMs) that can be plugged directly into the Avalanche Network. The HyperSDK is designed with powerful default parameters to allow developers to focus on building the core of their application, instead of having to build a VM from scratch. Theoretically, the HyperSDK will reduce the time needed to create a VM from months to days, providing developers with a quicker path to market.

The HyperSDK also aims to bring a new era of performance to Avalanche. It will offer an improved transaction processing mechanism called Vryx, which builds upon the core ideas laid out in many well-regarded research papers, including the Narwhal Tusk paper published by the Diem (Facebook) team that influenced many of the modern chains today like Aptos and Sui. Vryx decouples the transaction processing steps which enables validators to build and replicate chunks of blocks concurrently. In other words, it scales throughput by decreasing the total amount of time it takes to build, replicate, and verify a block. Ultimately, it will enable much higher TPS within the Avalanche Network. Vryx is not live today, but the goal is for it to be implemented into the HyperSDK by the end of the year. Ava Labs will soon publish performance benchmarks highlighting the performance of Vryx, which will potentially exceed 100k TPS.

Like other performance-built blockchains, the tradeoff for performance will come via increased validator hardware requirements. While future Subnets will be able to determine the VM they run which influences their hardware requirements, the Primary Network community will be left to determine if it is the appropriate tradeoff for C-Chain. The tradeoff here is between performance and decentralization as it is generally viewed that increased hardware requirements increase validator costs and therefore decrease accessibility to running a node. While this is reasonable in theory, it is not necessarily true in practice as Solana has 1,606 staked nodes with higher hardware requirements than the Avalanche Primary Network. Other factors like the geographic distribution of the nodes and servers come into the decentralization discussion as well.

Database Solutions

Ava Labs is building an in-house database solution called Firewood to improve performance further. Firewood is the team’s response to the state management problem, one of the primary bottlenecks to scaling blockchains. A blockchain’s state, or a snapshot of the relevant data stored within the system, grows with its usage and creates long-term scalability issues as the current state needs to be quickly accessed by validators to performantly process transactions. Quick state access becomes a computationally burdensome task as the state grows larger.

Firewood aims to improve upon the database the team initially built called MerkleDB. It uses a novel mechanism to efficiently store and read blockchain state by reducing the overhead of modifying the existing state. The result is a more robust database that provides quick state access, removing a key bottleneck to increased transaction throughput. Ava Labs will soon also publish performance benchmarks for Firewood.

Comparisons to Other Tech Stacks

Avalanche is not the only tech stack building infrastructure to launch blockchains. Most notably, appchains in the Cosmos Ecosystem and rollups on Ethereum are the most popular ways to build your own chain today. Each framework has a different set of tradeoffs that attract a different group of developers. 

Cosmos Appchains

The end goals of the Avalanche Network and the Cosmos Ecosystem are nearly identical: a web of independent chains connected asynchronously with a trust-minimized messaging standard. Both platforms allow developers to build a blockchain that manages its own security, which requires bootstrapping a high-quality validator set. Even if ACP-13 is implemented, the 500 AVAX deposit may still act as a prohibitive barrier to entry to become a Subnet validator. As such, the validators that do make the deposit may be more willing to validate many chains to earn more rewards and offset their initial deposit. There is no comparable mechanism to the 500 AVAX deposit in the Cosmos ecosystem today, yet we see a large overlap between appchain validator sets. For example, Chorus One, Allnodes, Polkachu, and Informal Systems are all validators for Celestia, Comos Hub, Osmosis, and dYdX.

The key differences today are that the Cosmos Ecosystem offers more sovereignty and the tech stack is further battle-tested, while the Avalanche Network offers a more scalable consensus mechanism and will soon offer higher transaction throughput. 

The P-Chain acts as a central registry for Avalanche Subnets today, so the validator set resides on the P-Chain. Therefore, Subnets are independent networks that have an external dependency to the P-Chain and are not entirely sovereign. For example, Subnet staking rewards are handled by the P-Chain, so Subnets cannot alter the reward mechanism to experiment with new types of reward distributions and must follow the staking rules set by the P-Chain. Cosmos chains are arguably more sovereign as they do not have a similar central hub and are free to redesign more of their tech stack. An early discussion is taking place to remove this dependency by allowing Subnet Orchestrated Validator Sets to manage their own validator set and update the P-Chain of all changes. Subnets would get more control over their chains, and the P-Chain would only be used to provide cross-Subnet communication. This is only a discussion and it is not clear if this will be implemented.

The Cosmos ecosystem has seen more experimentation over the last few years. Terra proved the tech stack could handle the traffic of a general-purpose L1, and more recently dYdX proved it was flexible enough for application-specific purposes. Today, there are 88 active Cosmos chains compared to 34 Subnets validating 36 active chains in the Avalanche Network. The larger developer community of the Cosmos has pushed more innovation through the tech stack, with external teams building modules that other chains can leverage.

There are also clear similarities between AWM and the Inter Blockchain Communication (IBC) protocol used by Cosmos Appchains, but the core difference lies in the message verification process. Since AWM has P-Chain as a universal registry, all Subnets refer to it to verify that active validators signed an inbound message with the necessary stake weight. There is no single reference point with IBC, so Cosmos validators must sync information between chains and keep a local record of the other chain’s validator set. Channels between Cosmos chains are regularly refreshed to maintain the active validator set, creating a per-connection for new channels.

Both AWM and IBC require relayers to send the messages between chains. Relaying in the Cosmos ecosystem is not incentivized, so relayers tend to be service providers that have a business need to play this role. The push to add fees to IBC transfers has received minimal traction thus far. Nonetheless, the Cosmos ecosystem has a large relayer network with Crossnest, Informal Systems, and Notional playing active roles. It will likely take time to develop a similar network of relayers as the Subnet ecosystem grows, but Teleporter offers an optional fee for incentivizing relayers to deliver messages. This should theoretically improve the quality of service relayers provide and result in quicker asset transfer. Teleporter has been live for less than 24 hours at the time of writing, but we will continue to monitor how the relayer ecosystem develops.

The use of subsampling in the Avalanche Consensus mechanism has done an incredible job scaling the size of the active set beyond 1,800. This is much better than the existing Cosmos chains, which range between 80 and 180 validators. This should allow permissionless blockchains to flourish in the Avalanche network, but it is worth noting that both networks allow developers to build blockchains with permissioned validator sets. Noble in the Cosmos and Evergreen Subnets for Avalanche are great examples of this. Additionally, Avalanche will likely offer a more performant tech stack after the HyperSDK, Vryx, and Firewood are available. However, the exact performance improvement will not be known until the benchmarks are released. 

Rollups

Rollups are another alternative to launching a blockchain on the Avalanche Network. A rollup is a blockchain that extends the execution of another blockchain and settles transaction data back down to it. There is a wide array of options to launch a rollup with state validation like fraud proofs or zero-knowledge (zk) proofs, frameworks like OP Stack or Arbitrum Orbit, settlement options like Ethereum or even another rollup, and data availability solutions like Ethereum or Celestia. The exact construction of a rollup dramatically impacts its security and reliability, so we generalize the construction to compare the idea to launching a blockchain in the Avalanche Network.

One of the largest differences is the source of security. Blockchains in the Avalanche Network derive their own security, while rollups inherit security from a base layer. Rollups create a mechanism to scale the execution of an underlying layer that provides consensus, settlement, and data availability to the rollup. In contrast, Subnets are effectively Layer1 blockchains that provide their own consensus, settlement, and DA with their own staking token. While most rollup frameworks are centered around EVM equivalent rollups, which are not as performant as newer VMs, it is possible to build a rollup with a newer or custom VM similar to how Eclipse is forking the SVM for its rollup. Avalanche Subnets are inherently VM-agnostic, meaning that a Subnet can run a blockchain built with any virtual machine. Though most in-production Subnets are currently EVM-compatible, efforts to bring custom virtual machines such as MoveVM, WASM-based VMs, and others built with the HyperSDK are well underway.

Rollup transactions are often executed by a single sequencer that posts transaction data to a data availability layer for public visibility. The sequencer is a central point of failure in most rollups today. In the event of an outage, users may be unable to process L2 transactions. Outages will generally not lead to loss of user funds, but the exact security assumptions depend on the construction of the rollup. Similarly, an outage on one Subnet does not impact the liveness of another Subnet. However, the Avalanche Network creates fault isolation such that there is no single point of failure. Even a P-Chain outage would only impact the ability to send AWM messages to other chains, but activity within each Subnet would be unaffected. This is in contrast to rollups, which would see a degraded performance if the settlement or DA layers go down.

Avalanche security comes from the Subnet of a given chain handling execution, data availability, and consensus. Validators handle all functions of the chain, including execution, data availability, and consensus. Like most Proof-of-Stake chains, they are often economically incentivized to participate in network security with inflationary rewards or transaction fees. Rollups post transaction data to the data availability (DA) layer so that execution and settlement layers can verify whether the transaction data is available. A rollup may not be able to continue its state if the data is withheld, which would lead to frozen user funds. Users should be able to download block data and execute the rollup’s state to verify the state transition.

There are no variable costs to running a blockchain in the Avalanche Network because the Subnet itself handles security. The only cost is the AVAX deposit that ACP-13 is working to reduce. In contrast, the cost to post data to a DA layer has historically been the largest expense of running a rollup. These are variable costs that scale with usage and are often passed back to the user as transaction fees. However, the launch of Celestia significantly reduced these costs by 99%.

The undeniable advantage of Subnets over rollups lies in AWM, offering native interoperability, a feature notably absent in rollups, where cross-rollup communication remains an unsolved problem. Liquidity, users, and attention have become fragmented between the isolated network of rollups. There are third-party bridging solutions available today, but each introduces a new set of trust assumptions. There are attempts to create a richer bridging solution enabled by zk proofs where two rollups that use the same zk prover can asynchronously pass messages without additional trust assumptions, but even this solution has limitations. There are many teams creating their own zk provers, and the incentive is for each team to see their solution win out. We expect this to result in liquidity fragmented into different rollup constellations that leverage the same technology, rather than just individual rollups, where third-party bridging is still required outside each constellation. In contrast, Avalanche’s use of a single messaging protocol provides powerful asynchronous communication between its entire network, without the need for any third-party bridges. 

Conclusion

The Avalanche Network is well on its way to becoming the best platform to build high-performance blockchains that can seamlessly interact with each other. Their largest challenge will be attracting builders into their ecosystem over competing architectures. The strong focus on performant and scalable blockchains will likely be Avalanche’s competitive advantage, and we expect the launch of HyperSDK, Vryx, and Firewood in the back half of the year to act as major catalysts for Subnet adoption. Further, the discussion around ACP-13 strictly focuses on reducing the barriers to entry and scaling Subnet adoption. 

This research report has been funded by Ava Labs. By providing this disclosure, we aim to ensure that the research reported in this document is conducted with objectivity and transparency.  Blockworks Research makes the following disclosures: 1) Research Funding: The research reported in this document has been funded by Ava Labs. The sponsor may have input on the content of the report, but Blockworks Research maintains editorial control over the final report to retain data accuracy and objectivity. All published reports by Blockworks Research are reviewed by internal independent parties to prevent bias. 2) Researchers submit financial conflict of interest (FCOI) disclosures on a monthly basis that are reviewed by appropriate internal parties. Readers are advised to conduct their own independent research and seek the advice of a qualified financial advisor before making any investment decisions.