How Do Blockchains Differ? Layer 1s, Layer 2s and the Multichain Map

What actually makes one blockchain different from another?

The first axis is consensus, the method a network uses to agree on which transactions happened. Bitcoin uses proof of work, where miners spend electricity to win the right to add blocks. Ethereum has used proof of stake since it switched mechanisms in 2022, where validators stake ETH as collateral against dishonesty: at least 32 ETH per validator, and since the Pectra upgrade a validator with compounding (0x02) withdrawal credentials can hold an effective balance of up to 2,048 ETH (ethereum.org, proof-of-stake and withdrawal credentials documentation). The academy's comparison of proof of work and proof of stake covers the mechanics and the security assumptions of each; what matters here is that the choice shapes everything downstream, from energy use to how fast new blocks arrive.

The second axis is programmability. Bitcoin's design deliberately limits what its transactions can express: it moves value under signature rules, and less expressiveness generally means a smaller attack surface. Chains like Ethereum and Solana run smart contracts, programs that hold and move value under rules fixed in code, which is what makes tokens, decentralised applications and the risks in the academy's guide to smart contract, bridge and systemic risk possible. A chain that executes general code can do more, and accordingly has more ways to go wrong.

The third and fourth axes travel together: cadence and cost. Bitcoin's difficulty rule targets one block every ten minutes on average (its developer documentation describes an ideal of 1,209,600 seconds per 2,016 blocks, which is 600 seconds per block). Ethereum divides time into twelve-second slots (ethereum.org, proof-of-stake documentation). Solana's slot time was 400 milliseconds until August 2026 and has been 300 milliseconds on mainnet since 25 August 2026, with further reductions planned (Solana, network upgrades page, checked 23 September 2026). Block cadence is a different measure from finality, the point at which a network's rules treat a transaction as settled; how and when that point is reached differs by consensus design and can lengthen under network stress, and that gap is the subject of the academy's guide to how transactions get confirmed. Fees are set differently on each chain and move with demand, which the guide to gas and network fees covers in detail. Faster and cheaper can look like a simple improvement; the fifth axis shows what such a choice can involve.

The fifth axis is decentralisation, the number and independence of the parties running the network. A ledger's aim is that no single party can rewrite it or shut it out, and how far a network meets that aim depends on the set of operators behind it. In general, many independent nodes on modest hardware tend to make a network more costly to corrupt and harder to switch off, while a smaller set of powerful machines can make it faster and cheaper to run; the outcome for any one network depends on its design, its client software and how stake or hash power is distributed. Higher throughput is often achieved with hardware requirements that fewer parties can meet. This is the trade-off at the heart of the whole map, and it has a name in the field, the blockchain trilemma: security, decentralisation and scale pull against each other. The trilemma is a design heuristic that admits exceptions, and every network is a choice about which corner to favour.

What is a layer 1, and how do the major ones compare?

Layer 1 is the foundation storey: the network that settles its own history. When a Bitcoin transaction confirms, the record rests on Bitcoin's own miners and nodes, and it becomes progressively harder to reverse as further blocks are added on top of it. Each layer 1 has a native coin (BTC, ETH, SOL) that pays its fees and rewards its operators, and each makes the five-axis trade differently. The table compares the three reference points on a like-for-like basis: each row uses the same kind of measure for every chain, taken from the chain's own protocol documentation or its foundation's published reports, and each figure carries the date it was checked. None of the rows is a ranking.

Three cautions apply to the table. First, the operator rows are not directly comparable across chains: Bitcoin's security rests on miners and mining pools as well as nodes, Ethereum's on validator keys that pool into operators, and Solana's on a validator set that the Foundation counts and publishes; the Nakamoto coefficient (the smallest number of validators that could together censor the network) appears for Solana alone among the official sources used here. Second, block cadence is a protocol setting, and the fee rows describe how each protocol prices a transaction rather than what a transaction cost on any particular day. Third, the halt row records what each project has itself documented; absence of a documented halt is not proof that none occurred.

