Avalanche L1s: Powering the Future of Appchains

Introduction

As an application scales, the incentives of its users and operators must stay aligned. Incentives shape behavior and drive network effects, ultimately fueling product development and monetization. On generalized chains, most of the value created just flows back to the base layer. Apps bear the cost for growth while the underlying chain captures the upside. Unsurprisingly, apps with significant velocity are incentivized to deploy onto their blockchains. We have seen this play out numerous times in the past. Examples like Uniswap (Unichain L2) and dYdX (dYdX L1) come to mind.

The general argument for appchains is pretty straightforward, too. General-purpose chains try to be everything for everyone. And that comes at a cost. Congestion, higher fees, and limited flexibility are all drawbacks of shared blockspaces. For teams that want and need deeper customization along with better performance, launching their own chain is much more attractive. Owning the full stack not only lets them tailor the infrastructure but also capture more of the value they generate. 

Gaming and payments apps can leverage private and permissioned blockchain rails to streamline operations and improve UX. DEXs can focus on reducing latency and increasing throughput. Businesses and institutions like banks can finally deploy in a compliant manner, leveraging privacy features with permissioned access rails – all non-negotiables for regulated entities. These businesses couldn’t find PMF with the traditional public and permissionless design of blockchains. 

But launching your own appchain doesn’t come without challenges. A sound design is needed to incentivize validators (usually through inflation), making it a tricky and expensive endeavor. To onboard users, wallet integrations and a good block explorer are the first of your worries, followed by countless dev tools if you want to be competitive with other ecosystems and attract an active developer cohort. The list is endless, covering everything a blockchain needs, from oracles to liquidity and native bridges.  

Yet, if you overcome all of these obstacles, your biggest challenge still awaits: implementing a native cross-communication protocol to maintain composability with a larger ecosystem. Otherwise, fragmentation is the pitfall of appchains we have seen time and time again. To create synergy instead of competition, appchains must stay interconnected and complementary. 

In theory, the ideal appchain solution powers a future of interoperable chains, where each chain can maintain its sovereignty and customize modular infra, while still benefiting from network and ecosystem effects without servicing large expenses. Avalanche recognized this early, paving the way for such a future since its launch in 2020. 

Its opinionated design after the Etna upgrade supercharged Avalanche L1s: composable, purpose-built appchains that can share validator sets and leverage modular infra to deliver tailored appchains for specialized use cases. 

To understand Avalanche’s evolution as a bespoke appchain hub and how it stacks up against contenders like Initia and the Elastic Network, let’s first explore Avalanche’s old architecture before the Etna upgrade. From there, we can compare it to the post-Etna design and highlight the key improvements that set it apart. 

Pre-Etna Upgrade: Avalanche’s Former Design

From day one, Avalanche was built to give developers the ability to launch purpose-built chains specifically optimized for their use case. With cheap transactions, fast finality, and full control over execution logic, custom chain development could be both accessible and scalable. This foundation manifested Avalanche as one of the few blockchains to take the appchain vision seriously before it became a widely accepted narrative. 

At a high level, Avalanche comes with a high-performance consensus, customizable virtual machines (VMs), and a dedicated network model for activity isolations. Even before the Etna upgrade went live, developers had already utilized these features and designed their Avalanche L1s (called “subnets” back then) to be use-case specific. Without compromising on the user experience.

These design choices ranged from permissioned to permissionless access with different business-specific operational flows. Avalanche also built a native messaging protocol to meet the demand for seamless value transfer between the L1s. 

There are two main components to Avalanche’s architecture: the Primary Network and Avalanche L1s. 

The Primary Network

The Primary Network consists of three permissionless chains. The P-Chain for validator management, the C-Chain for smart contract deployment (EVM), and the X-Chain for payment and native asset transfer. 

These three chains operate autonomously from one another, each with its own optimized VM to fit its purpose. While sharing the same validator set, this structure creates activity isolation and enables targeted optimizations. Such separation also leads to faster product iterations and cost reduction. 

