The Next-Generation Rollup Stack: How L1, L2, and L3 Blockchains Interact

Audience: Engineers, advanced students, sophisticated investors, and protocol designers

Introduction

Blockchains and digital ledgers are increasingly organized as multi-layered systems rather than single, monolithic chains. At the base sits a highly secure Layer 1 (L1) blockchain such as Ethereum, which provides consensus, settlement, and often data availability. Above it, Layer 2 (L2) and Layer 3 (L3) rollups execute the bulk of user transactions, post data or proofs back to lower layers, and inherit their security. Understanding how these layers interact is essential for evaluating the scalability, security, and usability of modern blockchain ecosystems.

This white paper explains how L1, L2, and L3 blockchains and digital ledgers communicate and compose with each other. We focus in particular on rollups—scaling systems that move execution off the base chain while anchoring security to it. We elaborate on the four-phase rollup lifecycle (deposit, execution, proof, finality), explore the spectrum between monolithic and modular designs, walk through concrete ecosystem architectures, and analyze data availability (DA) bottlenecks, blob markets, shared sequencers, and MEV-boost style designs. Throughout, we highlight how messages and value flow between layers and the assumptions that make these flows safe.

The discussion is written at a college level for readers comfortable with basic computer science concepts such as state machines, consensus protocols, and cryptographic proofs. At the same time, it aims to be detailed enough for engineers and protocol researchers to reason about real-world design trade-offs in multi-layer blockchain stacks.

Rollup Lifecycle: Deposit → Execution → Proof → Finality

Overview

A rollup can be modeled as a replicated state machine that outsources its security to another chain. Instead of every node on the base chain re-executing every transaction, the rollup executes transactions off-chain (or in a separate chain) and periodically commits compressed state updates or proofs to the underlying settlement layer. This reduces computation on the base chain while preserving security, provided that the commitments and associated data or proofs are correct.

The lifecycle of a rollup transaction can be decomposed into four canonical phases: deposit, execution, proof, and finality. Each phase describes how information flows between layers. Deposits move assets and messages from a lower layer to a higher one. Execution occurs primarily on the rollup, generating new state roots. Proofs or batch commitments are posted back down to the settlement layer. Finality determines when users can treat these state transitions as irreversible from both an economic and user-experience (UX) perspective.

Phase 1: Deposit (L1 → L2 → L3)

In the deposit phase, users or contracts on a lower layer initiate a transfer of assets or messages to a higher layer. At a technical level, this is implemented via a bridge contract on the settlement layer and a corresponding bridge or inbox contract on the rollup. The bridge contract on L1 escrows assets (such as ETH or ERC-20 tokens) or records messages, while emitting events or writing to storage in a way that can be authenticated and read by the off-chain infrastructure that powers the rollup.

For an L1 → L2 deposit, a user submits a transaction on L1 to the bridge contract. Once this transaction is finalized on L1, the L2 infrastructure—typically the sequencer and its associated relayers—monitors L1 for new bridge events. When it detects a valid deposit event, it injects a corresponding message into the L2 inbox. The L2 bridge contract then mints or credits the user with the appropriate representation of the asset on L2. This representation is usually fungible with the original asset because the L1 bridge contract holds a corresponding locked balance, ensuring that the system remains solvent.

For L2 → L3 deposits, the process is analogous but the L2 now plays the role of the settlement layer for the L3. The user interacts with an L2 bridge contract, which locks assets on L2 and produces an event or message that the L3 sequencer consumes. The L3 bridge contract then credits the user with L3-native representations of the assets. Importantly, a full L1 → L3 movement is typically composed as two hops: L1 → L2, then L2 → L3. Each hop has its own latency and trust assumptions, and the composition must be carefully reasoned about to avoid double-minting or solvency issues.

Communication in the deposit phase is therefore implemented as a combination of on-chain contracts, off-chain relayers or sequencers, and well-defined message formats. Security depends on the correctness of the bridge contracts and the settlement layer’s consensus, rather than on the honesty of the sequencer: even if the sequencer is malicious or offline, users can in principle reconstruct the relevant events directly from the lower-layer ledger.

Phase 2: Execution (Off L1)

