Understanding Avalanche’s P-, C-, and X-Chains and Independent L1s

Avalanche is a blockchain platform connecting the public Primary Network with independently operated Avalanche L1s. Within the Primary Network, the C-Chain runs smart contracts, the P-Chain handles staking and validator registration, and the X-Chain issues and transfers native assets. A custom L1 uses its own validators and execution rules and is responsible for its own security. This distinction separates C-Chain DeFi from networks built for games or institutions. Primary Network, Avalanche L1s

Three chains, one validator set

A chain is an individual ledger of transactions and state. A virtual machine (VM) defines which transactions are valid and how they change state; the EVM is one example. Validators are nodes that check these rules and participate in block consensus. One Avalanche L1’s validator set can validate one or more chains. The Primary Network, which runs three, is an example. L1 structure

Primary Network validators validate all three chains. Each chain has a separate role and balances, but the same validator set secures them. The C-Chain is not an L2 of the P-Chain. Chain roles

The C-Chain is the chain most application users encounter. It supports the Ethereum Virtual Machine and Solidity tools, with mainnet Chain ID 43114. It has separate balances, contract deployments, and liquidity from Ethereum. Issuing an ERC-20 on the C-Chain does not change its gas asset: fees are paid in AVAX. C-Chain and L1 gas, Primary Network

The P-Chain records Primary Network staking, L1 creation, validator registration, and changes to validator weights. It also supports updates authorized by an L1’s ValidatorManager contract and communicated through Warp messages. Registration manages validator information. The P-Chain does not execute each L1’s transactions or relay every cross-chain message. ACP-77

The X-Chain issues and transfers native assets under AVM rules. These assets use a different standard from C-Chain ERC-20s. The original X-Chain used a directed acyclic graph (DAG), but Cortina converted it into a linear chain with a total transaction order. A diagram depicting today’s X-Chain as a DAG is outdated. Cortina’s X-Chain linearization

What changed from Subnets to independent L1s

Under the earlier Subnet model, a validator also had to validate the Primary Network. ACP-77, activated with Etna, separated those obligations. Validators following the new L1 model sync the P-Chain to track validator information without validating the entire Primary Network. An L1 can define its own validator membership, gas token, fee market, and execution environment. Existing Subnets have not all automatically converted to this model. ACP-77, L1 operating model

The 2,000 AVAX is locked stake; the continuous fee is a consumed expense. Comparing them as equivalent spending confuses capital commitment with operating costs. The continuous fee is not a fixed monthly subscription either. It is a protocol charge that adjusts with the number of active L1 validators. Servers, RPC services, upgrades, and validator incentives remain separate costs. ACP-77 fee model

Consensus and each L1’s security boundary

Snowman is a consensus protocol in which validators repeatedly poll small samples to converge on a preferred block. On the Primary Network, AVAX stake weights a validator’s influence in sampling. Its probabilistic safety model depends on protocol parameters and the share of honest validators. Snowman++ adds block proposer selection. Fast finality is a design goal, but it does not establish one TPS figure or finality guarantee for every L1 and workload. Snowman consensus, Current C-Chain architecture

A C-Chain application relies on Primary Network validators and AVAX staking. An independent L1 application relies on that L1’s validator count and weight distribution, administrative powers, and economic incentives. P-Chain registration does not make every Primary Network validator check the L1’s blocks. The Primary Network generally penalizes poor participation by withholding rewards rather than slashing principal; a custom L1 can apply different rules. L1 security, Primary Network validator incentives

The security model also differs from an Ethereum rollup. A typical rollup derives security by connecting its data and state verification to Ethereum. An independent Avalanche L1 is responsible for its own validation and data availability. Isolating workloads and fee markets therefore comes with a need to assess validators and operating authority separately for each L1. Independent network design

C-Chain acceptance, execution, and settlement after Helicon

According to the official announcement, Helicon activated on mainnet on September 22, 2026, at 15:00 UTC. The C-Chain moved from its former Coreth execution engine to the Continuous Execution VM. Helicon announcement, Execution engine documentation

Continuous Execution separates consensus acceptance from transaction execution. Accepted blocks enter a queue, an executor processes them, and subsequent blocks settle the resulting state and receipt roots. Consensus and execution run concurrently; this does not mean all EVM transactions execute in parallel. Checking that a transaction can pay its costs at acceptance does not guarantee contract success or prevent an out-of-gas failure. Applications must distinguish block acceptance from a successful swap. ACP-194

Helicon also changed staking. The minimum Primary Network validation period is 48 hours, while the minimum delegation period remains two weeks. The 90% uptime requirement for rewards applies to validation periods starting after the upgrade. ACP-285 changes the reward curve gradually over 90 days following activation, so that transition is still underway on November 10, 2026. Helicon, Detailed staking guide

Asset transfers and message delivery

Export and import between P, C, and X