To users and developers, this was the first scalable implementation of Avalanche’s design philosophy: purpose-built chains with customized VMs, all secured by the same consensus engine. And unlike other networks, all transaction costs on the Primary Network on Avalanche are burned – the first important design difference. 

After the Etna upgrade, the general architecture setup of the Primary Network and the burn of transaction costs remain the same. However, the operations of these three chains were adjusted to better accommodate and supercharge Avalanche L1s. We’ll dive into this later.

Snow Family Consensus

Avalanche’s consensus mechanism is a crucial piece of infra. It serves as the foundational core, allowing developers to build chain-specific modules on top of each Avalanche L1. 

The traditional BFT consensus model creates trade-offs between scalability, speed, and security – because a validator processes every transaction and then sends it out to every peer. As more participants join the network, the number of messages exchanged between validators increases exponentially. Either the number of validators must be capped, limiting decentralization, or this added load can slow down performance. If validators are overwhelmed and go offline, the network becomes more vulnerable to attacks. A smaller number of validators also means it’s easier for bad actors to sway consensus. 

These bottlenecks are exactly what Avalanche aimed to solve with their Snow Family of consensus protocols: Slush, Snowflake, and Snowball. The main idea is that validators can reach consensus without directly communicating with everybody – via subsampling. 

Subsampling allows validators to reach consensus by repeatedly querying random subgroups of the validator set. Operating on a probabilistic model, validators gradually increase their confidence in the correct state of the network after each round of subsampling. 

Once the threshold for validation is reached, transactions are finalized and updated to the chain. This subsampling method greatly reduces network constraints and resource usage, enabling sub-2 second finality and improved scalability compared to traditional BFT consensus.

Avalanche L1s: Pre-Etna

Avalanche L1s pre-Etna were built for scalability and blockspace abundance. Each L1 operated like an independent network within the larger ecosystem, with a subset of Avalanche validators securing it. 

The Primary Network handled global validator coordination, while these individualized L1s allowed builders to customize their environments. In most but not all cases, this avoided congestion from unrelated apps. 

Developers had meaningful control over the design of their L1s. They could customize execution logic, make applications permissioned or permissionless, and choose whether their chain was private or public. That flexibility allowed them to tailor Avalanche L1s for specific use cases and business needs (e.g. financial institutions that require privacy rails to conform with regulations).

This customization and independence set apart Avalanche L1s from Ethereum Rollups. While both inherit security from the base layer, L1s built on Avalanche essentially run as independent networks – handling execution, settlement, and data availability. Rollups, on the other hand, mainly rely on the Ethereum base layer for finality and DA. This distinction is key to Avalanche’s design edge in the race to becoming the appchain hub. Developers can move faster without being restricted by shared infrastructure.

Fundamental Design Challenges Pre-Etna Upgrade

As compelling as the architecture sounds, this original design came with trade-offs that limited adoption, especially by the institutions it aimed to support. 

Cost was the first obstacle. Launching an Avalanche L1 pre-Etna required a set of validators, each needing a stake of 2,000 AVAX tokens. This was because validators were required to participate in the Primary Network as well. That meant just getting the L1 operational could cost over $150,000, not including hardware or other business expenses. For smaller teams or firms, this high upfront cost was a significant barrier to entry. 

Requiring validators to participate in both the Primary Network and the individual L1 also introduced another layer of technical complexity. It made Avalanche L1s vulnerable to unexpected usage spikes from the broader network, which could disrupt the L1’s performance. 

Lastly, compliance was one of the biggest hurdles. Many regulated entities are simply not allowed to validate permissionless networks, which made Primary Network validation a dealbreaker. That meant fewer asset issuers, fewer unique tokens, and a hard path towards any real institutional involvement on the Avalanche network. 

The Etna Upgrade