Once deposits have been recognized, the bulk of user activity occurs during the execution phase. Here, the rollup behaves much like a standalone blockchain: it maintains a replicated state (accounts, balances, smart contracts), and it processes ordered transactions to transition from one state to the next. The main distinction is that this execution is not validated by the consensus protocol of the base chain; instead, it is validated later via proofs or fraud detection mechanisms when batches are posted back to the settlement layer.

On L2, a sequencer or set of sequencers is responsible for ordering transactions into blocks. Users send transactions to the sequencer through an RPC endpoint or similar interface. The sequencer chooses an ordering, executes the transactions against the current L2 state, and produces L2 blocks and an updated state root. L3 sequencers perform the same role, but their ledger is anchored to an L2 settlement layer instead of directly to L1. This creates a hierarchy in which each layer has its own execution environment, fee market, and potentially its own virtual machine (e.g., EVM-compatible or otherwise).

L3s often optimize execution for ultra-low fees, domain-specific functionality, or high-frequency trading workloads. For example, an L3 might adopt a specialized execution engine optimized for order book operations while still committing its results to an EVM-compatible L2. Communication between levels in this phase is primarily logical: higher layers rely on lower layers to eventually include their commitments, but they do not need synchronous interaction for each individual transaction. This separation enables high throughput but requires careful design of rollback semantics in the event that lower-layer finality is delayed or reorganized.

Phase 3: Proof (Fraud or Validity)

The proof phase is where the rollup convinces the settlement layer that the off-chain execution was correct. Two broad families of rollups implement this in different ways: optimistic rollups and zero-knowledge (ZK) rollups. The core idea is that the rollup periodically publishes compressed state information—such as a state root and transaction data—and provides either a mechanism to dispute incorrect updates (optimistic) or a cryptographic proof that the transition is valid (ZK).

In an optimistic rollup, such as Optimism or Arbitrum, batches are posted to the settlement layer under the assumption that they are correct by default. The rollup contract maintains a record of proposed state roots and the associated batch data. For a bounded challenge window (often on the order of a week), any party can submit a fraud proof that demonstrates a mismatch between the proposed state root and the correct result of executing the batch. Typically, this is implemented via an interactive dispute protocol that pinpoints the exact step where the transition diverges, allowing the settlement layer to re-execute only a small portion of the computation on-chain. If fraud is proven, the incorrect batch is reverted and the party that proposed it loses an economic stake, thereby dis-incentivizing dishonest behavior.

In a ZK rollup, such as zkSync Era, StarkNet, or Scroll, each batch is accompanied by a succinct validity proof—often a SNARK or STARK—that attests to the correctness of the state transition. The settlement-layer contract verifies this proof using a fixed verification circuit. Because verification is much cheaper than re-executing all transactions, the base chain can scale the checking of many off-chain computations. There is no need for a challenge window; instead, security rests on the soundness of the underlying proof system and the correctness of the circuits. This results in faster finality and simpler UX, albeit at the cost of more sophisticated cryptographic infrastructure.

For L3 systems, the proof hierarchy composes. An L3 posts proofs or commitments to its L2 settlement contract. The L2, in turn, posts its own proofs or fraud-data to L1. This means that an L3’s security reduces to the conjunction of its own proof system and the correctness of the L2 and L1 layers beneath it. Communication between levels is thus realized through a chain of proofs and commitments, with each layer treating the one below as a trusted ledger for verifying and storing these artifacts.

Phase 4: Finality (Economic & UX)

Finality refers to the point at which a transaction can be considered irreversible for all practical purposes. In layered systems, finality is multi-dimensional. There is cryptographic or consensus finality at the settlement layer, economic finality based on the cost of rewriting history, and UX-level finality that determines when users can confidently spend withdrawn funds or rely on cross-rollup messages.

For L2s posting to an L1 like Ethereum, optimistic rollups achieve finality only after the challenge window for fraud proofs has expired. Until then, a batch could in principle be invalidated, causing downstream state to roll back. This means that while transactions may appear final within the L2’s local context (because the sequencer will not voluntarily revert them), withdrawals to L1 are delayed until the challenge window closes. ZK rollups, by contrast, attain L1 finality as soon as the validity proof is verified on-chain. The delay is then dominated by proof generation and inclusion latency, often on the order of minutes to hours.