On the halts specifically, the Solana Foundation's own reports are the primary record. Its October 2022 performance report lists a 7-hour outage on 30 April 2022, roughly four and a half hours on 1 June 2022 and 6 hours 19 minutes on 30 September 2022; its incident write-ups cover about 17 hours offline on 14 September 2021 and about 19 hours 42 minutes on 25 to 26 February 2023; and its March 2024 report records a 4 hour 46 minute halt on 6 February 2024 (Solana Foundation, network performance reports and outage reports). The Foundation's Network Health Report of 20 June 2025 states that the network had "experienced 100% uptime for nearly 16 months" at that date; this guide has not checked a dated Foundation record covering the period since. Each Foundation report also states that no user funds were lost in the incidents it describes. The past halts remain part of the documented record of a design that favours throughput.

The pattern to take from the table is that each column is a coherent choice. Bitcoin accepts longer block intervals and a limited script to keep its design conservative, and many of the custody practices in the academy's complete guide to keeping crypto safe grew up around it. Ethereum accepts fee pressure under load in exchange for general smart contracts, with a minimum stake per validator key and no official count of the independent operators behind those keys. Solana's published validator recommendations call for heavier hardware, its Foundation counted 1,295 consensus validators as of 16 April 2025, and its own reports document past halts, alongside sub-second block cadence and a low fixed base fee. None of these is the correct answer in general; each is the correct answer to a different question, and each position can change as protocols upgrade.

Beyond the big three sit dozens of other layer 1s, including BNB Chain, Avalanche, Cardano and Tron, each making its own version of the same trades. The five axes are the portable tool: ask where a chain sits on each, and especially who runs it and how many of them there are, and you can place any network you meet without needing a new mental model each time.

What is a layer 2, and what do you trade for cheaper transactions?

The reason layer 2s exist is arithmetic. A decentralised base chain has limited space per block, and when demand exceeds it, fees climb. The scaling approach Ethereum has taken moves much of the work off the base chain: execute transactions on a separate, faster network, compress the results, and post them to the layer 1.

The main design on Ethereum is called a rollup, and its name describes it: many transactions are rolled up into one bundle whose data lands on the base chain. L2BEAT, which tracks these networks, defines rollups as layer 2s that periodically post state commitments to Ethereum, validated either by validity proofs or accepted optimistically and open to challenge through a fraud-proof mechanism within a set window (L2BEAT, scaling summary, checked 23 September 2026). Networks such as Arbitrum One, OP Mainnet and Base work this way on top of Ethereum. Because many transactions share the cost of one base-chain posting, a layer 2 transaction usually costs far less than the same transaction on Ethereum itself; ethereum.org's layer 2 page shows live averages for both, and they move with demand. Ethereum's Dencun upgrade of 13 March 2024 added a cheaper data lane for rollups (EIP-4844 "blobs"), and the Fusaka upgrade of December 2025 added PeerDAS, a more efficient way for layer 2s to post and retrieve that data (ethereum.org, Dencun and layer 2 pages). Blobs are temporary. ethereum.org's Dencun page states that they are guaranteed to be available for around 18 days (4,096 epochs) and are then pruned from the network, a window it describes as a buffer over typical seven-day rollup withdrawal periods. After that, the full data survives only where rollup providers, block explorers or indexing services have chosen to store it, while the state commitments remain on Ethereum. A rollup can instead post its data as calldata, which ethereum.org describes as permanent.

Not every layer 2 posts its transaction data to Ethereum. ethereum.org describes validiums as using "an offchain data availability model, where operators store all transaction data off Ethereum Mainnet", and L2BEAT's glossary defines a validium and an optimium as off-chain systems that settle with validity proofs and fraud proofs respectively and publish their data off-chain. Their state commitments still go to Ethereum, but whether users can reconstruct balances and exit depends on whoever holds the data: often a data availability committee, a set of members who attest that the data is available, or another data layer. That is an extra trust assumption a rollup does not add. The labels are a taxonomy with hybrids at the edges; a volition, for example, lets users switch between rollup and validium data availability (ethereum.org, validium documentation; L2BEAT, glossary, checked 24 September 2026).

Rollups come in two families that differ in how the base chain checks their work. Optimistic rollups publish results that stand unless challenged during a dispute window; ethereum.org describes a one-week challenge period before withdrawing to Ethereum, and L2BEAT lists shorter windows on some networks. Zero-knowledge rollups attach a mathematical proof that the results are valid, so exits do not wait for a dispute window, although proof generation and other steps can add their own delays, at the cost of heavier proving machinery that may concentrate control in fewer hands (ethereum.org, optimistic and ZK rollup documentation).

