Second layers are usually explained as a cheaper version of the chain underneath, which is true and useless. The interesting question is what they do differently to be cheaper, because every one of the differences is also the source of a risk that does not exist on the base chain. The fee is lower for reasons, and the reasons are the subject.
A blockchain is expensive because every participant verifies every transaction and stores the result forever. That redundancy is the security, and it is also the cost ceiling: no amount of engineering removes the fact that thousands of machines are doing the same work.
A second layer does the work once, somewhere else, and then writes a compressed record of what happened onto the base chain. The base chain no longer executes each transaction; it stores enough information for the outcome to be reconstructed or disputed. That is the whole trick, and the cost saving is proportional to how much is left out.
This makes the base chain a settlement layer rather than an execution layer, which is a genuine architectural change rather than a scaling patch. It also means the guarantees a user gets are no longer the base chain's guarantees directly, but whatever the mechanism connecting the two manages to preserve. Almost every practical difference follows from that sentence.
The base chain stops executing your transaction and starts recording that it happened. Everything a second layer gains and everything it risks comes from that substitution.
The first family publishes the transaction data and assumes the result is correct unless somebody proves otherwise within a challenge window. Anybody can submit a proof that a published state is wrong, and if nobody does within the window, the state is treated as final.
The second family publishes a cryptographic proof that the computation was performed correctly, which the base chain verifies directly. There is nothing to dispute because the correctness is demonstrated rather than assumed, and the finality arrives as soon as the proof is verified.
The trade-off is between assumptions and cost. The first family is cheaper to operate and inherits a delay plus a requirement that somebody is watching and able to challenge. The second removes both the delay and the watcher, and pays for it in the computational cost of producing proofs, which has fallen substantially and is still the binding constraint on what these systems can execute.
The saving comes from two places and it is worth separating them. Execution is done once by the layer instead of by every node of the base chain, which removes most of the computation. That part is straightforward and it is the part most explanations stop at.
The second and larger part is amortisation. The record written to the base chain covers many transactions at once, so the base chain cost is shared across everybody in that batch. A busy layer therefore has a lower per-transaction cost than a quiet one, which is the opposite of the intuition that congestion makes things expensive.
The practical consequence is that a layer's fee is not a fixed property of the layer. It moves with base chain congestion, with how full the batches are, and with how much data the layer chooses to publish rather than keep. A fee quoted today describes today, and comparing layers on a single observation is comparing two moments rather than two systems.
Somebody has to decide the order in which transactions are executed before the batch is written down, and in almost every deployed second layer today that somebody is a single operator run by the team that built the layer. This is the part that most contradicts the mental image of a decentralised system.
What a single sequencer can do is bounded but real. It can decide the order, which matters wherever ordering has value. It can decline to include a transaction, which is censorship in the narrow technical sense. What it usually cannot do is steal, because the state transitions still have to be valid, and an invalid one is either disproved or unprovable depending on the family.
Most designs include an escape hatch: a way to submit a transaction directly to the base chain and force its inclusion if the sequencer refuses. It is worth knowing whether the layer you use has one and whether it has ever been exercised, because a mechanism that has never been used in anger is a design rather than a guarantee.
In the first family, the challenge window has to be long enough for an honest party to notice a wrong state and submit a proof, including during a period of base chain congestion. That is why withdrawal delays are measured in days rather than minutes, and the length is a safety parameter rather than an inefficiency.
The delay applies to the trustless exit, not to every exit. Third-party services will advance you the funds on the base chain immediately and wait out the window themselves, charging for the service and the capital. That is a useful product and it replaces a protocol guarantee with a counterparty, which is a different risk rather than no risk.
In the second family the delay is short because there is nothing to challenge, though it is not instantaneous: a proof has to be produced and verified, and production takes real time and real computation. The gap between the two families on this specific point is the most user-visible difference between them.
The phrase is used loosely and it has a precise meaning. What the base chain secures is that the layer cannot finalise an invalid state transition: it cannot credit you tokens that were never deposited, and it cannot let somebody spend what they do not have. That is a strong and genuine guarantee.
What it does not secure is everything outside that definition. It does not guarantee that your transaction is included, that it is included in the order you would prefer, that the layer's own contracts are free of defects, or that the operator will keep running the service. Each of these has failed in practice somewhere without any invalid state ever being finalised.
The honest summary is that the base chain secures the accounting and not the service. That distinction is the one to carry, because it explains why a layer can be simultaneously correct and unusable, and why an outage on a layer is a real event even when nobody loses a balance.
The base chain secures the accounting, not the service. A layer can be perfectly correct and completely unusable at the same time, and both have happened.
Each layer is a separate environment with its own copy of the assets and its own pools. The same asset on two layers is two different balances that happen to share a name, and moving between them means using a bridge with all the failure modes bridges have.
For anybody trading, the consequence is that depth is divided. An asset with substantial liquidity in aggregate can be thin on the specific layer you are on, and the price you get reflects the pool you reached rather than the market as a whole. That gap is largest exactly when it matters most, during fast moves.
It also complicates the arithmetic of cost. A cheaper transaction on a layer with less depth can be more expensive in total than a dearer transaction where the depth is, once the price you actually receive is counted. Comparing the fee alone is the error, and it is the error the marketing of every layer encourages.
Publishing all transaction data to the base chain is what allows anybody to reconstruct the state independently, and it is also the largest remaining cost. Some systems reduce it by keeping the data elsewhere and publishing only a commitment to it, which is materially cheaper.
That choice changes the security model rather than optimising it. If the data is unavailable, the state cannot be reconstructed by an outsider, and users depend on a committee or a separate network to keep serving it. These systems are usually labelled differently for exactly this reason, and the label is doing real work.
Whether the trade is acceptable depends on what is being held and for how long. It is a defensible choice for high-volume, low-value activity and a poor one for balances somebody intends to leave alone for a year. The mistake is not making the trade, it is not knowing which one you made.
Four things describe the situation more usefully than any brand comparison. Whether the sequencer is a single operator and whether a forced-inclusion path exists. Whether transaction data goes to the base chain or elsewhere. How long a trustless exit takes. And whether the contracts can be upgraded, by whom, and with what delay.
That last one is underrated. Many layers can be upgraded by a multisignature wallet, sometimes with a timelock and sometimes without, and an upgradeable contract holding your deposit is a different object from an immutable one. The existence of an upgrade path is not disqualifying and its absence from a security description is.
None of these require trusting a summary. All four are published, all four are verifiable, and reading them takes less time than the first trade you place. A trader who can answer the four is making a decision; one who cannot is accepting whichever answers happen to apply.
Sequencer decentralisation is the open engineering problem, and several designs exist without a settled consensus on which works at scale. The difficulty is that ordering has value, so distributing the right to order is also distributing a revenue stream, and the mechanisms that do this well without introducing new delays are still being tested.
Interoperability between layers is the second. Moving between two layers currently means returning to the base chain or trusting a bridge, and the standards that would let layers settle against each other directly are not yet common. Until they are, the fragmentation described above is a structural feature rather than a growing pain.
Neither of these is a prediction about what will happen. They are a description of what is currently unsolved, which is more useful, because it tells you which claims to read sceptically today. A layer that claims to have solved either should be asked how, and the answer is usually specific and checkable.
Two reasons. Execution happens once on the layer instead of on every node of the base chain, and the record written to the base chain covers many transactions at once, so that cost is shared across the batch. The second effect means a busy layer has a lower per-transaction cost than a quiet one.
One publishes transaction data and assumes the result is correct unless somebody proves otherwise within a challenge window. The other publishes a cryptographic proof the base chain verifies directly, so there is nothing to dispute. The first inherits a delay and needs a watcher; the second pays in the cost of producing proofs.
In almost every deployed layer today, a single operator run by the team that built it. It can decide ordering and decline to include a transaction, but it generally cannot steal, because state transitions still have to be valid. Most designs include a way to force inclusion through the base chain.
In the challenge-based family, the window must be long enough for an honest party to notice a wrong state and prove it, including during base chain congestion. It is a safety parameter, not an inefficiency. Third-party services will advance funds immediately for a fee, which replaces a protocol guarantee with a counterparty.
That the layer cannot finalise an invalid state transition: no crediting tokens that were never deposited, no spending what does not exist. It does not guarantee your transaction is included, that the layer's contracts are free of defects, or that the operator keeps running. The base chain secures the accounting, not the service.
No. They are two separate balances that share a name, each with its own pools, and moving between them requires a bridge. Depth is divided, so an asset that is liquid in aggregate can be thin on the layer you are on, and that gap is widest during fast moves.
Publishing all transaction data to the base chain lets anybody reconstruct the state independently. Systems that publish only a commitment and keep the data elsewhere are cheaper, but users then depend on a committee or separate network to serve it. These are usually labelled differently, and the label is doing real work.
Whether the sequencer is a single operator and whether forced inclusion exists; whether transaction data goes to the base chain or elsewhere; how long a trustless exit takes; and whether the contracts can be upgraded, by whom, and with what delay. All four are published and verifiable.