Avalanche’s architecture started to feel increasingly limiting. The financial and operational requirements, combined with the big compliance hurdle, meant only a small set of teams could actually take advantage of Avalanche’s capabilities. 

The Etna upgrade completely changed that. It catapulted Avalanche’s position to the frontier of appchain hubs by expanding L1 flexibility and addressing the pitfalls around cost and compliance. Core features like the consensus mechanism and token burn model were left unchanged. The focus zeroed in on making Avalanche L1s as an appchain model more viable. 

Implemented in December 2024, the upgrade included improvements from the following Avalanche Community Proposals (ACPs):

• ACP-77: Outlined a new validator management framework called Avalanche L1, enabling the creation of low-cost, natively interoperable blockchains.
• ACP-103: Introduced a dynamic fee mechanism to the P-Chain, previewing a future transition to a multidimensional fee mechanism.
• ACP-118: Proposed a standard AppRequest payload format type, simplifying potential AWM signature aggregation implementations.
• ACP-125: Reduced the minimum base fee on the Avalanche C-Chain from 25 nAVAX to 1 nAVAX.
• ACP-151: Used the current P-Chain block height for signature verification. This impacts how ICM messages are verified for a more reliable message delivery.

Together, these proposals introduced a more adaptive architecture that better supports custom chain development and sets the stage for broader adoption. 

Supercharged Avalanche L1s

With the Etna upgrade, launching a custom chain has become much more streamlined, transforming what was once a cumbersome process. Teams and developers still enjoy the benefits Avalanche L1s were known for, but without the high upfront staking costs or validator requirements that previously limited accessibility and caused compliance issues. 

Beyond that, a plethora of core improvements were made to supercharge Avalanche L1s – let’s dive in.   

New Economic and Technical Sovereignty

In a dynamic, fast-moving industry like crypto, flexibility is critical to long-term success. Avalanche’s previous architecture already let builders customize their execution layer and choose between public or private access to fit specific use cases. But with the Etna upgrade, that customization now extends to validators and consensus as well. 

Validators are now managed independently by each L1. Teams define their own rules of who can validate, which token is used, and how rewards are structured. This gives the L1 token a much more critical role and allows teams to better align incentives and coordinate growth (e.g. using their native token as the L1 token). 

The new structure also keeps accrued value within the appchain itself rather than leaking it to any external layers, a foundational shift in how apps are able to grow and sustain their own ecosystems. 

Additionally, teams may choose between Proof-of-Stake (PoS) and Proof-of-Authority (PoA) consensus mechanisms — unlocking even more optionality for teams to align their networks with their goals. For example, institutions can go with PoA to run high-trust, internal chains that are private and permissioned with full compliance from day one. 

Interoperability

For most appchains, composability and interoperability remain challenges. Each chain is tailored to its own use case, making it harder to integrate across a whole ecosystem. One of the core strengths of Avalanche L1s is their native interoperability through Interchain Messaging (ICM). ICM is Avalanche’s protocol that allows L1s to transfer data and assets between each other without relying on any external bridges or complex solutions. This gives apps a way to share users, coordinate across chains, and access broader, network-wide liquidity without having to give up their own tailored environments.

To support message delivery, ICM operates with relayers. Relayers are off-chain programs that listen for messages on one chain and then deliver them to their destination chain. Importantly, these messages are secure and tamper-proof, ensuring relayers cannot alter them in the process. While anyone can run a relayer, businesses and institutions can also choose to authorize only specific entities or enforce private communication channels between L1s. These are crucial features for enabling confidential execution of operations like time-sensitive trades on tail-end assets.

The Etna upgrade introduced two key updates here that made ICM faster, more secure, and easier to work with. ACP-118 introduced a standard messaging format that improves cross-chain compatibility and makes implementation easier, while ACP-151 improved validator set response time to ensure quicker and more secure message validation. Although not as significant as ACP-77, these updates were key to improving the builder experience and security of the entire cross-chain system. 

Putting it all together