For L3s, finality is layered: an L3’s local notion of finality depends on its own proof or challenge mechanisms, plus the finality of the L2 that settles it, which itself depends on the L1. As a result, a withdrawal from L3 to L1 typically involves compounded waiting periods and multiple contract interactions. To mitigate poor UX, ecosystems often introduce fast bridges and liquidity providers that front assets on the target chain based on their assessment of the risk that the underlying withdrawal will be reverted. This approach improves user experience but introduces additional trust assumptions about the intermediaries facilitating cross-layer movement.

Why “Monolithic vs Modular” Is Not Binary

Blockchain system design is often described as a choice between monolithic and modular architectures. A monolithic chain performs execution, consensus, settlement, and data availability within a single protocol and validator set. A modular architecture separates these concerns across multiple specialized chains or layers, allowing each to optimize for a specific role. In practice, however, production systems almost always occupy a middle ground: they reuse some components across layers, repurpose existing chains for multiple roles, and evolve over time as new protocol features are deployed.

At the conceptual level, we can treat execution, settlement, and data availability as separate services. Execution is the process of applying ordered transactions to state. Settlement is the authoritative resolution of disputes and the enforcement of final state, typically implemented via consensus and economic guarantees. Data availability ensures that the information needed to reconstruct state and verify correctness is actually accessible to light clients and verifiers. Communication between layers consists of moving commitments and messages across these service boundaries, regardless of whether they are hosted on the same physical chain or multiple chains.

The Spectrum of Modularity

To understand why “monolithic vs modular” is not a binary choice, it is helpful to view blockchain stacks as points along a spectrum defined by how tightly coupled execution, settlement, and data availability functions are. At one end are classic monolithic chains, where a single consensus protocol and validator set handle user transaction execution, maintain the canonical state, and store enough data on-chain for anyone to reconstruct that state. Communication in such systems is mostly intra-chain: smart contracts and accounts interact by publishing transactions to the same ledger.

As we move along the spectrum, we encounter architectures where execution is offloaded to separate layers (such as rollups) that still rely on the base chain for settlement and DA. In these systems, messages and proofs must cross layer boundaries: execution engines supply commitments to settlement contracts, and settlement layers, in turn, provide data and dispute resolution services. At the far modular end, we find ecosystems where DA, settlement, and execution each run on distinct chains: a DA layer focused on scalable data publication, a settlement layer focused on secure proof verification and bridging, and multiple execution environments (L2s and L3s) that compose over them. Again, communication is implemented via smart contracts, relayers, and cross-chain protocols, not by a strict on/off modular switch.

Ethereum L1 Today (with Rollups)

Ethereum today is neither purely monolithic nor fully modular. As an L1, Ethereum executes smart contracts, maintains a canonical state, and provides data availability via calldata and, more recently, blobspace introduced by EIP-4844. At the same time, it serves as a settlement and DA layer for multiple rollups that perform the majority of end-user transaction execution off-chain. These rollups post their data or proofs back to Ethereum, leveraging its consensus security while alleviating its computational load.

In this model, Ethereum’s validators are responsible for including rollup batches and proofs in blocks, enforcing fraud proof outcomes, and storing enough data (either directly or via commitments) so that anyone can reconstruct the L2 state. Communication between Ethereum and its rollups is bidirectional: deposits and messages flow up from L1 to L2, while proofs, state commitments, and withdrawals flow back down. The same chain thus simultaneously plays the role of execution environment for native contracts, DA provider for rollups, and final arbiter for cross-layer disputes. This hybrid role illustrates that real-world systems occupy nuanced positions on the modularity spectrum.

Modular Stacks (Celestia / EigenDA / Avail / NEAR DA + Ethereum)

Modular stacks introduce specialized DA chains such as Celestia, EigenDA, Avail, or NEAR DA that decouple data availability from settlement. In a typical configuration, a rollup posts its transaction data to a DA chain optimized for high throughput and low cost, while posting validity proofs or fraud data to Ethereum for settlement and bridging. The DA chain exposes APIs and light-client protocols (e.g., data availability sampling) that allow nodes to check that data has been published without downloading it all, while Ethereum enforces the correctness of state transitions via on-chain verification logic.

Communication in these modular systems becomes multi-hop. The rollup protocol must coordinate commitments to both the settlement and DA layers, ensuring that the data referenced in proofs is actually available on the DA chain. Failure in either link—Ethereum or the DA layer—can undermine security. For example, if the DA chain withholds data, users may be unable to reconstruct the rollup state even if Ethereum faithfully verifies proofs. Conversely, if Ethereum suffers a consensus failure, the DA chain may continue to serve data, but the authoritative notion of finality for the rollup’s state becomes ambiguous. Designing robust communication protocols between these layers is therefore critical to making modular stacks safe.

