Avalanche avax

Avalanche is a proof-of-stake platform for building and operating sovereign, interoperable blockchain networks. Its public Primary Network contains the P-Chain (platform and validator coordination), C-Chain (an Ethereum Virtual Machine chain for smart contracts), and X-Chain (asset exchange and transfer).

The network's central architectural idea is that applications can run on their own Avalanche L1 (formerly commonly called a subnet). An Avalanche L1 is validated by a dynamic subset of Avalanche validators and can validate one or more blockchains. This lets an application choose its own execution environment, validator requirements, fee market, native token, privacy model, and compliance rules rather than sharing all constraints with a general-purpose chain.

AVAX is Avalanche's native utility token. It pays fees on the Primary Network, secures the network through staking, and serves as a basic unit of account across Avalanche L1s. Primary-Network transaction fees are burned, while protocol staking rewards are minted subject to the protocol's supply schedule; the documented maximum supply is 720 million AVAX.

Avalanche is positioned for decentralized applications as well as regulated and enterprise deployments. Its official adoption material highlights institutional users and partners including JPMorgan, Citi, KKR, Apollo, BlackRock, Franklin Templeton, FIFA, and the state of Wyoming, while also citing gaming, consumer applications, and on-chain finance.

Many blockchain applications compete for the same execution resources. A popular application can increase congestion, fees, and latency for unrelated users, while a single shared execution environment may not provide the throughput, privacy, validator geography, access control, or specialized hardware that a business or regulated application needs.

Avalanche addresses this by allowing application-specific L1s with isolated workloads and configurable virtual machines. A chain can set its own gas token and fee policy, tune throughput, require validators to meet hardware or geographic requirements, use KYC/AML or licensing gates, and keep state visible only to approved validators. This makes the network model more adaptable to enterprise and jurisdiction-specific requirements than a one-size-fits-all chain.

The trade-off is that sovereignty places more responsibility on the application operator: each L1 must design and operate its validator and execution policies, and assets moving between chains may require explicit interoperability or bridge mechanisms. The Primary Network remains the simpler starting point for applications that do not need those specialized properties.

Avalanche's Snow* consensus family reaches agreement through repeated random sampling rather than all-to-all voting. Snowball supplies the repeated-sampling confidence mechanism for binary choices, while Snowman extends it to a linear sequence of blocks. The official architecture documentation describes probabilistic safety with tunable confidence and sub-second finality; Snowman is used by the Primary Network chains and most Avalanche L1s.

Validators participate with proof-of-stake weight. AVAX stake determines a validator's weight in network decisions, and validators receive protocol rewards for good behavior. Primary-Network transaction fees are permanently burned. Avalanche's current architecture should not be confused with the historical DAG engine: the X-Chain was linearized in the Cortina upgrade and now uses Snowman consensus.

An Avalanche L1 consists of a dynamic subset of validators and one or more blockchains running a virtual machine. L1 workloads are isolated, so activity on one L1 does not directly consume another L1's execution capacity. Avalanche Warp Messaging provides native cross-Avalanche-L1 communication capabilities, while every L1 validator must sync the Primary Network P-Chain for interoperability.

Avalanche L1s are deployed by default with Subnet-EVM, a fork of go-ethereum. It implements the Ethereum Virtual Machine and supports Solidity smart contracts and most other Ethereum client functionality. Operators can customize the EVM, add precompiles, configure native gas-token behavior, and use validator-management contracts; this combination gives developers Ethereum compatibility with application-specific control.