A layer 2 chain handles some transaction activity outside a base blockchain, or layer 1, while relying on the layer 1 for selected functions. To understand how a particular system works, examine what it executes itself, what it publishes to the layer 1, and which responsibilities remain elsewhere. The “layer 2” label alone does not establish a system’s security, settlement behavior, or payment performance.

What a layer 2 chain is—and what it is not

A layer 1 is the base blockchain in a layered system. A layer 2 is a system designed to perform some activity separately from that base layer while depending on it for specified functions. The division of responsibilities is not uniform: some architectures separate functions that another architecture may combine. source

A rollup is one kind of layer 2 architecture. It separates transaction execution from the base layer while publishing data to the underlying blockchain, where base-layer consensus establishes the published record. This is a description of the rollup model, not a guarantee that every system called a layer 2 follows it. source

The distinction between a rollup and a separate chain cannot be settled by branding alone. A useful architectural question is where the system places consensus and data availability. In L2BEAT’s terminology, a rollup uses a layer 1 for consensus and data availability; a system that publishes data elsewhere adds external data-availability assumptions and is classified differently. This terminology helps describe architecture, but does not rate an implementation’s safety. source

A separate blockchain may have its own participants and operating components. Hyperledger Fabric, for example, is documented as a permissioned-network model coordinating organizations, certificate authorities, peers, orderers, channels, policies, ledgers, smart contracts, and client applications. That example illustrates a distinct network architecture; it does not define every sidechain or layer 2. source

How transactions move from execution to settlement

A useful conceptual model separates a layer 2 transaction’s processing from the layer 1 record on which the system depends:

  1. Execution: The layer 2 processes activity outside the layer 1. Its own architecture determines how transactions are handled.
  2. Publication: The system publishes data or another representation of activity to the layer 1, according to its design.
  3. Layer 1 processing: The underlying network handles the published record under its protocol rules. For Ethereum, a full node independently verifies blocks and transactions against those rules rather than relying entirely on another node. source

These stages should not be treated as synonyms. A layer 2 application’s execution status, publication of information to a layer 1, and the layer 1’s handling of that information describe different parts of a system. The available evidence does not establish one universal timing or settlement guarantee for all layer 2 designs.

The distinction matters when setting operational expectations. A business evaluating a payment flow needs to identify what event its process treats as sufficient, and what technical record supports that decision. The layer 2 category by itself does not provide a confirmation policy or define when an external payment obligation is complete.

Rollup designs, data availability, and security dependencies

Data availability is a central architectural question: does the design use the layer 1 for it, or does it rely on a separate arrangement? Under the cited L2BEAT terminology, a rollup uses the layer 1 for consensus and data availability, while a system publishing data elsewhere adds external data-availability assumptions. That difference changes which components the assessment must include; it does not, on its own, prove that either design is secure or insecure. source

The broader architecture also determines which functions sit together and which are separated. One model describes a monolithic base layer as performing execution, settlement, consensus, and data availability together, while a modular stack can assign those functions to specialized layers. The terms are architectural descriptions, not evidence that a specific deployment has no additional dependencies. source

For a concrete system, technical documentation should identify the division of work and dependencies rather than rely on a broad category name. The evidence available for this explainer supports describing the rollup and data-availability distinction, but does not establish the sequencer arrangements, upgrade controls, withdrawal paths, or recovery procedures of any particular network. Those points therefore require system-specific documentation before they can inform an operational assessment.

Payment trade-offs to assess

The architecture alone does not establish a particular fee, throughput, transaction confirmation experience, or availability level. Those are system- and condition-specific matters, and the evidence here does not support a current performance comparison. Avoid treating general descriptions of layer 2 designs as promises about a particular payment flow.

Instead, make the assessment concrete. Determine which activity occurs on the layer 2, what information is published to the layer 1, and which layer 1 functions the system relies on. Then identify any additional components or procedures that the documentation says are necessary. For Ethereum specifically, full nodes verify blocks and transactions against protocol rules; this fact does not establish that every layer 2 transaction receives identical checks or that an application’s displayed status constitutes final settlement. source

Asset movement between networks is also a separate issue from transaction execution. A layer 2 label does not tell a reader whether a particular payment flow uses a bridge or another transfer arrangement. Assess that mechanism independently rather than assuming it is inherent to every layer 2 architecture.

Questions to ask before evaluating a specific network

Use primary technical documentation to answer questions such as:

  • Which functions does the layer 2 perform, and which does it rely on the layer 1 to perform?
  • Where are transaction data and other relevant records published? Does the stated architecture use the layer 1 or an external data-availability arrangement?
  • What does the documentation say happens between layer 2 execution and the layer 1 record, and which status does the business process rely on?
  • Which components or operating procedures are outside the layer 1, and what documentation describes their role?
  • If the payment flow moves assets across networks, what mechanism handles that movement? Assess it separately from the layer 2 execution model.
  • Are claims about fees, throughput, confirmation, security, or availability supported by current evidence for the specific system and conditions?

Treat answers as descriptions of a particular architecture, not as properties guaranteed by the words “layer 2.” This explainer does not compare named networks or establish current performance, access, security, legal, or tax conclusions. Those questions require current, system-specific or jurisdiction-specific evidence.

Sources and references