Staking AVAX, calling a smart contract, and transferring an asset on the X-Chain involve different transaction rules. Avalanche’s Primary Network handles these operations across three blockchains, each running its own virtual machine.
The Primary Network documentation identifies PlatformVM as the VM behind the P-Chain, Coreth as the implementation powering the C-Chain, and AVM as the VM used by the X-Chain.
What Does a Virtual Machine Define?
In Avalanche, a virtual machine defines a blockchain’s application logic. It specifies the data the chain stores, the transactions it supports, and the changes those transactions can make. It also provides interfaces through which applications interact with that chain.
The official virtual machine overview describes a VM as a blueprint for a blockchain. Multiple chains can use the same VM while maintaining a separate state.
AvalancheGo connects this chain-specific logic to networking and consensus. The VM implements the rules used to process blocks, while the consensus engine coordinates agreement on which blocks are accepted. This separation lets developers build different blockchain behaviors around a common node framework. The VM architecture reference describes the interface between these components.
PlatformVM and the P-Chain
Despite its name, the P-Chain is a regular blockchain like the C-Chain and X-Chain. What sets it apart is the set of transactions PlatformVM supports. PlatformVM implements the operations used to manage validators, staking, and blockchain creation on the P-Chain. Its state includes validator records and information about the networks and chains registered within Avalanche.
For example, joining the Primary Network as a validator involves a P-Chain transaction processed under PlatformVM’s rules. Creating a blockchain also involves a platform transaction, which identifies the VM and the initial data that the new chain will use. The PlatformVM architecture documentation lists these operations and their transaction types.
Avalanche L1 validator management adds another part to this role. An L1 can use its own validator manager to authorize changes to its validator set. Under ACP-77, those changes are communicated to the P-Chain through Warp messages and processed according to the platform’s rules.
This gives the L1 control over its validator management while keeping the corresponding validator information available on the P-Chain. The L1’s application transactions continue to follow the VM used by its own blockchain.
Coreth and the C-Chain
Coreth is the Ethereum Virtual Machine implementation that powers the C-Chain. It executes EVM bytecode, maintains the chain’s execution state, and exposes Ethereum-compatible APIs. Solidity contracts deployed on the C-Chain run through this implementation. These capabilities are documented in the Coreth architecture reference.
For a developer, this means familiar contract languages and Ethereum-compatible tools can be used to build on the C-Chain.
Execution and consensus have separate responsibilities here. Coreth implements the contract execution environment, while the C-Chain uses Avalanche’s Snowman-based consensus infrastructure to agree on blocks. EVM compatibility describes how contracts execute; it does not determine which consensus protocol the chain uses.
Coreth also supports atomic import and export operations with the P-Chain and X-Chain. These operations provide a defined mechanism for moving AVAX between the Primary Network’s chains, even though those chains use different VMs and maintain separate state.
AVM and the X-Chain
The Avalanche Virtual Machine, usually shortened to AVM, implements the X-Chain’s asset operations. Its APIs support Avalanche Native Tokens, including asset information and transaction queries. AVAX is one of the assets handled on this chain. The X-Chain RPC documentation describes these interfaces.
AVM uses an unspent transaction output model, or UTXO model. A transfer consumes existing outputs and creates new ones. Each output identifies an asset and includes the conditions governing how it can be spent. The P-Chain also uses a UTXO model, while the C-Chain follows Ethereum’s account-based model.
For example, an output can specify an amount and the addresses whose signatures are required to spend it. A subsequent transaction supplies the corresponding input and authorization. The X-Chain transaction specification defines these structures and their validation requirements.
Older explanations often associate the X-Chain with Avalanche’s original DAG-based consensus. Cortina linearized the X-Chain in April 2023, and it now uses Snowman consensus. Its asset-focused VM and UTXO model remain useful distinctions when comparing it with the C-Chain. The change in consensus is documented in the consensus architecture reference.
How Do These VMs Relate to Avalanche L1s?
Developers building an L1 can choose a VM suited to their own application requirements.
The official custom VM guidance presents two starting points. Teams can use Subnet-EVM for an Ethereum-compatible chain or develop a custom VM. Coreth powers the C-Chain, while Subnet-EVM provides an EVM implementation intended for custom Avalanche L1s.
A custom VM can define its own transaction formats, state, and application rules while connecting to AvalancheGo through the required interfaces. That gives developers control over the chain’s behavior without requiring them to write the surrounding networking and consensus infrastructure from scratch.
Technical Terms Mentioned in the Text
Virtual machine
The software that defines a blockchain’s application logic, transaction rules, and state changes.
EVM
The Ethereum Virtual Machine, an execution environment for smart contract bytecode.
State
The data a blockchain maintains at a particular point, such as balances, contract storage, or validator records.
UTXO
An unspent transaction output that can be consumed by a transaction satisfying its spending conditions.
Dive into the Avalanche ecosystem today! Download the Core Wallet and unlock a world of seamless DeFi, NFTs, and more.