L3s on L2s (Arbitrum Orbit, OP Stack L3s, zkSync Hyperchains)

L3 systems such as Arbitrum Orbit chains, OP Stack L3s, and zkSync hyperchains further extend modularity by allowing application-specific rollups to settle on L2s instead of directly on L1. In this arrangement, the L2 acts simultaneously as an execution environment for its own users, a settlement layer for its L3s, and often a DA layer (or a router to an external DA chain). L3s can then customize their execution logic, fee markets, and governance, while relying on the L2 for proof verification and bridging to other parts of the ecosystem.

Communication between L3s and their L2 parent is structurally similar to the L2–L1 relationship: bridge contracts manage deposits and withdrawals, proof-verification contracts enforce correctness, and cross-domain messaging channels allow contracts to send asynchronous calls across layers. However, the trust assumptions compound: an L3 user ultimately depends on both the L2 and L1 maintaining honest consensus and secure contracts. The benefit is that L3s can be tailored for niche use cases—such as high-frequency trading, gaming, or privacy-preserving applications—while still inter-operating with the broader ecosystem through the L2.

The Spectrum Summary

Summarizing, we can categorize architectures roughly as follows. Monolithic systems place execution, settlement, and DA on a single chain. Hybrid systems, like Ethereum with rollups, keep settlement and DA on L1 while migrating significant execution to L2 and L3 layers. Fully modular systems separate DA and settlement across different chains, with multiple execution environments composed on top. Each design point represents a different balance between simplicity, performance, and flexibility.

In every case, the interaction between layers is realized through concrete communication mechanisms: smart contracts that lock and mint assets, message queues that relay cross-domain calls, proof-verification circuits that attest to correctness, and DA protocols that guarantee retrievability of data. The “monolithic vs modular” framing is therefore best understood not as a strict categorization, but as a vocabulary for describing how and where these communication responsibilities are distributed.

Concrete Architectures of Major Ecosystems

Ethereum + OP Stack “Superchain”

The OP Stack is a modular framework for building optimistic rollups that share common infrastructure and governance primitives. In the Superchain vision, multiple OP Stack chains—such as Optimism Mainnet, Base, and others—form an interconnected set of L2s (and potentially L3s) that interoperate seamlessly while settling on Ethereum. Ethereum provides consensus, settlement, and DA (via calldata and blobs), while OP Stack chains handle the majority of user-level transaction execution.

In this architecture, an L1–L2 deposit involves a user interacting with an Ethereum bridge contract that is aware of the OP Stack rollup’s inbox contract. The rollup’s sequencer monitors Ethereum for events emitted by the bridge and injects corresponding messages into the L2. Execution proceeds on the OP Stack chain, and periodically the sequencer posts batches of transactions and state roots back to Ethereum. Fraud-proof mechanisms, defined in the rollup’s on-chain contracts, allow challengers to dispute invalid batches during a challenge window. L3s built on the OP Stack can repeat this pattern, treating an OP Stack L2 as their settlement layer while inheriting final security from Ethereum indirectly.

The Superchain concept further extends this model through shared infrastructure. Chains in the Superchain may adopt shared sequencers that provide a common ordering service across multiple OP Stack rollups. This enables near-atomic cross-chain transactions and faster bridging, as the same ordering layer can coordinate transaction inclusion across several L2s and L3s. At the same time, OP Stack chains can choose alternative DA providers (such as EigenDA) while still using Ethereum for settlement, demonstrating how communication pathways between layers can be reconfigured without changing the high-level execution environment exposed to developers.

Ethereum + Celestia / EigenDA / Avail Modular Rollups

A second class of architectures couples Ethereum with specialized DA layers such as Celestia, EigenDA, or Avail. In these designs, the rollup posts its transaction data to the DA chain, which is optimized to store large amounts of data cheaply and verify availability via sampling. Simultaneously, the rollup posts proofs or batch commitments to Ethereum, where settlement contracts enforce correct state transitions and manage cross-chain bridges.

