Skip to main content

Avalanche X, P, and C-Chain

The Avalanche Primary Network is three chains, and only one of them is an EVM. Core is one of the few wallets that exposes all three to dapps:

ChainAliasVMWhat runs there
Contract ChainCEVMSmart contracts, ERC-20s — everything Ethereum-shaped
Platform ChainPPlatformVMStaking, delegation, validators, Avalanche L1s
Exchange ChainXAVMUTXO-based asset transfers

C-Chain: nothing special required​

The C-Chain is an EVM. Every standard flow in these docs — eth_sendTransaction, signing, Wagmi — works unchanged. Chain id 43114 (0xa86a), Fuji testnet 43113 (0xa869).

X and P-Chain: build, then hand to Core​

X and P-Chain transactions are not EVM transactions — dapps build them with AvalancheJS and pass the unsigned bytes to Core for signing and broadcast:

// Get the user's X/P public key to derive their addresses.
const { xp } = await provider.request({
  method: 'avalanche_getAccountPubKey',
});

// Build the transaction with avalanchejs (here: a P-Chain delegation),
// then hand the unsigned bytes to Core.
const txHash = await provider.request({
  method: 'avalanche_sendTransaction',
  params: {
    transactionHex: unsignedTxHex, // from avalanchejs
    chainAlias: 'P',
  },
});

Core shows the user a decoded approval screen — for a delegation, that includes the validator, amount, and end time — then signs, broadcasts, and returns the transaction id.

The parameters beyond transactionHex and chainAlias handle UTXO selection (utxos, externalIndices, internalIndices); the method reference covers them.

Want the signature without the broadcast? avalanche_signTransaction returns signed bytes for you to submit through your own node — same transactionHex/chainAlias input, without the index arrays.

The X and P-Chain guide works through a complete delegation, from key derivation to confirmation.

Testing​

Enable testnet mode (Core settings, or avalanche_setDeveloperMode) to target Fuji's X, P, and C-Chains, and fund accounts from the testnet faucet.