A layer 2 is a separate network that processes transactions cheaply and periodically posts the results to a layer 1 for settlement, which means your fee falls, your waiting time changes shape, and your assets end up somewhere that is not quite where you think it is.
If you read nothing else
- Almost every guide on this topic starts with an architecture diagram. That is the wrong end.
- Start here: what you pay, how long you wait, and which network your balance is on.
- Same-named coin on two networks is two different balances. This is the expensive part.
- Getting assets between networks means a bridge, and bridges are their own risk.
- Withdrawing from a layer 2 back to a layer 1 can involve a delay of days on some designs.
Start with the fee
You want to send fifty dollars of a stablecoin to someone. On a busy layer 1 that might cost several dollars. On a layer 2 it might cost a fraction of a cent. That is the entire commercial argument for layer 2s, and everything else is engineering in service of it.
Where does the difference come from? A layer 1 charges you for space in a block that every node in the network must store and verify forever. That is genuinely expensive, and the price rises with demand because the space is fixed.
A layer 2 does the computation somewhere else, then posts a compressed summary of many transactions to the layer 1 as a single batch. Your transaction's share of that batch is what you actually pay for on the underlying chain, plus a small amount for the layer 2's own operation. Divide one settlement cost across a few thousand transactions and it becomes very small.
So a layer 2 fee has two components: your share of a batch posted to layer 1, and the layer 2's own charge. The first moves with layer 1 congestion, which is why layer 2 fees rise when the base chain gets busy even though the layer 2 itself is idle.
Why block space costs anything at all
It is worth pausing on this, because the reason is not obvious and it explains most of what follows.
When you pay a fee on a layer 1, you are not paying for the electricity of one computer running your transaction once. You are paying for every node in the network to receive it, validate it, and keep the resulting state forever. Add a transaction today and you have added a small permanent obligation to everyone who will ever run a node.
That is why the block size cannot simply be increased until fees go away. Bigger blocks mean more data for every node to store and verify, which means fewer people can afford to run one, which means the network is checked by fewer independent parties. The fee is not a tax; it is the price of a resource that is genuinely scarce because keeping it cheap to verify is the point.
A layer 2 changes the arithmetic by moving execution somewhere with different economics. One machine runs the transactions. The layer 1 stores a summary. The permanent obligation imposed on every node shrinks by roughly the compression ratio, and the fee falls with it.
What you are actually paying for, itemised
On a rollup, a single transfer's cost breaks into three parts, and knowing which is which explains why fees behave the way they do.
- Your share of the data posted to layer 1. Usually the largest component. Divided across everyone in the batch, and priced by whatever the layer 1 charges for data at that moment.
- The layer 2's own execution charge. Small, and usually stable, because the layer 2 has spare capacity most of the time.
- The operator's margin. Somebody runs the sequencer and the machines that produce the proofs, and that costs money. Some networks are explicit about this; some are not.
The practical upshot: when someone says a layer 2 is cheap, ask cheap relative to what, and at what level of layer 1 congestion. A rollup's fee is a derivative of the base chain's fee, and the derivative moves.
None of this applies to chains that are simply cheap on their own. Solana has low fees without a layer 2, by taking a different set of trade-offs at layer 1. TRON gets there differently again, by charging in staked resources rather than per transaction. “Cheap” and “layer 2” are not synonyms.
Then the waiting
Confirmation on a layer 2 is usually fast — often under a second, because a single sequencer is ordering transactions rather than a distributed set of validators reaching agreement.
What takes time is the other direction. Moving assets from a layer 2 back to its layer 1 can involve a built-in delay, and on one common design that delay is around a week. It exists so that anyone can challenge an invalid state before it is finalised, which is the security mechanism working as designed rather than a bug.
Most people never experience it, because third-party services offer instant withdrawals by fronting the funds and waiting out the delay themselves — for a fee. That is a real service and also worth understanding: you are paying someone to take a timing risk on your behalf.
So the honest summary of the timing is: fast to use, potentially slow to leave, and the slow part is something you can pay to avoid.
Then: where is my coin?
This is the section that saves money.
When you hold a token on a layer 2, you generally do not hold the layer 1 token. You hold a representation on the layer 2, backed by the real asset locked in a contract on the layer 1. The representation is only worth anything because that lock exists and the bridge behaves.
The practical consequences arrive fast:
- Addresses can look identical. On EVM-compatible networks the address format is the same everywhere. The same string is a valid address on the layer 1 and on twenty layer 2s. Nothing about it tells you which network the sender meant.
- Exchange withdrawals ask which network. That dropdown is not a formality. Choosing the wrong one sends real assets to a network where your wallet may not be able to reach them.
- Same ticker, different token. A stablecoin native to a layer 2 and the same stablecoin bridged onto it can both exist, with the same ticker and different contract addresses. They do not automatically trade at the same price and are not interchangeable.
- You need the gas token of whichever network you are on. Arriving on a new network with assets and no gas is a common and irritating dead end.
The same problem appears without layer 2s at all. Avalanche runs three chains in its Primary Network, each with its own balance for the same asset. USDT exists natively on several chains at once. If you are not sure what you are looking at, the address identifier will tell you which family an address belongs to and explain why it is shaped that way.
Bridges, and why they keep getting robbed
A bridge locks an asset on one network and issues a representation on another. That means, at all times, a contract somewhere holds the real assets backing everything that has crossed.
That is a large, static, publicly visible pot of value whose security rests on a specific implementation. It has proved to be one of the most attacked components in the industry, and several of the largest losses on record have been bridge exploits. The reason is structural: complexity plus concentration plus visibility.
Practical implications for someone just moving money around:
- A bridge run by the network's own team, using the network's own security assumptions, is a different proposition from a third-party bridge with its own validator set. Know which you are using.
- Bridged assets carry the bridge's risk in addition to the asset's own. A dollar token bridged twice is exposed to both bridges.
- Where a native version of an asset exists on your destination network, using it avoids one layer of this entirely.
Now the architecture
With the costs and the risks established, the structure is easy.
A layer 1 is a blockchain that settles its own transactions and provides its own security. Bitcoin, Ethereum, Solana, Cardano and the rest of the networks in this archive are layer 1s. If it has its own validator set deciding what is true, it is a layer 1.
A layer 2 processes transactions off the layer 1 and relies on it for settlement and, to varying degrees, for security. It does not have its own independent validator set deciding finality; it derives that from the chain beneath it.
The phrase “derives security from” is doing a lot of work in most explanations, and it covers a wide range in practice. A layer 2 that posts all its transaction data to the layer 1 and lets anyone reconstruct and challenge its state has a strong claim to that phrase. One that posts only a summary, with the data held elsewhere, has a weaker one. The label does not distinguish them.
The useful question to ask about any layer 2 is: if the operator disappeared tomorrow, could I still get my assets out using only the layer 1? If yes, the security claim is doing real work. If no, or only with the cooperation of someone else, you are trusting an operator, and that is fine as long as you know it.
The sequencer, and why it is the part to ask about
Almost every layer 2 in production today has a single sequencer: one operator that receives transactions, decides their order, and produces blocks. That is how confirmations arrive in under a second — there is nobody to reach agreement with.
It also means one party can, in principle, reorder your transaction, delay it, or refuse it. It cannot steal your funds, because the state it publishes still has to be valid, but ordering has value and control over ordering is control over something real.
The mitigation most designs offer is an escape hatch: a way to submit a transaction directly to the layer 1 that the layer 2 is obliged to include, or to withdraw your assets using only layer 1 data if the sequencer stops responding. Whether that hatch exists, whether it has been tested, and how long it takes to use are the three questions that separate a layer 2 with a real security claim from one with a marketing one.
Decentralising the sequencer is on most roadmaps. Check whether it has happened on the network you are about to use rather than whether it is planned.
Data availability, without the jargon
One more idea, because it is the axis the newer designs actually differ on.
For anyone to check that a layer 2 behaved honestly, they need the transaction data. If that data is posted to the layer 1, anyone can download it, rebuild the state themselves, and prove a fraud if there was one. The layer 1 becomes a public noticeboard that nobody can take down.
If the data is kept somewhere else — a committee, the operator's own servers — then everything still works while that party cooperates, and the ability to independently check breaks the moment they stop. The state might be provably valid and still be unusable, because you cannot reconstruct what you own.
That distinction is the whole difference between a rollup and the cheaper designs that resemble one. Both can be reasonable choices. They are not the same guarantee, and the naming does not make it obvious.
The kinds of layer 2, briefly
Enough to read the terminology, no more.
Optimistic rollups assume posted transactions are valid and allow a challenge window during which anyone can prove otherwise. That window is where the multi-day withdrawal delay comes from. Simple, well understood, slow to exit.
Zero-knowledge rollups post a cryptographic proof that the batch is valid. No challenge window is needed because validity is proven rather than assumed, so exits are faster. The proving is computationally heavy and the systems are more complex.
Validiums and similar use validity proofs but keep the transaction data off the layer 1. Cheaper again, with an extra assumption: that whoever holds the data will make it available. That assumption is the trade.
State channels let two parties transact directly off-chain and settle a final balance on chain. Excellent for repeated payments between the same parties, not a general-purpose network.
You do not need to be able to explain a validity proof. You need to know that the withdrawal delay, the data availability assumption and the operator dependency differ between these, and that those three things are what will actually affect you.
A practical checklist
Before moving anything between networks:
- Confirm the network on both ends. The sending side's dropdown and the receiving side's expectation must match. Do this before you paste the address, not after.
- Check your destination supports it. Exchanges do not accept deposits on every network, and an unsupported deposit is a support ticket at best.
- Have gas on the destination. Assets you cannot move are assets you do not have.
- Send a test amount first when the value is meaningful and the route is new. The fee on a second transaction is cheaper than the alternative.
- Know your exit route and its timing before you go in, not when you want out.
- Prefer native over bridged where a native version exists.
None of this requires understanding the cryptography. It requires knowing that networks are separate places, that assets live in one place at a time, and that getting between them costs something and carries risk.
One transfer, followed all the way through
To make the abstractions concrete, here is what actually happens when you move a stablecoin from an exchange to a friend on a layer 2, in the order it happens.
- You choose a network on the withdrawal screen. This is the decision that matters most and it takes one click. The address you are sending to is valid on all of them; only your friend's wallet knows which one it can actually see.
- The exchange sends on that network. If it holds the token on the layer 1 and you asked for the layer 2, it bridges internally — which is why some withdrawals to layer 2s are slower and cost more than others on the same exchange.
- Your friend's wallet shows a balance. That balance is a representation on the layer 2, backed by assets locked in a contract on the layer 1. It is spendable there and nowhere else.
- They try to send it onward and cannot. No gas token on that network. Extremely common, entirely avoidable, and the reason to send a small amount of the network's native asset alongside.
- Later, they want it on the layer 1. Now the exit route matters: a native withdrawal with whatever delay the design imposes, or a third-party service that fronts the funds for a fee.
Five steps, and four of them are places where a wrong assumption costs money. None of them involve understanding a proof system.
When a layer 2 is the wrong answer
Worth stating, because the framing usually assumes cheaper is better.
For large, infrequent holdings, the fee saving is irrelevant and the added surface — a bridge, a sequencer, a withdrawal delay — is a cost with nothing on the other side. Something you move twice a year does not need a network optimised for moving things constantly.
When the destination does not support it, which is more often than you would expect. Exchanges support a subset of networks for deposits, and it is not the same subset they support for withdrawals.
When a cheap layer 1 does the job, which is the case for plenty of transfers. Several base chains have low fees without a layer 2 at all, by making different trade-offs at layer 1. Reaching for a rollup because it is the modern answer is not a reason.
When you cannot answer the sequencer question. If you do not know whether an escape hatch exists on the network you are about to hold value on, that is a reason to find out before, not after.
Primary references
- Ethereum.org on optimistic rollups, including batching, challenge periods and exits.
- Ethereum.org on zero-knowledge rollups, including validity proofs and data availability.
- Ethereum.org's bridge overview for bridge models and their security trade-offs.
This guide describes mechanisms rather than reporting figures, so it quotes no dated numbers. Fee levels, withdrawal windows and the set of supported networks all change; check the specific layer 2's own documentation for its current parameters, and your exchange's withdrawal page for what it actually supports today.
Related: how different chains charge for transactions · what this address format can identify · the record for the chain most layer 2s settle to