The workflow for a batch in this setting typically involves several coordinated steps. First, the sequencer aggregates user transactions and encodes them into a batch. Second, the batch data is published to the DA chain, which returns a commitment (such as a Merkle root) that can be used to verify data inclusion. Third, the rollup posts the batch’s state root and DA commitment to Ethereum, together with either a validity proof (for ZK rollups) or fraud-related metadata (for optimistic rollups). Nodes that want to reconstruct the rollup’s state download the data from the DA chain and execute or verify the batch, checking consistency with the Ethereum-level commitment.

Communication between layers here is explicit and multi-directional. The DA chain and Ethereum must agree on the identifier for each batch so that the rollup’s commitments can be cross-checked. Light clients perform data availability sampling on the DA chain while simultaneously monitoring Ethereum for settlement events. If either chain fails—e.g., the DA chain withholds data or Ethereum rolls back blocks—then the guarantees about the rollup’s state are weakened. System designers therefore integrate escape hatches, such as emergency withdrawal mechanisms that allow users to exit the rollup using only the data already confirmed on the settlement layer.

ZK Ecosystems with L3s (zkSync, StarkNet, Arbitrum Orbit)

ZK ecosystems such as zkSync and StarkNet, as well as optimistic frameworks like Arbitrum Orbit, support hierarchies of L2s and L3s connected by proofs. In zkSync’s hyperchain model, for example, multiple app-specific chains (L3s) generate ZK proofs that their local state transitions are valid, and these proofs are recursively composed and ultimately verified on Ethereum. StarkNet envisions a similar design with StarkNet as an L2 and StarkNet-based appchains as L3s. Arbitrum Orbit allows developers to deploy L3s that settle on Arbitrum One or Nova, which in turn settle on Ethereum.

The lifecycle in these ecosystems involves proof aggregation and recursive verification. An L3 generates proofs of its own blocks and submits them to an L2 contract. The L2 then bundles multiple L3 proofs, along with its own transaction data, into a higher-level proof that is posted to Ethereum. This hierarchical structure means that communication between layers is primarily mediated by proofs and commitments rather than raw transaction data. Cross-chain messages still flow through bridge contracts, but their correctness can be reasoned about using the compositional properties of the proof system.

From a systems perspective, these ZK-centric designs push significant complexity into the proving infrastructure but simplify the trust model once proofs are verified. Messages and value can move across L2s and L3s with stronger guarantees of non-reversion after proof verification, which is attractive for applications requiring fast and robust finality. However, the recursive nature of the proofs means that delays or failures at any level can stall finality for all dependent chains, making robust monitoring and fallback mechanisms essential.

Data Availability Bottlenecks and Blob Markets

DA Bottlenecks

Data availability is the dominant scalability bottleneck for many rollup-centric architectures. Even if computation can be offloaded to high-performance execution environments, verifiers must still have access to the inputs required to recompute or validate the state transitions. If this data is not widely available, then a malicious sequencer could post commitments that are impossible to audit, undermining the security of the system. As a result, the capacity and pricing of DA resources on L1 and specialized DA chains largely determine the throughput and cost profile of L2s and L3s.

On Ethereum, DA is traditionally provided via calldata attached to transactions, which is stored permanently in the blockchain’s history. This approach is secure but expensive, as every byte of calldata competes for blockspace with regular transactions on the chain. EIP-4844 introduced “blobs”—temporary storage areas optimized for rollup data. Blobs are priced in a separate gas market with their own supply and demand dynamics. Rollups purchase blobspace to publish their batches, and the cost of this blobspace becomes a major component of end-user fees on L2. Because blob capacity per block is finite, multiple rollups must compete for the same resource, leading to congestion and fee spikes during periods of high demand.

Modular DA layers such as Celestia, EigenDA, Avail, or NEAR DA address this bottleneck by specializing in high-throughput, low-cost data publication. They use techniques like erasure coding and data availability sampling to ensure that even light clients can verify that data has been published without downloading it all. However, these chains introduce their own trust and failure modes: users must now assume that a majority (or qualified quorum) of DA validators behave honestly in making data retrievable. When combined with L2 and L3 layers, the overall system inherits the intersection of assumptions from all participating chains.

Blob Markets