High upfront costs and impractical operational requirements were major bottlenecks for Avalanche L1s pre-Etna. The upgrade tackled both of these by introducing a new Avalanche L1 framework that supports arbitrary staking and removes the need to validate the Primary Network.

Teams no longer need to lock up 2,000 AVAX (per validator) to launch an L1. Instead, validators now pay a small monthly fee (currently ~1.3 AVAX), which is burned to create another accrual mechanism to AVAX. This lowers the barrier to entry remarkably, allowing teams to focus their resources on real product development and growth. By making it cheaper and easier to launch an appchain, Avalanche has created a strong incentive for new teams to build within its ecosystem. 

Validators on Avalanche L1s now exist independently from the Primary Network as well. With no global sync requirement, they can benefit from more consistent uptime and better resource management. This separation also opens the door for more participants to join as validators on any individual network, improving both decentralization and resilience of the Avalanche L1s.  

These infrastructure upgrades also set the stage for more specialized deployments. Businesses can now launch permissioned chains with full control over validation, access, and compliance without sacrificing interoperability or performance. This unlocks a broad range of enterprise use cases that were previously out of reach. As a result, a growing cohort of institutions is now utilizing Avalanche L1s, like J.P. Morgan’s Kinexys.

Post-Etna, Avalanche L1s are vastly improved – or supercharged. Here are the key improvements summarized: 

Enterprises building on Avalanche L1s

With this technical foundation in place, Avalanche has already seen a growing wave of real deployments across institutional finance, DeFi, AI, gaming, and other sectors. 

A few notable examples include:

MapleStory Universe

MapleStory Universe (MSU), the Web3 extension of the iconic MMORPG franchise, recently launched its own permissioned Avalanche L1, Henesys. As the backbone for MSU’s ecosystem, Henesys supports a gasless and invisible transaction UX with custom execution logic to power game-specific mechanics like item minting, ownership, and verifiable randomness.

By launching on its own Avalanche L1, MSU is able to deliver a seamless player experience while retaining full control over performance, economics, and developer tooling.

Kinexys: J.P. Morgan’s Digital Asset and Payment Infrastructure

Kinexys is a digital asset platform developed by J.P. Morgan. As a proof of concept under “Project Guardian”, Kinexys used a permissioned Avalanche L1 to tokenize WisdomTree funds and simulate portfolio rebalancing across multiple blockchains. The L1 on Avalanche was one of three chains used in the pilot, specifically hosting tokenized fixed income, while other networks handled equities and alternative investments. 

The goal was to demonstrate how real-world portfolios could function in a multi-chain world, with each network handling distinct asset classes and execution logic.

Kite AI

Kite AI is launching the first AI-focused Avalanche L1 with its own Proof of Attributed Intelligence mechanism, customizable subnets for specialized AI tasks, and a tailored reward system for models, agents, and data providers. Its incentivized testnet Aero is currently live, with mainnet coming soon.

Using Avalanche’s framework to launch a personalized appchain allows Kite to build out its own bespoke consensus mechanism and manage AI workloads more efficiently while also giving contributors full control over how data and models are used. 

New Jersey Property Deeds

New Jersey’s Bergen County recently unveiled plans to tokenize 370,000 property deeds on an Avalanche L1. Representing over $240b of real estate, this initiative will create an immutable, searchable chain of titles across 70 towns and aims to reduce processing times by over 90%. 

It’s the largest deed tokenization project by a U.S. county to date and highlights Avalanche’s growing role in modernizing public infrastructure. 

California DMV

The California Department of Motor Vehicles (DMV) previously announced that they are building a dedicated Avalanche L1 to digitize more than 42 million vehicle titles. The system is designed to streamline title transfers through smart contracts and verifiable credentials, which will enable California residents to claim and manage titles directly through a mobile app.

Through this, the DMV can offer a faster, more secure, and fully digital alternative to the legacy process. It’s one of the earliest examples of a U.S. state agency running its own blockchain network to improve public services at scale.

