Map the jobs of Avalanche’s Primary Network chains and L1 validators. Use the Cortina and Etna changes to understand why older architecture descriptions need dates.
Three Primary Network chains, different responsibilities
Avalanche's Primary Network contains the X-Chain for asset operations, the P-Chain for validator and network coordination, and the EVM-based C-Chain for smart contracts. These roles do not imply three independent sets of guarantees for a user interface. A wallet still needs to identify the correct chain, transaction type and destination.
The current AvalancheGo architecture documentation describes the software that supports the Primary Network and Avalanche L1s. EVM compatibility on the C-Chain helps developers reuse tools, but a deployed application must still test addresses, infrastructure, contracts and external dependencies.
The X-Chain is no longer a DAG on the Primary Network
The earlier article described today's X-Chain as a directed acyclic graph using the old non-linear Avalanche consensus engine. That is obsolete. The Cortina upgrade linearized the X-Chain; current consensus documentation identifies April 2023 as the mainnet transition and says the DAG engine is no longer used on the Primary Network.
The linearized X-Chain uses the Snowman family alongside the P-Chain and C-Chain. A diagram showing an X-Chain DAG can explain historical architecture, but it should carry its version date rather than stand in for the current design.
Snowman consensus explained: four steps
Snowman reaches agreement on a linear sequence of blocks. For a beginner, separate these four jobs:
- Validate. The virtual machine checks whether a proposed block follows the chain's rules. Invalid blocks do not become valid through voting.
- Sample. A validator asks a randomly selected sample of validators which valid branch they prefer.
- Update. Poll results influence the validator's preference and confidence. Polling repeats; one sample is not the final decision.
- Accept. When the protocol's acceptance conditions are met, the validator accepts the block and rejects conflicting alternatives.
Imagine two valid blocks competing at the same height. Both can pass the rules check, but the network must agree on one history. This is why checking validity and reaching agreement are different tasks.
This simplified walkthrough leaves out networking and proposer scheduling. See the official Snowman consensus and engine documentation for the mechanisms and configurable parameters.
Fast acceptance still has security assumptions
Snow-family protocols use repeated sampling to reach agreement. The official consensus explanation describes probabilistic safety, with parameters and assumptions about validator behavior and network conditions. It is therefore inaccurate to describe safety as unconditional or mathematically free of any possibility of conflicting outcomes.
Finality, application success and completion of a cross-chain transfer are also separate events. A transaction can be included and execute unsuccessfully. A source-chain transaction can finish while a destination-chain action is still pending. A claimed latency should state which event was timed and under what conditions.
Etna changed the requirements for Avalanche L1 validators
Avalanche's Etna release summary dates its mainnet upgrade to 16 December 2024. The Avalanche9000 explanation says the newer L1 validator model removes the requirement to validate the Primary Network and stake 2,000 AVAX there. L1s can define their own validator requirements, while their validators face the applicable continuous validation fee.
This does not mean Primary Network staking requirements disappeared, or that every legacy Subnet automatically has identical configuration. “Subnet” remains relevant in older documentation and deployments. Identify whether a description concerns the Primary Network, a legacy configuration or an L1 using the newer validator model.
Customization changes what must be checked
A dedicated L1 can choose application rules, validator participation and economic parameters. That flexibility does not automatically give it the same security as another L1 or the Primary Network. The actual validator set and management contracts matter.
For a hypothetical game chain, low local transaction costs could coexist with a small validator set or an administrative pause authority. For a financial application, a fast local confirmation could coexist with a slower collateral bridge. These are distinct design tradeoffs rather than one universal performance score.
A practical architecture worksheet
- Name the chain and software version.
- Identify who validates it and who can change validator membership.
- Separate transaction inclusion, execution outcome and cross-chain completion.
- Record gas costs and validation costs in their own units and time periods.
- Check the contracts and permissions used for cross-chain messages or assets.
The previous comparison table's fixed latency and blanket security rankings have been removed. Comparing Avalanche with another architecture requires current, matching workloads and an explicit account of shared versus independently configured security.
Revision history and scope
Updated 19 October 2026. Updated the X-Chain after Cortina and the validator model after Etna. Replaced unconditional finality and fee claims with their technical assumptions.
24 October 2026: Moved the earlier correction note below the lesson and added a reader-focused introduction. This is a presentation edit; the earlier factual review date is unchanged.
1 November 2026: Added a beginner walkthrough separating block validation, repeated sampling and acceptance, checked against the linked official consensus documentation.