The term “blob markets” refers to the economic layer governing access to DA resources, whether on Ethereum or external DA chains. On Ethereum, rollups bid for blobspace in a market that is separate from, but coupled to, the base gas market. If many rollups attempt to publish large batches simultaneously, blob prices increase, and L2 transaction fees rise accordingly. Protocol designers can attempt to smooth this volatility through batching strategies, compression schemes, and timing policies, but ultimately the elasticity of supply and demand determines the equilibrium price for DA.

External DA chains function as alternative blob markets. Rollups that use Celestia, EigenDA, or Avail pay those networks—often in their native token or in assets wrapped from Ethereum—for the right to publish data with certain availability guarantees. Because these chains can be tuned specifically for DA, they may offer cheaper or more predictable pricing than Ethereum blobs, especially if their validator sets and security budgets are smaller. The trade-off is that the rollup must now trust that these DA chains will not censor specific batches or withhold data.

For L2s and L3s, the choice of blob market is a key design decision that shapes both economics and security. An L2 that uses Ethereum blobs enjoys strong coupling to Ethereum’s consensus and avoids dependence on external DA validators, but it may be more sensitive to blob price volatility. An L3 might choose to rely on its L2 for DA, inherit its DA assumptions, or bypass the L2 entirely by posting data directly to a modular DA chain while still settling proofs on L2 or L1. Each configuration defines a distinct communication pattern and risk profile across the stack.

Shared Sequencers vs MEV-Boost Style Designs

Shared Sequencers for Rollups

Shared sequencers are an emerging concept that introduces a distinct ordering layer above DA and below execution. Instead of each rollup operating its own independent sequencer set, multiple rollups connect to a common sequencing network that orders transactions across chains. This shared ordering domain can be implemented as a proof-of-stake chain, a committee-based service, or another consensus protocol that provides a canonical cross-rollup transaction order.

The main advantage of shared sequencers is improved cross-rollup composability and atomicity. If two rollups rely on the same sequencer set, then a user can construct a transaction that spans both rollups (for example, swapping one asset on Rollup A for another on Rollup B) and have the shared sequencer include these legs in a single logical slot. Because ordering is coordinated, the likelihood of one leg executing while the other fails due to reordering or censorship is reduced. This property is particularly valuable for complex DeFi interactions that require consistent state across multiple domains.

From a communication standpoint, shared sequencers act as a hub for message routing. Rollups submit their transaction batches to the shared sequencer, which determines the global order and then forwards ordered batches to the appropriate DA and settlement layers. The rollups themselves still perform execution and proof generation locally, but their view of cross-domain activity is synchronized by the shared ordering service. The downside is that this centralization of ordering introduces a new trust and liveness assumption: if the shared sequencer fails, many rollups may experience correlated halts. Designing fallback paths, such as local emergency sequencing modes, is therefore crucial.

MEV-Boost Style Designs (PBS / Builder Markets)

Miner or Maximal Extractable Value (MEV) arises whenever block producers can profit by reordering, inserting, or censoring transactions. Ethereum’s MEV-Boost and proposer-builder separation (PBS) designs address this by separating the roles of block proposers and block builders. Builders compete in an auction to construct the most profitable block, and the proposer selects the highest-paying bid without directly seeing individual transactions. This reduces certain types of MEV abuse while retaining a market-driven approach to block construction.

Rollups can adopt analogous designs. Instead of a monolithic sequencer that both orders transactions and decides which ones to include, a rollup can allow multiple builders to propose candidate L2 blocks. A sequencer—potentially decentralized or shared across rollups—then selects the best block based on fees, MEV capture, or other policies. This “MEV-Boost for rollups” pattern creates a layered market in which searchers, builders, and sequencers each play distinct roles, similar to their counterparts on L1.

In such systems, communication channels arise between builders, sequencers, and the underlying settlement and DA layers. Builders must obtain the mempool of user transactions, construct candidate blocks consistent with the rollup’s rules, and commit to these blocks in a way that the sequencer can verify. Sequencers, in turn, must publish the chosen block data to DA layers and proofs or commitments to settlement layers. While this division of labor can improve efficiency and decentralization, it also increases protocol complexity and introduces new attack surfaces, including collusion between builders and sequencers or off-protocol side deals.

Comparison and Hybrid Approaches

Shared sequencers and MEV-Boost style builder markets solve different but related problems. Shared sequencers focus on global ordering and cross-domain atomicity: they are primarily about coordinating the relative order of transactions across multiple rollups. MEV-Boost style designs focus on how blocks are constructed and who captures the economic value from ordering within a single chain. A rollup ecosystem may use one, the other, or a combination of both, depending on its goals.

