“Are L2s eroding the value of L1?”
“Is Ethereum losing its global composability?”
During the two years when L2s were at their peak, concerns like these permeated almost every corner of the Ethereum community.
Under Ethereum’s scaling framework at the time, L1 served as a stable but expensive settlement layer, while L2s provided cheaper and more efficient execution. This gave Ethereum more blockspace, but gradually eroded the cohesive experience of using it as “one chain.”
Over the past two years, these concerns have pushed Ethereum to reconsider the relationship between L1 and L2.
On the one hand, Ethereum L1 has continued to raise the gas limit and advance statelessness and zkEVM verification, no longer content to remain a low-throughput settlement layer. On the other hand, debate within the community has intensified. Earlier this year, Vitalik Buterin argued that as Ethereum mainnet improves its own scaling capabilities, some of the assumptions behind the five-year-old roadmap—which positioned L2s as the primary scaling solution—have changed. Further reading: “Making Sense of Vitalik’s L2 Rethink: Moving Past Fragmentation and Refocusing on Native Rollups”
More recently, Ethereum researcher Barnabé Monnot suggested that the long-term relationship between L1 and L2 needs to be reconsidered. This includes how L2s should create value in the future, why finality needs to arrive much faster, and whether L1 itself could, in a sense, become its own Rollup as proof systems are gradually integrated into mainnet validation.
These ideas do not yet amount to a finalized protocol roadmap, but they provide a valuable lens through which to view Ethereum’s future.
Ultimately, the challenge Ethereum faces today is no longer simply how to add more blockspace. As transactions, assets, and user state spread across an increasing number of execution environments, the deeper question is how responsibilities should be redistributed among L1, L2s, execution and settlement layers.
1. Ethereum Is Not Abandoning L2s, but Their Role Must Be Recalibrated
To be fair, when Ethereum’s Rollup-centric scaling roadmap first took shape, the primary role of L2s was relatively straightforward: to provide Ethereum with more—and cheaper—transaction capacity.
Given the technical constraints at the time, this division of labor made perfect sense.
Every Ethereum validator needed to re-execute L1 transactions, which meant mainnet throughput could not be increased aggressively in the short term. Rollups, by contrast, could execute transactions in batches off-chain and submit only compressed data or state commitments back to mainnet. This dramatically reduced the cost per transaction while preserving certain Ethereum security properties.
Ethereum scaling therefore developed along two parallel paths. L1 remained deliberately constrained, prioritizing decentralization and security, while L2s absorbed new transaction demand and continued to reduce costs through blobs, data compression, and proof systems.
But the assumptions behind that division of labor have now changed.
In 2026, the Ethereum Foundation reorganized its protocol work by merging the previously separate Scale L1 and Scale Blobs initiatives into a unified Scale track. Raising the gas limit, expanding data availability, optimizing execution clients, advancing statelessness, and moving the zkEVM attester client toward production readiness are now part of the same scaling framework.
In other words, Ethereum no longer treats L1 and L2 scaling as two separate tasks. Instead, it is beginning to allocate execution, consensus, and data capacity from a system-wide perspective.
This does not mean Ethereum is preparing to abandon L2s or move all activity back to mainnet. Rather, it means that L2s can no longer prove their long-term value solely by offering faster transactions and lower gas fees.
After all, if L1 can increase execution capacity by several orders of magnitude while preserving security and decentralization, general-purpose EVM execution and low-cost blockspace will no longer be capabilities unique to L2s. L2s will increasingly need to address differentiated requirements that L1 cannot serve uniformly, such as application-specific optimization, privacy features, and more flexible governance and economic models.
The Ethereum Foundation made this point explicit in its latest description of the L1–L2 relationship. Previously, the primary objective of L2s was to scale Ethereum, with differentiation and customization treated as secondary benefits. Today, their primary role is to provide differentiated features and customization while continuing to contribute additional scale.
L1, meanwhile, needs to become a sufficiently powerful, permissionless, and maximally resilient global hub for settlement, shared state, liquidity, and DeFi.
This effectively moves L2s away from a single technical category and toward a more complex spectrum.
At one end are Rollups that seek to inherit as many Ethereum security properties as possible. They aim to reduce reliance on multisignature security councils, enable permissionless proving, and ensure that users can still exit through L1 even if the operator stops functioning.
In the middle are execution environments that inherit selected Ethereum properties based on their business requirements. They may use stronger administrative controls, independent sequencers, or specialized compliance mechanisms in exchange for greater performance, privacy, or operational flexibility.
At the other end are chains that may use the EVM, support Ethereum-based assets, or connect to certain cross-chain infrastructure while remaining relatively independent in terms of security and settlement.
This is why Ethereum is not abandoning L2s, but redefining the division of labor. Over the past three to five years, L2 primarily referred to a scaling technology. In the future, it is more likely to describe a range of execution environments with different security, settlement, and liquidity relationships with Ethereum.
2. Interoperability Is Not Just About Moving Across Chains, but About Trusting State Across Chains
As Ethereum expands into a system composed of many L2s, another familiar problem becomes increasingly difficult to ignore: more L2s inevitably fragment liquidity, account state, and the application experience.
This has been evident in how people have used Ethereum over the past several years. A user may hold assets on one chain, use an application on another, and need to visit a third to complete a transaction. The same stablecoin may have different versions across networks, while the same account must manage different gas tokens, bridges, and asset entry points.
As a result, interoperability has become an increasingly important part of Ethereum’s roadmap.
The Ethereum protocol team has focused its 2026 Improve UX track on two areas: native account abstraction and interoperability. It views the key to addressing L2 fragmentation as making Ethereum “feel like one chain again”—a vision that depends partly on the maturation of intent-based architectures.
The Open Intents Framework (OIF), for example, allows users to specify only the outcome they want, such as “convert an asset on Chain A into USDC on Chain B.” Solvers then handle route calculation, fronted liquidity, execution, and rebalancing behind the scenes. Further reading: “Intents Standardized: How OIF Ends Cross-Chain Fragmentation”
The Ethereum Interoperability Layer (EIL) goes a step further by seeking to establish a trustless transport layer that makes cross-L2 transactions feel no different from single-chain transactions. Further reading: “Ethereum Interop Roadmap: Solving the Last Mile to Mass Adoption”
At the account level, EIP-7702, introduced through the Pectra upgrade, already allows traditional externally owned accounts (EOAs) to temporarily execute smart contract code, supporting features such as transaction batching, gas sponsorship, and recovery mechanisms. Native account abstraction proposals such as EIP-8141 seek to go further by embedding smart account logic directly into the protocol. The goal is to make smart contract wallets the default account model while reducing reliance on additional bundlers, relayers, and intermediary services.
L1 fast-confirmation rules are another important part of this effort. Before full finality is reached, they aim to provide a stronger confirmation signal within approximately 15–30 seconds. This can shorten application wait times in most ordinary scenarios and directly benefit every cross-chain application that depends on L1 finality. The implications are particularly significant for bridges, stablecoin settlement, and real-world asset transactions.
The real bottleneck in many cross-chain interactions is not whether a message can be sent, but when the destination chain can be sufficiently confident that the source-chain state will not be reversed.
One frequently overlooked point is that inclusion in a block does not mean a transaction has reached finality. From a user’s perspective, a transaction may appear successful within seconds. Bridges, exchanges, lending protocols, and cross-chain solvers, however, must still assess the risk of a chain reorganization and determine whether they can safely release assets or execute the next operation on another chain.
This is why many cross-chain services that appear to provide nearly instant settlement do not actually wait for the source chain to finalize. Instead, a solver or liquidity provider advances the funds. This mechanism improves the user experience, but it does not eliminate the underlying settlement delay.
Ethereum’s long-term objective is therefore to reduce finality from minutes to seconds. This is not a single scheduled upgrade, but a collection of research efforts that must be introduced in stages. They include decoupling finality voting from fork choice, optimizing the validator set, improving vote aggregation and network propagation, and gradually modifying the consensus protocol.
Ultimately, good interoperability is not about giving dozens of chains the same bridge button. It is about enabling different execution environments to trust one another’s state faster and at a lower cost.
3. If L1 Becomes Its Own Rollup, Does the Layered Boundary Still Exist?
If the changing role of L2s and shorter time to finality represent adjustments to Ethereum’s existing layered architecture, another idea raised by Barnabé goes a step further by challenging the definitions of L1 and L2 themselves: as proof systems are integrated into Ethereum mainnet, L1 could eventually become, in a sense, its own Rollup.
At first, this sounds counterintuitive.
A Rollup is generally understood as a scaling network built on top of L1. It executes transactions externally and relies on L1 to verify the resulting state. Ethereum itself is the underlying consensus and settlement network, so how could it become its own L2?
To understand this idea, it helps to separate the concept of a Rollup from its position in a layered architecture.
On Ethereum today, when a node receives a block, it re-executes every transaction in that block, independently calculates the resulting state changes, and determines whether the block complies with the protocol rules.
This model allows nodes to verify the chain independently, but it also means the network’s overall execution capacity must remain within the hardware capabilities of ordinary nodes. The more computation a block contains, the more hardware resources and time validators need to execute it.
In the future, as real-time proving and the L1 zkEVM mature, transactions could still be processed by high-performance execution nodes, but ordinary validators might no longer need to re-execute every transaction themselves. Instead, execution nodes could generate validity proofs after completing the computation. Other validators would then verify these smaller, less computationally expensive proofs to confirm that the state transition was correct.
From the perspective of execution and verification, this closely resembles a Rollup. One group of participants performs high-performance execution, compresses the result into a cryptographic proof, and submits it to a broader set of consensus participants, who verify the proof and confirm the final state without repeating the entire computation.
Barnabé’s description of “L1 becoming its own Rollup” is therefore better understood as a shorthand for this validation model. It does not mean Ethereum mainnet would be placed on another underlying chain or “downgraded” into its own L2.
The key point is that once proofs begin replacing the repeated execution performed by every node, “Rollup” may no longer refer only to a layer built on top of L1. It may instead describe a more general architecture for execution and verification.
This would further blur the traditional boundary between L1 and L2.
On the one hand, L1 could use zkEVM proofs to expand its own execution capacity. On the other hand, Native Rollups seek to give L2s more direct access to Ethereum’s protocol-level verification capabilities, allowing L1 to verify L2 state transitions in a more native and standardized way.
Today, different Rollups typically need to build and maintain their own proof systems, verification contracts, upgrade mechanisms, and security councils. If a proof system fails, an emergency upgrade becomes necessary, or an operator stops functioning, users may still depend on additional governance and trust structures.
The long-term direction of Native Rollups is to turn part of Rollup verification into a native Ethereum capability. This would allow L2s to reduce their reliance on custom security structures, inherit L1’s state-transition rules more completely, and potentially eliminate the need for security councils.
Looking further ahead, if multiple L2s can access one another’s state through faster L1 confirmations, standardized proof systems, and synchronous composability, their relationship with mainnet may no longer resemble a collection of isolated networks connected by bridges.
Instead, they may function more like multiple execution domains operating under the same Ethereum consensus. Some could support general financial activity, while others specialize in gaming, social applications, or payments. Still others could provide privacy or specialized compliance capabilities. They would use different execution logic and offer different products, but share a verifiable state framework, a common security foundation, and the same asset settlement system.
Of course, this remains a long-term direction.
But regardless of the precise form these technologies ultimately take, they are already transforming the boundary between L1 and L2 from a clear architectural divide into a spectrum of security inheritance.
Final Thoughts
Ethereum's history has often moved between fragmentation and recomposition.
Ethereum once achieved global composability through shared state. It later moved execution into Rollups to gain greater capacity. Now it must reconnect the assets, accounts, and applications that have been separated—without reversing the scaling gains it has already achieved.
For ordinary users, the ideal Ethereum should never resemble a network map made up of dozens of chains, different gas tokens, and bridges. Over time, wallets, applications, and underlying protocols can determine where a transaction is executed, which chain supplies the liquidity, and where final settlement occurs.
But the trust assumptions, security boundaries, and exit paths involved must not be hidden along with that operational complexity.
The endgame for L2s may therefore be neither to replace L1 nor to be displaced by an increasingly scalable L1. Instead, they may become a set of execution environments with different functions and performance characteristics that can nevertheless share security, liquidity, and state.
In the past, Ethereum gained greater capacity by separating execution.
In the next stage, we will see whether those separate pieces can come together once again as one Ethereum.