Architecture Tradeoffs & Improvements

It’s hard to deny the improvements Avalanche has undergone with the Etna upgrade. Teams now have a more flexible and affordable framework to build within the Avalanche ecosystem. Compared to the limitations pre-Etna, this is a huge step forward.

However, this new convenience doesn’t come without drawbacks. While removing the high staking requirements and decoupling validation from the Primary Network has a plethora of benefits, the Etna upgrade shifts most of the architectural design responsibility onto the teams themselves. 

Developers now have to make critical decisions around validator setup, reward structures, and network security. This opens up a range of options to choose from, but also introduces risks of poor design via increased complexity. 

Validators and Avalanche L1’s Sovereignty

Post ACP-77, the P-Chain no longer manages staking and reward distributions for any network other than the Primary Network. All staking-related operations for the Avalanche L1 are handled by the L1’s validator manager. There are no restrictions on what requirements an Avalanche L1 can have for validators to join. Essentially, Avalanche L1s now have sovereignty over their own security. 

The onus is now on the validator to vet the security of any chain they want to participate in. Any assets on the Avalanche L1 will be solely under the purview of the L1. If a validator gets kicked out of the L1 validator set, the P-Chain can only guarantee retrieval of the remaining AVAX balance on the P-Chain, but not the funds that have been locked on the Avalanche L1. 

L1s can use the P-Chain as an impartial judge to modify parameters. If a validator misbehaves, the L1 validators can collectively generate a BLS multisig to reduce the voting weight of a malicious validator. This operation is fully secured by the economic weight behind Avalanche’s Primary Network (229m AVAX or $5.7b at the time of writing). 

Cross-Chain Security with the Primary Network

The distinction between the Primary Network and the Avalanche L1’s validator set post-Etna strengthens network security via fault isolation. Congestion and faults at the Avalanche L1 will not impact the activities on the Primary Network and vice versa.

For cross-chain communication between the Avalanche L1 and the Primary Network, the P-Chain only considers a message valid if the stake weight behind the BLS signature aggregation from the source chain is at least 67% of the total stake. This is also equivalent to the threshold set for messages sent to the C-Chain. Future ACPs may be proposed to support the modification of this threshold on a per-L1 basis. 

Avalanche L1’s Validator Earnings

Validator earnings are determined by the rules of the Avalanche L1. These include the staking requirements, inflation rates, and other operational mechanics. Compared to the previous model, the Avalanche L1 validator doesn’t have the earning consistency from participating in the Primary Network. 

While the guaranteed income from the Primary Network is gone, validators can now participate in validating multiple L1s to build new revenue streams. There’s no limit on how many L1s a validator can support, but earnings will depend on each chain’s design, uptime requirements, and reward structure. It’s up to the validator to evaluate the potential of each opportunity. For this reason specifically, the design of an L1’s incentives is critical to stand out among the crowd and attract validators. 

Primary Network Improvements

The Primary Network and Avalanche L1s have always had a symbiotic relationship. As the ground zero for the platform, the Primary Network serves as the liquidity hub, establishes network effects, and offers interoperability services. Avalanche L1s provide a pathway for chain sovereignty and blockspace abundance. Together, they complement and expand the broader ecosystem towards a multichain future. 

ACP-77 brought systemic changes to how Avalanche L1s operate post-Etna, which resulted in the Primary Network’s adjustment to adapt accordingly. Other ACPs included in the Etna upgrade, such as ACP-125 and ACP-103, target the C-Chain and the P-Chain, and ensure that the Primary Network can perform under load while optimizing for future growth. The X-Chain will be scheduled for a later update due to the lack of feature updates and general usage, as well as concerns regarding technical complexity.

C-Chain

The C-Chain is the smart contract, EVM-compatible chain, where most user activities occur on the Primary Network. The most significant change to the C-Chain was brought on by ACP-125. The upgrade reduced the base fee on the C-Chain from 25 nAVAX to 1 nAVAX (a 96% reduction). This move encourages new activities and use cases on the platform, such as DeFi, high-frequency trading, and microtransactions (especially interesting for gaming apps). As we can see in the graph, the impact of the base fee drop was immediate, with significant activity upticks. 