Hybrid approaches combine a shared ordering layer with competitive block building. In such designs, a shared sequencer network establishes the global sequence of transaction slots, but within each slot, multiple builders propose candidate blocks for each rollup. The sequencer chooses among these candidates using a PBS-like auction, thereby aligning incentives for efficient block construction while preserving cross-rollup coordination. Communication between the layers—the shared sequencer, builders, DA chains, settlement chains, and execution environments—must be carefully specified to avoid ambiguity about which transactions are final and in what order they occurred.

In all cases, the introduction of shared sequencing or PBS-style mechanisms modifies the security assumptions of the stack. Users must now reason not only about the honesty of validators on the DA and settlement layers, but also about the economic incentives and potential collusion among sequencers and builders. Properly designed crypto-economic mechanisms, slashing conditions, and transparency tools (such as open telemetry on ordering and inclusion) are necessary to maintain trust in this more complex, multi-layer communication environment.

Security Assumptions and Failure Modes Across Layers

Layer 1 (e.g., Ethereum)

The L1 blockchain underpins the entire rollup stack. Its consensus protocol, validator set, and economic security guarantee that finalized blocks are extremely costly to revert. Key assumptions include an honest or economically rational majority of validators, robust network liveness, and the absence of catastrophic consensus bugs. If these assumptions fail—for example, in a 51% attack or a prolonged censorship episode—then the security of all L2s and L3s anchored to this L1 is compromised for the duration of the incident.

From the perspective of cross-layer communication, L1 failures can invalidate or delay messages and commitments posted by rollups. Deposits that appeared confirmed may be reverted in a reorganization; proofs that were thought to be verified may be rolled back; and bridge contracts may observe inconsistent histories. To mitigate these risks, many protocols rely on “deep finality” assumptions—waiting for many blocks before treating L1 events as irreversible—and design emergency governance procedures that can coordinate recovery across layers if a severe L1 failure occurs.

Data Availability Layers (Ethereum Blobs / Celestia / EigenDA / Avail / NEAR DA)

DA layers guarantee that the data needed to verify rollup state transitions is actually accessible. Their core assumptions typically include honest majority or quorum properties among validators, correct implementation of erasure coding and sampling protocols, and continued network liveness. If a DA layer withholds data while still claiming that it has been published, then users and verifiers cannot reconstruct the rollup’s state, even if the settlement layer remains honest.

In a multi-layer architecture, DA failures manifest as frozen rollups: users cannot safely transact or exit because they cannot prove the correct state of their accounts. To address this, robust designs incorporate escape hatches that allow users to withdraw funds using only the data already stored or committed on the settlement layer, bypassing the need for fresh DA. Additionally, cross-chain monitoring and alerting systems can detect anomalies in DA availability and trigger defensive actions, such as pausing bridges or halting new deposits until the issue is resolved.

Settlement Layers (Ethereum for L2, L2 for L3)

Settlement layers host the smart contracts that verify rollup proofs, adjudicate fraud disputes, and manage cross-layer bridges. Their security depends on the correctness of contract code, the soundness of proof systems, and the economic incentives governing challenge mechanisms. A critical vulnerability in a rollup’s settlement contract—such as a re-entrancy bug or an incorrect verification condition—can allow attackers to mint assets, steal funds, or permanently brick the rollup.

For optimistic rollups, the challenge protocol must be robust: there must be at least one honest party with the ability and incentive to detect and challenge invalid batches. If all potential challengers are offline, coerced, or economically misaligned, then an attacker could push through an invalid state root that the settlement layer would accept as final. ZK rollups avoid the need for interactive challenges but rely heavily on the correctness of their circuits and the cryptographic assumptions underlying their proof systems. A soundness bug could allow the creation of proofs for arbitrary false statements, compromising the entire system.

Sequencers and Shared Sequencers

Sequencers and shared sequencing networks determine the order in which transactions are processed, which has direct implications for liveness, fairness, and MEV. Typical assumptions include that sequencers will eventually include valid user transactions (even if they may censor temporarily), that they will not finalize blocks with invalid state transitions, and that they cannot indefinitely halt the system without triggering fallback mechanisms. Violations of these assumptions lead to censorship or network-wide outages.