What settles on the base chain, and what does not

"Inherits Ethereum's security" is true of a narrower set of things than it sounds. The state commitments a rollup posts to Ethereum are as hard to erase as any other Ethereum transaction. The transaction data it posts is made available on Ethereum for anyone to check: permanently if posted as calldata, and for about 18 days if posted as blobs, after which it is pruned and survives only in copies others keep. A validium or optimium keeps its data off Ethereum from the start. Everything else about the layer 2 is a separate assumption, and it helps to name them the way L2BEAT's risk framework does (L2BEAT, risk analysis and glossary, checked 23 September 2026).

The sequencer orders and executes transactions and submits the data to Ethereum. Many rollups run a single sequencer; L2BEAT's Arbitrum One page, as displayed on 23 September 2026, describes one for that network. Where the proof system works as designed, a sequencer that misbehaves generally cannot steal funds, because the base chain accepts only state that passes those checks, though it can pause, reorder or exclude transactions. The question L2BEAT records is what users can do if it fails: on Arbitrum One, for example, users can force transactions in through Ethereum after a delay of up to one day.

The proposer publishes the claimed state root on Ethereum. If the proposer stops, the question is whether anyone else can propose or whether users have an escape hatch to exit with their assets.

The bridge contracts on Ethereum hold the deposits. They are code, and ethereum.org's own bridge documentation notes that one flaw in a bridge contract is enough to expose assets. The academy's guide to why cross-chain bridges keep getting hacked covers what has happened when that flaw existed.

The upgrade keys can change all of the above. L2BEAT's FAQ states that most layer 2 constructions are upgradable, and that until upgradability is disabled or controlled by a sufficiently decentralised body, funds can in theory be taken through the upgrade mechanism. Its "exit window" measure is the time users have to leave before an unwanted upgrade takes effect. On Arbitrum One, as displayed on 23 September 2026, the regular upgrade path carries a 10-day exit window, and a 9-of-12 Security Council can act without delay in an emergency.

L2BEAT summarises these assumptions in three maturity stages (L2BEAT, "Introducing Stages", 19 June 2023): Stage 0, where the rollup is effectively run by its operators; Stage 1, where it is governed by contracts with a functional proof system, independent user exits and a Security Council safeguard; and Stage 2, where the contracts run it with permissionless proofs and a Security Council limited to correcting proven errors. On 23 September 2026 the site listed Arbitrum One, OP Mainnet and Base at Stage 1. The stage is a snapshot of trust assumptions on a date, and it moves in both directions.

A useful habit for any layer 2 is to ask four questions: who orders the transactions and what happens if they stop, who proposes state and how funds exit if they vanish, how battle-tested are the bridge contracts, and who holds the upgrade keys and how much notice users get. The answers are published for the major networks; the point is to read them rather than to assume them.

Why do assets live on specific chains, and what is the difference between a coin and a token?

The distinction sounds academic and decides real losses. A native coin is created by the chain's own protocol, pays the chain's fees, and exists nowhere else. A token is an entry in a smart contract's ledger, a program on someone else's chain that records who owns how many units, which is how one chain can host many assets its designers did not create. Ethereum standardised the pattern with ERC-20, a standard for fungible tokens in which each unit is identical to every other (ethereum.org, ERC-20 documentation), and most chains with smart contracts have an equivalent.

Two practical consequences follow. First, a token inherits its host chain's properties and adds its issuer's: hold a stablecoin token and you depend on the chain's security and on the issuer's reserves at the same time, which is the layered analysis taught in what is a stablecoin. Second, and this is the one that costs beginners money, the same asset name can exist on many chains as unrelated deployments. USDC on Ethereum, USDC on Solana and USDC on Base are three different records on three different ledgers. An exchange withdrawal screen asking you to pick a network is asking which ledger to write to, and writing to a ledger the destination wallet does not follow can lose the funds outright. The guide to sending and receiving crypto turns this into a checklist; the map here is the reason the checklist exists.

What does the multichain map mean for holding crypto safely?

Chain identity comes first because many of the mistakes that cannot be reversed happen there. Wallet addresses on different networks can look alike, several ecosystems share identical address formats, and a transfer written to the wrong ledger often cannot be undone. Checking the network on both ends of a transfer, and sending a small test amount first for meaningful sums, is cheap insurance against a common self-inflicted loss.

