How Avalanche Works: Three Chains, Subnets & Consensus

In lesson one we said Avalanche's design is unusual: instead of one chain doing absolutely everything, it splits the work across three specialised chains and lets anyone launch their own custom networks. This lesson lifts the bonnet. By the end you'll understand the three chains and what each is for, what 'subnets' really are, and how Avalanche reaches agreement in a second or two without burning a power station's worth of electricity. None of it requires a computer-science degree — just a few good analogies.

The three chains: X, C and P

Most blockchains use a single chain for absolutely everything — issuing tokens, running apps, and tracking who validates. The trouble with that is simple: when one job gets busy, everything else slows down and fees climb for all of it. Picture a single shop counter handling deliveries, returns, and new sales at the same time, and you've got the idea — one slow customer holds up the whole queue. Avalanche instead has three built-in chains, each tuned for a different job, so a queue at one window doesn't hold up the others.

A quick way to remember them: X for eXchange of assets, C for Contracts, P for the Platform's plumbing. In practice, the vast majority of everyday activity — DeFi, NFTs, trading apps — happens on the C-Chain, because it speaks Ethereum's language and works with Ethereum's tools. That compatibility is the single biggest reason apps move across from Ethereum so easily: developers don't have to learn an entire new system from scratch, they just redeploy what they already have. When you withdraw AVAX from an exchange, it's almost always the C-Chain you'll be using — which is exactly why we'll keep coming back to it for the rest of the course. The X-Chain and P-Chain hum away in the background; you rarely touch them directly.

Avalanche consensus, simply

Every blockchain needs a way for thousands of computers, run by strangers who don't trust each other, to agree on the same history without a central referee waving a flag. Bitcoin solves this with energy-hungry mining — a global race to do deliberately pointless sums, where the winner gets to add the next block. Avalanche uses a completely different approach, usually called Avalanche consensus, and once it clicks it's genuinely elegant.

Here's the rough idea, with an analogy. Imagine you're in a packed stadium and everyone needs to agree on a single answer — say, a colour. Instead of polling all 50,000 people (which would take forever), you ask a small handful of random neighbours what they think. If most of them say 'blue', you lean blue too. Then you ask a fresh random handful, and again, and again. Because everyone is doing this independently at the same time, opinions snowball: a few quick rounds and the entire stadium has converged on the same answer, astonishingly fast. That repeated random sampling is exactly what Avalanche validators do with transactions, and it's why the network can settle things in a second or two even with a lot of participants taking part.

• Fast — transactions typically finalise in a second or two, with no waiting around for several blocks to 'confirm' on top of each other.
• Scalable — because each validator only ever talks to small random samples rather than the whole crowd, adding more validators doesn't grind the whole thing to a halt.
• Energy-light — it leans on staking rather than mining, so it doesn't burn the electricity of a small country just to stay secure.

Subnets: custom blockchains on demand

A subnet (short for 'subnetwork') is a group of validators who agree to run one or more of their own blockchains. The clearest way to picture it: Avalanche is less a single road and more a road-building kit. The three main chains are the motorway everyone shares, while a subnet is a private road a team builds for their own traffic — with their own speed limits and their own rules — while still using Avalanche's underlying engineering to lay the tarmac. They get customisation without having to invent a whole new network from nothing.

Why would anyone want that? Because sometimes the shared main chains don't fit the job. A blockchain game might want its own fee token so players never have to think about owning AVAX just to play. A bank might be legally required to make every single participant identity-verified for compliance reasons — something a fully open, anonymous network simply can't offer. A subnet lets each of them set exactly the rules they need without asking everyone else's permission, and without competing for elbow room on a crowded shared chain.

• Each subnet can set its own rules, its own fees, and even its own native token entirely separate from AVAX.
• Validators choose which subnets to help run — but every subnet validator must also help secure Avalanche's main network, so they're never fully off doing their own thing in isolation.
• Subnets are how Avalanche aims to scale to many independent apps at once without them all congesting one shared chain and pushing each other's fees up.

Subnets are central to Avalanche's whole strategy, and they come with their own risks — a small, new subnet is far less battle-tested than the main network, and its security rests on its own validators rather than Avalanche's full might. We look at real-world examples, and those risks in detail, in the Avalanche ecosystem guide at the end of the course. For now, just remember the shape: shared motorway, optional private roads.

Fees, validators and security

On the C-Chain, fees are paid in AVAX and work much like Ethereum's gas: the price floats with demand, so you pay more when the network is busy and less when it's quiet — think surge pricing on a taxi app, but for blockspace. A portion of the base fee is burned: permanently destroyed rather than handed to anyone, which slowly trims the total supply over time. It's a neat detail, and you'll hear it talked up a lot. But don't mistake 'some supply gets burned' for 'the price goes up' — plenty of other forces, demand chief among them, push the other way and can easily swamp it.

Security comes from validators staking AVAX. To run a validator you must lock up a minimum amount of it and keep your computer (your 'node') online and well-behaved around the clock; downtime or misbehaviour costs you rewards. Because anyone who meets the requirements can attempt to run one, the validator set is open rather than hand-picked by a gatekeeper. That openness is healthy — but as with any network, it's worth checking in practice how concentrated the stake actually is among large holders, rather than assuming 'open to all' automatically means 'evenly spread'. The two aren't the same thing.

Frequently asked questions