Under shared sequencing, the blast radius of a failure grows. If a shared sequencer network goes offline, misbehaves, or becomes heavily censored, many dependent rollups may lose the ability to process transactions in lockstep. To counteract this, protocol designs often incorporate local escape hatches that allow each rollup to temporarily revert to a local sequencer set or to force transaction inclusion via the settlement layer. These mechanisms must be carefully specified to avoid conflicting views of the canonical chain when the shared sequencer recovers.

L3-Specific Compounding Risk

L3s inherit all of the risks of the layers beneath them, plus any additional vulnerabilities introduced by their own contracts and governance. If an L2 suffers a DA outage, smart contract exploit, or governance takeover, all L3s that settle on that L2 are affected, even if their internal design is flawless. Likewise, any serious issue on L1 propagates up through L2 and into L3. The result is a stacked risk profile in which each additional layer increases expressive power and specialization but also compounds potential failure modes.

To manage these risks, designers of L3s must be explicit about their dependency model. Documentation and user interfaces should make clear which L2 and L1 chains an L3 relies on, what DA providers are in use, and what emergency procedures exist in the event of failures at lower layers. In some cases, L3s may implement migration paths that allow them to switch settlement layers if their parent L2 becomes compromised, though such migrations are complex and require careful coordination among validators, operators, and users.

Summary Table: Security Assumptions by Layer

Across the stack, we can summarize security assumptions and failure modes as follows. L1 assumes an honest majority and robust consensus; failures compromise all dependent layers. DA layers assume honest data publication and retrievability; failures freeze state and can trap funds. Settlement layers assume correct verification logic and proof soundness; failures enable theft or corruption of cross-chain bridges. Sequencers assume eventual inclusion and fair ordering; failures degrade liveness and UX. L3s assume all of the above, leading to compounding risk. Understanding these dependencies is essential when designing or investing in multi-layer blockchain systems.

Conclusion

The modern blockchain ecosystem is rapidly converging on a rollup-centric, multi-layer architecture in which L1, L2, and L3 systems interact through carefully designed communication protocols. The four-phase rollup lifecycle—deposit, execution, proof, and finality—provides a useful mental model for understanding how value and messages move between layers. Deposits and withdrawals are mediated by bridge contracts and relayers; execution occurs primarily off L1 in specialized rollup environments; proofs and commitments anchor this execution back to lower layers; and layered finality determines when users can safely treat state as immutable.

Rather than a strict choice between monolithic and modular designs, real systems occupy a spectrum in which execution, data availability, and settlement can be colocated or distributed across chains. Ethereum today plays a hybrid role as both execution environment and settlement+DA layer for rollups. Modular DA chains such as Celestia, EigenDA, Avail, and NEAR DA offer alternative blob markets that change the economics and trust assumptions of rollups. L3s on top of L2s introduce additional flexibility for application-specific logic while compounding dependencies on lower layers.

Shared sequencers and MEV-Boost style designs further enrich the architecture, creating new layers responsible for transaction ordering and block construction. These components enable powerful features such as cross-rollup atomicity and more efficient MEV markets, but they also introduce additional actors and communication paths whose behavior must be modeled and secured. Security analysis in this context becomes a multi-layer exercise: we must reason about the combined assumptions of consensus protocols, DA mechanisms, settlement contracts, sequencer incentives, and proving systems.

As the ecosystem matures, we can expect to see an increasing number of hybrid approaches that mix and match components across this stack. Some applications will prioritize the very strong guarantees of tightly coupled L1–L2 systems; others will accept additional modularity to achieve dramatic cost savings or custom execution semantics on L3s. For practitioners, the critical task is to understand not only the internal design of a given rollup or chain, but also how it communicates with and depends on the layers above and below it. Only with a clear view of these interactions can we build scalable, secure, and user-friendly digital ledgers for the next generation of decentralized applications.

---

Prepared by: Leslie L Aker

© January 2026

Mr. Aker is a computer scientist, consultant, and cryptographer. He has more than 40 years of professional experience working as an innovator and disruptive technologist in advanced technology research and development. He spent most of my career working at the Naval Research Laboratory in Washington, DC, the US Navy’s corporate research facility, founded by Thomas Edison. Mr. Aker worked in the Center for High Assurance Systems. That’s a nice way of saying he has been hacking computers for more than 40 years.