Layer two designs are compared on fees and speed, and the substantive difference between them is what happens to the data.
The basic idea
Execute transactions elsewhere, and post enough information to the base layer that the result can be verified or challenged.
Which moves computation off the expensive layer while keeping some security property anchored to it.
The security property differs by design, and that is the whole substance of the comparison.
Data availability
If transaction data is published, anyone can reconstruct the state and prove what it should be.
Which means users can exit without the operator's cooperation.
If data is withheld, users depend on the operator to know their own balances, which is a materially weaker position.
Optimistic designs
Assume the posted result is correct unless challenged within a window.
Which requires at least one honest party watching and willing to submit a fraud proof.
The challenge window is why withdrawals take days, and third-party liquidity services exist to bridge that delay at a cost.
Validity proof designs
Post a cryptographic proof that the state transition was executed correctly.
Which removes the challenge window, since correctness is proven rather than assumed.
Proof generation is computationally expensive, and this is where much of the engineering effort sits.
The variants that keep data elsewhere
Designs that post proofs but keep data off the base layer occupy a different security category.
Which is a legitimate trade-off for some applications and should not be described as equivalent.
The specific risk is that the operator withholding data leaves users unable to demonstrate their balances.
Sequencers
Most current designs use a single sequencer ordering transactions.
Which is a centralisation point, capable of censoring or reordering, though generally not of stealing.
Forced inclusion mechanisms, allowing transactions to be submitted through the base layer, are the mitigation and vary in quality.
Upgrade keys
Many deployments retain administrative keys able to change the contracts.
Which is arguably the largest practical risk in most of them and receives less attention than the proof system.
Public trackers document these arrangements per network, and checking them is more informative than reading marketing.
What to look at
Where the data goes, who can order transactions, who can upgrade the contracts, and whether you can exit unilaterally.
These four answers describe the actual trust assumptions.
Data blobs
Dedicated data space with separate pricing was introduced specifically for this use case on some networks.
Which reduced posting costs substantially and reduced fees on the layers using it.
The data is retained for a defined period rather than permanently, which is sufficient for challenge windows and for reconstruction by anyone monitoring.
Proof systems
Validity proofs use succinct proof constructions that verify quickly regardless of the computation proven.
Which is what makes the approach viable — a proof of thousands of transactions costs little to verify.
Different constructions have different trade-offs regarding setup requirements, proof size and prover cost.
Trusted setup
Some proof systems require an initial ceremony producing parameters, where the discarded values would allow forgery if retained.
Which is addressed by multi-party ceremonies where a single honest participant suffices.
Newer constructions avoid the requirement entirely, and both approaches remain in use.
Interoperability between layers
Moving assets between two layers generally routes through the base layer or through a third-party bridge.
Which reintroduces bridge risk for what appears to be a movement within one ecosystem.
Shared standards for cross-layer messaging are being developed and are not yet universal.
Decentralising sequencers
Proposals include rotating sequencers, shared sequencing across multiple layers and auction mechanisms.
Which addresses censorship and introduces coordination complexity.
Progress has been slower than announced timelines suggested across most of the ecosystem.
Fees and what drives them
Costs on these layers are dominated by the cost of posting data to the base layer rather than by execution.
Which is why fees track base layer conditions and why dedicated data space reduced them substantially.
Compression of posted data is a meaningful engineering lever for the same reason.
Fragmentation
Liquidity and users spread across many layers reduces the depth available in any one.
Which is a genuine cost of the approach and is the subject of active work on shared standards.
Stages of maturity
Public frameworks classify these systems by how much of the security is actually enforced rather than promised.
Which distinguishes systems with working proof mechanisms and limited administrative control from those still relying on operators.
Most deployments sit at earlier stages than their marketing implies, and the classifications are published openly.
What to verify
Data location, sequencer control, upgrade keys and exit mechanisms.
Which is a short list that describes the actual trust position.
Where this is heading
Development is toward cheaper data availability, working proof systems and reduced administrative control.
Which is genuine progress and is uneven across deployments.
Judging a specific system on its current state rather than its roadmap is the sensible approach.