Avalanche’s C-Chain adopts an EIP-1559-like mechanism that allows priority fees for block inclusion during times of activity spikes. Unlike Ethereum, however, Avalanche burns all its fees, including both the base fee and the priority fee. Combined with the 96% reduction in fees from ACP-125, this creates strong incentives for more usage and higher transaction volumes.  

This is a net positive for validators as well. Higher on-chain throughput boosts fee burns and network utility, which ultimately benefits everyone through increased activity. 

P-Chain

Post-Etna, the P-Chain is now the platform that coordinates validator staking on the Primary Network. It also keeps track of active Avalanche L1s and manages the creation of new ones. 

While not required to validate the Primary Network, validators must still register with the P-Chain. This registration is key to cross-chain communication and gives L1s access to partial security via shared PoS backing. 

With that in mind, the changes brought by ACP-77 do shift more responsibility to the P-Chain. It now has to track validator balances for the continuous payment model and manage new validator onboarding across Avalanche L1s – naturally increasing the processing load and significance of the P-Chain. 

To accommodate these changes, ACP-103 introduced a dynamic fee mechanism to make sure that demand for the P-Chain is properly priced in. For teams and developers, this helps strengthen network performance even under heavy load. 

Token Economics

With a hard cap of 720m tokens, Avalanche’s core token model focuses on utility and burn mechanics. Unlike most other chains, all transaction fees (base and priority) are burned and permanently removed from circulation. This gives AVAX an elastic supply model that correlates directly to network activity. 

As network usage grows, so does the burn rate. Over time, this creates a deflationary pressure on the token supply that could lead to long-term price appreciation. And because validators are paid only through new issuance and not transaction fees, higher network usage leads to more AVAX burned and less AVAX remaining in circulation.  

As of May 2025, the AVAX token trades for $25 with a circulating market cap of $10.5bn. While the circulating supply is ~418m, the current max supply of AVAX is ~715m tokens, with 4.6m already burned. When accounting for burned supply, this suggests a fully diluted valuation of $17.7bn at current prices. 

Conclusion

Blockchains offer a clear opportunity for institutions and businesses to modernize their infrastructure. Crypto rails unlock cheaper, faster, and globally accessible systems that can vastly improve efficiency and expand access to more users.

Still, real adoption has been slower than expected, and most of that comes down to legacy constraints. The majority of institutions simply can’t participate in fully open, permissionless networks due to regulatory restrictions. And other developers are often stuck trying to build around compatibility issues or rigid frameworks instead of focusing on building real products. 

Avalanche L1s post-Etna directly address this – serving as sovereign blockchains built to give developers full control and autonomy over their architecture and execution. Instead of working around infrastructure limitations, teams can now fine-tune their networks to be exactly what they need. 

Etna also greatly improved interoperability amongst Avalanche L1s. Improvements to cross-chain communication and validator management have made Avalanche’s base architecture more secure, efficient, and developer friendly. At the same time, the Primary Network has been refined to support these updates without compromising on performance. 

For institutions, Etna was a much-needed upgrade. Removing the requirement to validate the Primary Network finally allows enterprises to launch fully private, permissioned chains that meet all compliance needs to overcome regulatory hurdles. Enterprises can define exactly how validation works, build custom VMs, and design chains around their own execution logic and business requirements. 

Avalanche has been pushing the appchain model from the beginning, and the Etna upgrade was a meaningful stride towards bringing their vision closer to reality.  Launching a custom blockchain is now easier than ever, and it’s not just about technical optimization. It’s a plan to grow apps with direct ownership and control. Avalanche L1s give teams the tools to scale, differentiate, and capture more of their own value than before, without being boxed in by shared systems that limit their upside.