Moving C-Chain AVAX into P-Chain staking requires cross-chain export and import operations. A wallet can manage both, but C-Chain and P-Chain balances are separate. This Primary Network transfer mechanism uses shared UTXO memory. UTXO means an unspent transaction output. It is distinct from sending an ordinary ERC-20 transfer to another chain. C-Chain atomic transactions

ICM, Warp, and Teleporter between L1s

Interchain Messaging (ICM) is Avalanche’s framework for communication between chains. Its underlying Avalanche Warp Messaging authenticates messages by aggregating signatures from source-side validators using BLS cryptography. A relayer carries the message and signatures to the destination, which checks validator information recorded on the P-Chain and the required signature weight. The P-Chain does not execute the destination contract for each message. How ICM works

Trust in this path depends on the honesty of the source-side signers and the destination’s verification configuration. Delivery also needs an available relayer. Messages from the Primary Network have configuration-dependent signer exceptions, so one fixed quorum rule cannot describe every route. Warp verification rules

EVM applications can use TeleporterMessenger in ICM Contracts for delivery, duplicate protection, retries, and relayer rewards. A message may arrive successfully while its destination contract call reverts. Teleporter distinguishes completed delivery from failed execution and supports execution retries. Developers must design both message authentication and the destination application’s success conditions. ICM Contracts and execution retries

ICTT custody and mint authority

Interchain Token Transfer (ICTT) is an asset-transfer application built on ICM. Its basic Home/Remote model locks the original asset in a Home contract and issues a representation on a Remote chain. The return path burns that representation and releases the original asset. ICTT design

An authentic signed message does not by itself establish safe collateral custody or mint authority. The Home holding the assets and the Remotes authorized to issue representations need separate assessment. External Ethereum bridges and issuer-based transfer routes introduce their own trust models. An ICM connection also does not automatically pool liquidity or make applications on multiple chains execute atomically as one transaction. ICTT security considerations

Public DeFi and purpose-built networks

Lending, trading, and liquid staking connect on the C-Chain. Aave provides lending and borrowing, BENQI offers lending and sAVAX liquid staking, and LFJ provides trading infrastructure built around Liquidity Book. Using sAVAX in DeFi makes a staking position available to applications but adds contract, liquidation, and liquidity risks. Aave deployment addresses, BENQI, LFJ

Independent L1s serve applications that need their own gas economics or validator policies. Institutional tokenization can also use public chains, so corporate use of Avalanche should not automatically be classified as a custom L1 deployment.

FIFA’s material retains forward-looking migration language, which cannot by itself establish current completion. GUNZ’s product description likewise does not prove that all game logic executes onchain. BUIDL combines qualified-investor restrictions with offchain fund management, custody, and legal rights. These examples illustrate different uses; they do not support comparisons of user counts or revenue. FIFA announcement, FIFA Collect FAQ, GUNZ, Securitize’s BUIDL announcement

How ecosystem activity connects to AVAX

AVAX pays for Primary Network gas and secures it through staking. Independent L1 validators also pay their continuous fees in AVAX. Primary Network transaction fees are burned, while staking rewards issue new tokens. Burning fees alone does not establish that supply always declines. AVAX token, L1 validator fees

Independent L1s choose their own gas tokens and fee rules. More L1 transactions therefore cannot be converted one-for-one into additional AVAX gas demand. The connection to AVAX needs to be assessed through specific channels such as Primary Network use, staking, and L1 validator costs. Those conditions matter when distinguishing ecosystem activity from token value capture. L1 token economics

Choosing the C-Chain or a custom L1

For an application that needs public liquidity and existing wallets and tools, starting on the C-Chain is simpler. The team can focus on contracts and the product without operating a chain. The official L1 guide also suggests deploying on the C-Chain first and considering a custom L1 when its constraints become relevant. L1 selection guide

An independent L1 is useful when a custom gas token, validator admission policy, dedicated capacity, or upgrade authority is a product requirement. That choice includes responsibility for validator security, RPC services, explorers, key management, recovery, and cross-chain asset liquidity. An allowlist alone does not establish regulatory compliance or transaction confidentiality. The decision rests on whether the product’s concrete need for control justifies that operating burden. L1 configuration and responsibilities

Further reading

• Snowman Consensus: Repeated sampled voting and its safety model.
• ACP-77: Validator management and continuous fees for independent L1s.
• ICTT: Contracts and trust assumptions for asset transfers built on messaging.

References

All sources were checked on November 10, 2026.

• Avalanche Builder Hub: Primary Network, Avalanche L1s, AVAX Token.
• Avalanche Builder Hub: Cortina, Snowman Consensus, ACP-77.
• Avalanche Builder Hub: Helicon, C-Chain architecture, ACP-194, Staking for Professionals.
• Avalanche Builder Hub: ICM, ICM Contracts, ICTT.
• Product documentation: Aave, BENQI, LFJ, GUNZ.
• Adoption announcements: FIFA and Avalanche, FIFA Collect FAQ, Securitize and BUIDL.