Trust accounting comes second. On a layer 1, you trust that chain's operator set. On a layer 2, you trust the base chain for its state commitments (and, on a rollup, for making its data available), plus the layer 2's sequencer, proposer, bridge contracts and upgrade keys for everything else; on a validium or optimium, you also trust whoever holds the data. Behind a bridge, you trust whatever locked the original asset. For any cheaper network, the practical question is what would be stuck, and for how long, if one component failed. The custody arrangement, whether an exchange account or a self-custody wallet, leaves that arithmetic unchanged; it decides who can act when something breaks, and each arrangement carries its own risks, which is why this academy treats who holds your keys as the first decision and chain choice as the second.

Movement between chains comes third. According to ethereum.org's bridge documentation (page last updated 3 April 2026), bridges account for the top three hacks in decentralised finance by size, and even an honest hop adds fees, delays and new contracts to trust. Each additional chain and each crossing adds contracts and parties to the set being relied on, so the attack surface grows with the number of hops. When a hop is necessary, the questions in the bridge security guide apply: what holds the locked funds, who can move them, and what happens if the operators disappear.

Frequently asked questions

Is a layer 2 as secure as Ethereum?

For the part that settles, the answer is largely yes: a rollup's state commitments rest on Ethereum, and its transaction data is posted there too, although data posted as blobs is pruned after about 18 days. A validium or optimium keeps its data off Ethereum and adds a data committee or other data layer to trust. Every layer 2's sequencer, proposer, bridge contracts and upgrade keys are its own, and a "what if" shows why that matters. If a rollup's sole sequencer stops, transactions pause; on Arbitrum One, L2BEAT records that users can force a transaction in through Ethereum after a delay of up to one day. If an unwanted upgrade goes through the regular path, the exit window is the time available to leave: 10 days on Arbitrum One, with a 9-of-12 Security Council able to act without delay in an emergency (L2BEAT, Arbitrum One page, as displayed on 23 September 2026). A layer 1 user faces neither question and faces the layer 1's own operator risks instead. L2BEAT publishes these assumptions per network, with a dated stage rating.

Which blockchain is best?

Best at what, and on which date, is the answerable version. As of the figures in this guide, Bitcoin favours a conservative, limited design; Ethereum runs general smart contracts across a large validator set with demand-priced fees; Solana runs sub-second slots with a low fixed base fee, heavier published hardware recommendations, a Foundation-counted validator set and a documented halt record through February 2024. The five axes let you match a chain to a purpose; each of the three makes different trade-offs, positions change with upgrades and network conditions, and this academy ranks and recommends none.

Can I send Bitcoin to an Ethereum address?

No. The networks keep separate ledgers with incompatible address formats, and what circulates on Ethereum as "wrapped" bitcoin is a token whose issuer or bridge states that it is backed by bitcoin held elsewhere, with its own custodial trust to evaluate. Assets move between chains through bridges or exchanges, and each of these is a service with its own operators, contracts and risks.

Do I need different wallets for different chains?

Sometimes. Wallet software varies in which networks it follows: some wallets handle one chain, others handle many. What stays constant is that the network must match on both ends of a transfer. The wallet security guide covers how multichain wallets present networks and where the wrong-network mistake usually happens.

Why does the same stablecoin exist on many chains?

Because an issuer deploys a separate version on each network it chooses to support, each one a distinct contract on a distinct ledger. They are meant to be worth the same, and they are still separate assets: moving between them is a real transaction across chains, and each version depends on its host chain in addition to the issuer's reserves.

Sources and further reading

Primary and reference sources for this guide. Live figures (slot times, fees, staked ETH, L2BEAT stages and risk values) are as displayed on the access date given.

