Layer 2 protocols handle some transaction execution outside a base layer and connect that activity to the base layer through a defined architecture. To understand a particular protocol, trace where transactions execute, what information is published, how the base layer participates, and which components have operational roles. The “Layer 2” label alone does not specify a protocol’s security, data-availability, settlement, or withdrawal guarantees.

What makes a protocol Layer 2?

In the Ethereum rollup model, transaction execution is separated from the base layer, while data is posted to Ethereum, where base-layer consensus establishes the published record. This describes a relationship between layers: execution happens outside Ethereum, but information about activity is published to it. It does not mean every task or guarantee is handled in the same way by every protocol. source

Several terms help make the relationship clearer. Execution means applying transactions and producing state changes. Consensus is the process nodes use to agree on new blocks and the continuing chain; its mechanics depend on the network. The distinction matters because a protocol can place execution and other functions in different locations. Saying that information is posted to a base layer does not, by itself, explain how every state change is checked or what conditions apply to settlement. source source

“Layer 2” is therefore an architectural label, not a complete description of a product, token, or guarantee. A protocol’s documentation needs to establish which functions are performed by its own components and which are assigned to the base layer. The Ethereum rollup model is one specific example; it should not be treated as a universal definition of every system called a Layer 2. source

This distinction also helps keep protocol architecture separate from general claims about scaling. The architecture described here identifies a division of execution and publication. It does not establish a particular transaction capacity, fee level, uptime, or user experience. Those claims would require current evidence for the individual system and the conditions being discussed.

How activity moves between a Layer 2 and its base layer

A conceptual rollup flow starts when a transaction is submitted for execution on the Layer 2. The protocol processes transactions and produces state changes outside the base layer. It then posts transaction data to Ethereum, where base-layer consensus establishes the published record. This sequence separates the place where execution occurs from the layer that records the published information. source

The model is useful, but it leaves important implementation details open. The claim that a rollup posts transaction data to Ethereum does not specify the exact data format, publication timing, or processing path for every transaction. Nor does it describe every step a particular protocol uses to establish that its state changes are acceptable. Readers need protocol-specific technical documentation for those details rather than filling gaps from the general architecture.

Architecture diagrams also use terms such as “node” and “validator,” which should not be treated as interchangeable. In Ethereum terminology, a node is a running instance of protocol client software connected to peers, with behavior determined by its client and configured mode. The name describes software and a role in the network, not necessarily every responsibility in a particular Layer 2. source

Ethereum provides a concrete example of role separation: an Ethereum node combines an execution client and a consensus client. A validator client is an additional role, required only when the node proposes and attests to blocks. These are Ethereum-specific roles. They should not be assumed to be the component names or operating arrangements used by every Layer 2 protocol. source

Settlement and withdrawal are also protocol-specific. The general rollup description establishes that execution occurs outside the base layer and transaction data is posted to Ethereum. It does not establish a universal withdrawal route, waiting condition, recovery procedure, or definition of when a particular user’s transaction is settled. Check the documentation for the system in question before relying on any such detail. source

Where Layer 2 protocols differ

A central design question is how a protocol checks the correctness of activity executed away from its base layer. The general rollup description supports the separation of execution from base-layer publication, but does not identify a single proof or challenge mechanism shared by all rollups. To compare correctness mechanisms, readers must look for evidence about the specific protocol’s state-transition checks and the role assigned to each component. source

Data publication is a separate question from execution. In the Ethereum rollup model described here, transaction data is posted to Ethereum. That statement identifies a publication location for this model; it does not establish how every protocol publishes data, what users can retrieve, or how long data remains accessible. Those additional properties need support from current, system-specific documentation. source

The same care applies to ordering and operations. A diagram may show that a protocol executes transactions and posts information to a base layer without identifying who performs every operational task or how authority is divided. The allowed architectural evidence does not specify a universal ordering mechanism, operator arrangement, upgrade authority, or bridge design. Those points cannot be inferred from the Layer 2 label.

A role-separation example from another technical setting illustrates why diagrams require context. Stratum V2 defines roles for mining devices, pool servers, optional proxies, job declarators, and template providers; a deployment can combine several roles in one software or hardware system. This example concerns Stratum V2, not Layer 2 architecture. It shows only that role names in a diagram describe a specified design and should not be imported into another system without evidence. source

When reading a Layer 2 diagram, identify the components that execute transactions and the information shown as reaching the base layer. Then consult that protocol’s documentation for roles not resolved by the diagram. In particular, verify how it describes correctness checks, data publication, authority, bridge assumptions, and failure handling. The evidence available for the general model does not answer those questions for a named implementation. source

Trade-offs to assess before relying on a protocol

Treat evaluation as a sequence of questions, not a ranking exercise. First, map which functions occur outside the base layer and what the protocol publishes to that layer. Second, determine what the protocol’s documentation says about checking state changes. Third, look for the specific transaction settlement and withdrawal conditions, rather than assuming that a published record automatically explains the user-facing process. The general rollup description supports the first part of this map but does not settle the implementation-specific questions. source

Next, identify which named roles belong to the base layer and which belong to the protocol under review. Ethereum’s execution client, consensus client, and optional validator client illustrate that even one network can distinguish roles; other systems may use different terms and arrangements. Do not assume that a role shown for Ethereum exists unchanged in a Layer 2 design. source

Keep architectural facts separate from operational claims. The relationship between off-base-layer execution and Ethereum publication does not establish fees, performance, uptime, supported features, or safety for a particular protocol. Those claims need current evidence about that system and the relevant conditions. This explainer does not recommend a protocol or infer outcomes from the architecture alone. source

Questions architecture diagrams cannot answer

A diagram can summarize a design’s components and show where a documented function takes place. It cannot, on its own, establish the full transaction lifecycle, withdrawal conditions, recovery process, or current operating characteristics. The evidence in this explainer does not provide universal answers for those matters. Verify them in current documentation for the specific protocol rather than treating a simplified architecture as a guarantee.

The same boundary applies to fees, availability, and yields. Nothing in the Layer 2 architecture described here establishes a fee amount, current availability, or yield. These are not properties to infer from the label or from the fact that execution and publication are separated. Any such statement requires relevant, current evidence for the named system and context. source

Technical architecture also does not answer legal, tax, or compliance questions. This explainer provides no jurisdiction-specific evidence on those topics, so it does not draw legal or tax conclusions. Keep those issues separate from the technical model and seek appropriate, jurisdiction-specific information when they matter. The useful architectural takeaway is narrower: identify where execution happens, what is published to the base layer, and which system-specific questions remain unanswered until the protocol’s own documentation is checked.

Sources and references