• Proof-of-stake (PoS). ethereum.org developer documentation, current version. https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/ (accessed 23 September 2026)
• Layer 2. ethereum.org, current version (Fusaka and PeerDAS note; live fee averages not quoted). https://ethereum.org/en/layer-2/ (accessed 23 September 2026)
• Optimistic rollups. ethereum.org developer documentation, current version. https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/ (accessed 23 September 2026)
• Zero-knowledge rollups. ethereum.org developer documentation, current version. https://ethereum.org/en/developers/docs/scaling/zk-rollups/ (accessed 23 September 2026)
• Cancun-Deneb (Dencun), including the FAQ on blob availability for around 18 days (4,096 epochs) and pruning. ethereum.org roadmap, activation 13 March 2024. https://ethereum.org/roadmap/dencun/ (accessed 24 September 2026)
• Validium (off-chain data availability, data availability committees, volitions). ethereum.org developer documentation, current version. https://ethereum.org/developers/docs/scaling/validium/ (accessed 24 September 2026)
• Withdrawal credentials (32 ETH minimum per validator; 0x00, 0x01 and 0x02 types; 2,048 ETH maximum effective balance for compounding validators). ethereum.org developer documentation, last updated 22 January 2026. https://ethereum.org/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/ (accessed 24 September 2026)
• EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, Final. https://eips.ethereum.org/EIPS/eip-4844 (accessed 23 September 2026)
• ERC-20 Token Standard. ethereum.org developer documentation, current version. https://ethereum.org/en/developers/docs/standards/tokens/erc-20/ (accessed 23 September 2026)
• Blockchain bridges. ethereum.org developer documentation, last updated 3 April 2026. https://ethereum.org/en/developers/docs/bridges/ (accessed 24 September 2026)
• Spin up your own Ethereum node (hardware requirements). ethereum.org, current version. https://ethereum.org/en/run-a-node/ (accessed 23 September 2026)
• Transactions (fees per byte; miner-chosen minimum). Bitcoin Developer Guide, current version. https://developer.bitcoin.org/devguide/transactions.html (accessed 24 September 2026)
• Gas and fees (base fee set by protocol and burned; priority fee). ethereum.org developer documentation, current version. https://ethereum.org/en/developers/docs/gas/ (accessed 24 September 2026)
• Block Chain (difficulty adjustment every 2,016 blocks, ideal 1,209,600 seconds). Bitcoin Developer Guide, current version. https://developer.bitcoin.org/devguide/block_chain.html (accessed 23 September 2026)
• Bitcoin Core requirements. bitcoin.org, current version. https://bitcoin.org/en/bitcoin-core/features/requirements (accessed 23 September 2026)
• Transaction Fees on Solana (5,000 lamports base fee per signature; prioritisation fee). Solana documentation, current version. https://solana.com/docs/core/fees (accessed 23 September 2026)
• Transaction Confirmation and Expiration (slot duration and finality lag). Solana developer guides, current version. https://solana.com/developers/guides/advanced/confirmation (accessed 23 September 2026)
• Reduced Slot Times (350 ms on 19 August 2026, 300 ms on 25 August 2026). Solana network upgrades, current version. https://solana.com/upgrades/reduced-slot-times (accessed 23 September 2026)
• Validator requirements (Agave). Anza documentation, current version. https://docs.anza.xyz/operations/requirements (accessed 23 September 2026)
• 9-14 Network Outage Initial Overview. Solana Foundation, September 2021. https://solana.com/news/9-14-network-outage-initial-overview (accessed 23 September 2026)
• Network Performance Report: October 2022. Solana Foundation, October 2022. https://solana.com/news/network-performance-report-october-2022 (accessed 23 September 2026)
• 02-25-23 Solana Mainnet Beta Outage Report. Solana Foundation, March 2023. https://solana.com/news/02-25-23-solana-mainnet-beta-outage-report (accessed 23 September 2026)
• Network Performance Report: March 2024. Solana Foundation, March 2024. https://solana.com/news/network-performance-report-march-2024 (accessed 23 September 2026)
• Solana Network Health Report: June 2025. Solana Foundation, 20 June 2025. https://solana.com/news/network-health-report-june-2025 (accessed 24 September 2026)
• Layer 2s summary and risk analysis. L2BEAT, live. https://l2beat.com/scaling/summary and https://l2beat.com/scaling/risk (accessed 23 September 2026)
• Arbitrum One project page (sequencer failure, exit window, Security Council). L2BEAT, live. https://l2beat.com/scaling/projects/arbitrum (accessed 23 September 2026)
• Glossary and FAQ (rollup, validium, optimium, data availability committee, sequencer, proposer, exit window, escape hatch, upgradeability). L2BEAT, current version. https://l2beat.com/glossary and https://l2beat.com/faq (accessed 24 September 2026)
• Introducing Stages: a framework to evaluate rollups maturity. L2BEAT, 19 June 2023. https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe (accessed 23 September 2026)