Ethereum Layer 2s are frequently presented as the natural path forward for blockchain-based financial infrastructure.
The promise is compelling: preserve Ethereum’s security and decentralisation while dramatically increasing throughput, reducing transaction costs, and enabling the scale required for serious financial applications. This narrative has gained significant traction.
Developers build on Layer 2s. Users entrust them with assets. Institutions increasingly evaluate them as viable foundations for trading systems, payments infrastructure, tokenised financial products, and decentralised market infrastructure.
If these claims were correct, Layer 2s would represent a meaningful advancement in blockchain architecture. Since they are not, the implications are significant. Financial infrastructure must be evaluated differently from consumer software.
Inconvenience is tolerable in social applications. Temporary degradation may be acceptable in entertainment platforms. Financial systems operate under a different standard.
Transaction ordering determines market outcomes. Access during stressed conditions can materially affect liquidity, solvency, and pricing conditions.
Trust assumptions around settlement, neutrality, and infrastructure control are not abstract technical details. They are core design requirements.
This makes precision especially important when evaluating claims around “scaling,” “decentralisation,” and “Ethereum-equivalent security.”
This paper argues that Ethereum Layer 2s do not solve the problem they are commonly presented as solving.
Optimistic rollups do not meaningfully increase Ethereum-secured throughput in the way often implied, because systems inheriting Ethereum’s security remain constrained by Ethereum’s shared publication bandwidth.
Zero-knowledge rollups improve verification efficiency, but blockchain consensus was never primarily about efficient verification. The core challenge is neutral transaction ordering and trust distribution. Zero-knowledge architectures introduce separate assumptions around sequencing, coordination, and operational control that remain difficult to reconcile with serious financial infrastructure.
Where explicit centralisation is acceptable, simpler and more operationally transparent systems already exist.
Where meaningful decentralisation is required, direct blockchain settlement provides stronger guarantees.
Layer 2s attempt to position themselves between these models.
This paper explains why that middle ground may be the least attractive place to build critical financial infrastructure.
What Layer 2s claim to offer
Layer 2 solutions are presented as a way to extend Ethereum beyond its base-layer limitations while preserving its core properties. In simple terms, they are marketed as delivering three key benefits.
First, scalability. They aim to increase transaction throughput and reduce costs so the network can support larger numbers of users and applications.
Second, inherited security. Transactions processed on Layer 2 are said to ultimately rely on Ethereum’s base layer for verification and final settlement.
Third, decentralisation. They are positioned as sufficiently trust-minimised systems where users can interact without relying on intermediaries or privileged operators.
If these three claims hold simultaneously, Layer 2s would represent a meaningful advancement in blockchain infrastructure. The rest of this article explains that they do not.
Throughout this paper, “Ethereum-secured” refers to systems where users can rely on Ethereum itself, rather than external operators or third parties, for transaction verification, data availability sufficient for independent state reconstruction, and trustless recovery of funds.
Optimistic Rollups Remain Constrained by Ethereum’s Shared Data Publication Capacity
Ethereum rollups generally fall into two architectural families: optimistic rollups and zero-knowledge rollups.
Although both are commonly presented as scaling solutions, they encounter different constraints.
Optimistic rollups cannot increase Ethereum-secured throughput because they remain constrained by Ethereum’s base-layer publication bandwidth.
For a rollup to inherit Ethereum’s security assumptions, it must publish sufficient information through Ethereum itself. This means rollup throughput is ultimately constrained not by how quickly transactions can be executed off-chain, but by how much information Ethereum can accept and make available on-chain.
The question is therefore not how many transactions a rollup can process internally. The question is how much transaction activity Ethereum can ultimately support through its shared publication layer.
Ethereum-Secured Rollups Require Publication
For a rollup (Layer 2) to inherit Ethereum’s security, it must publish enough transaction data on Ethereum itself in order for independent parties to reconstruct the state of the Layer 2 chain and withdraw funds without relying on the operator.
After Ethereum’s Dencun upgrade, this data is commonly posted through EIP-4844 blobs. Blobs are designed for rollups to lower storage costs, however they do not remove the core limit.
Even after Ethereum’s Pectra upgrade, Ethereum’s blob capacity remains limited. With a target of 6 blobs per block and a maximum of 9, the total network-wide publication bandwidth available to rollups is roughly 64 KB/s at target and 96 KB/s at peak.
Compression improves efficiency, but it cannot eliminate bandwidth limits. Better encoding may raise the ceiling, yet every rollup still runs into the same finite pipe.
This is a systemic constraint. Rollup throughput is not additive across many Layer 2s because all of them compete for the same blob space. Optimistic rollups change fraud assumptions, but does not remove the need to publish sufficient data.
Adding more Layer 2s divides a fixed resource. As demand rises, costs increase and sustained throughput falls. The result is that Layer 2s repackage limited throughput behind parallel systems.
Consider a rollup posting a 10,000 TPS workload. Under an extremely favourable model of simple spend only transactions with a minimal 105 bytes/transaction (20-byte sender + 20-byte receiver + 65-byte signature) and a very generous 95% size reduction that is far greater than the industry standard, the rollup would still require approximately 52.5 KB/s of publication bandwidth. This alone consumes over half of Ethereum’s maximum blob throughput, continually.
The scale of the constraint becomes apparent when realistic throughput targets are examined.
At this point there are only two possibilities.
Either throughput remains constrained by Ethereum’s shared publication bandwidth, or publication is moved elsewhere.
If throughput claims cannot realistically fit within Ethereum’s publication bandwidth budget, the alternative is external data availability. That may raise nominal throughput, but it weakens the claim that the system inherits Ethereum-level security.
Why Future Data Availability Upgrades Do Not Remove the Core Constraint
The defence to criticisms of Ethereum’s rollup scaling model is often that current blobspace constraints are temporary. Supporters argue that Ethereum’s scaling limitations today are only a short-term engineering problem and are to be fixed with upcoming updates.
They point to Ethereum’s roadmap, particularly danksharding and other planned data availability upgrades. They claim throughput limitations will eventually be solved through increased capacity.
This argument correctly identifies that Ethereum’s current blob bandwidth is limited, but it misdiagnoses the nature of the constraint.
The problem is not that Ethereum’s pipe is too small today. The deeper problem is that all rollups claiming Ethereum-level security must share the same pipe at all. Increasing blobspace does not eliminate contention; it merely postpones it.
Whether Ethereum provides 96 KB/s , 1 MB/s, or even 10 MB/s of shared publication bandwidth, the reality remains unchanged. Every rollup that wishes to inherit Ethereum’s security guarantees must publish sufficient transaction data into the same globally shared availability layer.
A globally shared publication layer means a common pool of bandwidth through which all rollups must publish information if they wish Ethereum itself to guarantee that the information remains available.
Throughput therefore remains a competitive shared resource rather than something that scales independently per application.
This distinction is critical because Ethereum’s scaling narrative often implies multiplicative throughput gains, as though each additional Layer 2 creates entirely new system capacity.
At this point, supporters of Layer 2 scaling may object that these limitations primarily apply to optimistic rollups.
After all, zero-knowledge rollups use a different verification model and are frequently presented as the next evolution of Layer 2 architecture.
If optimistic rollups remain constrained by Ethereum’s shared publication bandwidth, perhaps zero-knowledge systems solve the problem instead.
They do not.
The reasons, however, are different.
Why ZK Rollups Do Not Solve the Same Scaling Constraint
The previous section discussed Ethereum’s shared publication bandwidth constraint.
A common response is that zero-knowledge rollups solve this problem through more efficient compression and cryptographic validity proofs.
This response identifies a genuine improvement, but it addresses a different part of the architecture.
Zero-knowledge rollups primarily reduce verification costs. They do not eliminate the requirement that sufficient information be published if users are to independently reconstruct state and recover assets without trusting the operator.
This is a meaningful engineering improvement. However, it does not solve the core scaling constraint discussed above.
The bottleneck is not merely transaction verification. The bottleneck remains Ethereum’s shared publication bandwidth.
Zero-knowledge proofs may reduce the amount of information that must be published per unit of activity, but they do not eliminate the need to compete for the same finite publication resource.
For a Layer 2 to inherit Ethereum’s trust assumptions, independent participants must be able to reconstruct the Layer 2 state without relying on the operator.
This is a data availability question rather than a bandwidth question.
Data availability refers to the requirement that transaction data must be published somewhere that independent participants can access it.
This matters because if users cannot access the underlying transaction data, they cannot independently reconstruct the Layer 2 state.
It is important to distinguish data availability from publication bandwidth.
Data availability concerns whether users can obtain the information necessary to independently verify the system and reconstruct its state.
Publication bandwidth concerns how much information Ethereum can accept and make available over time.
These concepts are related but distinct.
A system may have excellent data availability while still be constrained by limited publication bandwidth. Conversely, a system may achieve high throughput by publishing less information, but only by weakening the assumptions that allow users to independently verify balances, reconstruct state, and recover assets.
The previous section focused on publication bandwidth. This section focuses on data availability.
Zero-knowledge proofs do not remove this requirement.
This distinction is important.
A zero-knowledge proof can prove that a state transition was valid.
It cannot by itself provide users with the information required to reconstruct the state that was proven.
Correctness and reconstruct-ability are separate properties.
A system may prove that its state transitions are valid while still requiring users to trust an external source for the underlying data.
This means that zero-knowledge rollups which claim Ethereum-equivalent security remain dependent on Ethereum’s shared data availability layer in exactly the same fundamental way.
Zero-knowledge systems can often compress execution data more aggressively than optimistic rollups, reducing the amount of data required per unit of activity. It does not however eliminate the architectural dependency.
As long as Ethereum is the system guaranteeing data availability, all Ethereum-secured rollups compete for the same finite shared resource. The problem therefore is not unique to optimistic rollups. It is inherent to the broader rollup model.
Increasing compression may delay the point at which congestion becomes economically painful, but it does not change the underlying structure. A larger shared pipe remains a shared pipe.
The only way to escape this constraint is to move data availability elsewhere.
Some zero-knowledge systems attempt exactly this by relying on external data availability layers, committees, or alternative availability assumptions.
However, once transaction data is no longer guaranteed available by Ethereum itself, the claim that the system fully inherits Ethereum’s security model can no longer be sustained, because users can no longer rely on Ethereum alone for independent state reconstruction and trustless recovery of funds.
This distinction matters because zero-knowledge rollups are often marketed as solving the scaling limitations of earlier Layer 2 designs. In reality, they solve a narrower problem.
Zero-knowledge rollups are therefore subject to two distinct critiques.
The first is architectural. Like optimistic rollups, systems claiming Ethereum-equivalent security remain dependent on Ethereum’s publication layer.
The second concerns trust. Even if publication constraints were somehow eliminated, financial infrastructure depends not only on transaction verification, but also on how transactions are accepted, ordered, and coordinated.
This introduces a separate set of assumptions around transaction ordering and system control.
ZK Rollups Replace Decentralised Consensus with Private Coordination
Zero-knowledge rollups are often presented as preserving decentralisation while improving performance. The implication is that cryptographic verification removes the trust assumptions that would otherwise accompany a faster, operator-managed system.
That framing is misleading. Zero-knowledge proofs solve the specific problem of proving that transactions were executed correctly according to the rules of the system.
They do not solve the separate and economically critical problem of deciding which transactions were accepted, when they were processed, and in what order they were executed.
That distinction matters because transaction ordering is one of the most sensitive functions in financial infrastructure.
The order in which transactions are processed can directly determine economic outcomes. A trade executed milliseconds earlier may receive a better price. A liquidation processed first may capture profit. A delayed transaction during market volatility may become economically worthless.
Ordering is not a technical implementation detail. It is a source of market power.
In a genuinely decentralised blockchain, transaction ordering emerges through open consensus among independent participants operating under a shared economic security model. No single actor determines inclusion or execution priority. This is one of the hardest technical problems blockchain systems solve.
Most zero-knowledge rollups do not solve that problem. Instead, they replace decentralised ordering with sequencers.
A sequencer receives transactions from users, decides which transactions to accept, determines execution order, constructs transaction batches, and coordinates submission for proof generation and settlement.
The zero-knowledge proof verifies that the chosen sequence was executed correctly. It does not decentralise who chose that sequence.
A private actor deciding transaction order and then producing cryptographic evidence that its chosen ordering followed the rules is not equivalent to decentralised consensus.
It is private coordination followed by mathematical verification.
Whoever controls transaction ordering can influence access, prioritise counterparties, delay competing activity, extract maximal extractable value, and shape market outcomes.
This creates a trust model fundamentally different from the neutral transaction ordering expected from decentralised financial infrastructure.
The Economics of ZK Rollups Favour Operational Centralisation
Supporters may argue that centralised sequencing is merely an implementation detail rather than a structural feature. Technically, zero-knowledge systems do not mathematically require a single sequencer.
This observation is correct, but incomplete.
The more important question is not whether decentralisation is theoretically possible. It is whether the economic incentives of the system naturally encourage decentralisation in practice.
The economic structure of zero-knowledge rollups differs significantly from the economic structure of traditional blockchain consensus.
In proof-of-work systems, the expensive work securing the network is mining. In proof-of-stake systems, security is provided by validators risking capital through staking. While these systems have their own centralisation pressures, the burden of securing the network can be distributed across many independent participants operating under a shared consensus process.
Zero-knowledge rollups operate differently.
The most computationally demanding task is not transaction execution or transaction ordering. It is proof generation.
zero-knowledge proof must demonstrate that an entire sequence of state transitions was executed correctly. Producing these proofs is computationally intensive, operationally specialised, and highly sensitive to infrastructure efficiency. As throughput increases, so does the complexity of generating proofs within commercially acceptable timeframes.
This creates a fundamentally different set of incentives.
The actors performing the most economically significant work are no longer participants contributing to a distributed consensus process. Instead, they are operators maintaining specialised proving infrastructure capable of generating validity proofs at scale.
As proving complexity increases, economies of scale become increasingly important. Access to specialised hardware, engineering expertise, operational coordination, and capital investment become competitive advantages. Larger operators can often generate proofs more efficiently, optimise proving pipelines more effectively, and spread infrastructure costs across larger transaction volumes.
This creates a natural tendency toward concentration.
More importantly, this concentration pressure emerges at a different layer of the system than traditional blockchain centralisation.
In proof-of-work systems, the expensive work securing the network is distributed across competing miners. In proof-of-stake systems, security is distributed across validators risking capital under a shared consensus process. The mechanisms may not be perfectly decentralised, but the architecture is explicitly designed to distribute the burden of security across many independent participants.
Zero-knowledge systems are different.
The most computationally expensive component of the architecture is proof generation itself. Rather than distributing this burden across a broad set of participants, the system derives its correctness from specialised proving infrastructure capable of producing validity proofs for the entire system.
Traditional blockchains distribute the expensive work that creates security.
Zero-knowledge architectures tend to concentrate the expensive work that creates correctness.
These are not equivalent economic models, and they should not be assumed to produce equivalent decentralisation outcomes.
While decentralised sequencing may be theoretically achievable, the economic burden associated with proof generation remains fundamentally different from the distributed security model underpinning traditional blockchains.
This distinction matters because transaction ordering and transaction verification are not equally important functions.
Blockchain systems were originally designed to solve the problem of transaction ordering without requiring trusted intermediaries. Establishing a neutral and adversarial process for determining which transactions occur, and in what order, is the core problem blockchain consensus was created to solve.
Zero-knowledge proofs do not solve that problem. They solve a different problem.
They prove that a chosen sequence of transactions was executed correctly. The question of who chose that sequence remains separate.
As a result, many zero-knowledge architectures rely on private coordination for transaction intake, ordering, batching, and proof generation, while using cryptographic proofs to verify the correctness of the resulting execution.
This may improve performance and reduce verification costs. However, reducing verification costs is not the same as reproducing the decentralised security model of blockchain consensus.
One architecture distributes the burden of security across many independent participants.
The other derives correctness from increasingly specialised proving infrastructure.
These systems should not be assumed to produce the same trust characteristics simply because both ultimately settle to the same chain.
For financial infrastructure, practical economic incentives matter more than theoretical architectural possibilities. A system whose operation depends upon concentrated proving infrastructure should not automatically be assumed to inherit the decentralised characteristics of the blockchain on which it ultimately settles.
Promises of Future Decentralised Sequencers Do Not Fix the Trust Model
A common defence of today’s zero-knowledge rollup architectures is that centralised sequencing is only temporary.
Supporters may argue that centralised sequencing is merely an implementation detail rather than a structural feature. They argue that technically, zero-knowledge systems do not mathematically require a single sequencer.
According to this argument, today’s operator-controlled systems are simply an intermediate stage. Over time, decentralised sequencer networks will replace central operators, removing censorship concerns and restoring the trust-minimised properties associated with blockchain infrastructure.
This defence fails for two reasons.
First, it does not address the present operational reality. Financial infrastructure must be evaluated based on how it functions today, not on speculative future architecture. A system that currently depends on private coordination over economically sensitive transaction ordering does not become trust-minimised because decentralisation is promised later.
Second, even if decentralised sequencer networks are eventually achieved, they do not recreate the trust model of direct base-layer settlement.
A decentralised sequencer is, in effect, an attempt to reconstruct at the Layer 2 level the same core function already performed by the blockchain itself: adversarial agreement over transaction inclusion and ordering.
This raises an obvious question.
If the solution to Layer 2 centralisation is to recreate a second distributed coordination system to determine transaction order, what has actually been simplified?
The architecture has not eliminated the original problem. It has duplicated it.
The base chain’s consensus model is the security anchor. It is the mechanism through which transaction ordering is established under a broad economic security model, open participation assumptions, and globally enforced consensus rules.
A Layer 2 sequencer network attempting to replicate this function does not inherit that exact trust model.
It creates a second coordination layer with its own validator assumptions, incentive structures, participation model, censorship risks, and failure modes.
Even if meaningfully decentralised, this does not produce Ethereum security, but faster.
It produces a derivative trust model built alongside Ethereum and ultimately anchored back to it.
That distinction matters.
For financial infrastructure, trust assumptions around transaction ordering, access, and settlement are not interchangeable simply because they ultimately reference the same settlement chain.
A derivative coordination system with different operators, different incentives, and different failure characteristics is not equivalent to direct base-layer neutrality.
This is why promises of future decentralised sequencers should be treated cautiously.
In many cases, they function less as a present security property and more as a forward-looking narrative used to preserve the broader claim that the architecture remains fundamentally trust-minimised.
The central question is not whether decentralised sequencing is theoretically possible.
It is whether the resulting architecture would materially reproduce the guarantees that make direct blockchain settlement valuable in the first place.
For serious financial infrastructure, that answer is far less obvious than Layer 2 marketing often suggests.
Supporters often acknowledge these concerns and respond with a final defence.
Even if sequencers remain important, users are not ultimately dependent upon them because emergency escape mechanisms exist.
The most common example is forced inclusion.
Forced Inclusion Is Not Meaningful Financial Access
A common defence of centralised sequencing is that users are not ultimately dependent on the sequencer.
According to this argument, if a sequencer refuses to process transactions, censors users, or becomes unavailable, users can bypass the operator entirely by submitting transactions directly to Ethereum through forced inclusion mechanisms.
This is presented as evidence that Layer 2 systems remain permissionless in practice.
That framing is misleading. Forced inclusion is not normal market access. It is an emergency recovery mechanism created to compensate for architectural tradeoffs introduced by the Layer 2 model itself.
In a genuinely permissionless blockchain, open access is the default operating condition. Users broadcast transactions directly into a shared public consensus process. There is no privileged coordinator whose failure requires an override mechanism.
Forced inclusion only becomes necessary because Layer 2 systems depart from that model.
By introducing sequencer-controlled transaction intake in pursuit of higher throughput and improved user experience, they replace direct access with operator-mediated access. Forced inclusion is then introduced as a contingency mechanism to restore some portion of the access guarantees that were lost.
This is an important distinction. Forced inclusion is not evidence that the architecture preserved permissionlessness. It is evidence that permissionlessness had to be partially reintroduced through a compensating control.
This reflects a broader pattern in Layer 2 design.
A problem is introduced in order to bypass one limitation, then additional complexity is layered on to mitigate the consequences of that decision.
Ethereum’s base layer is slow precisely because adversarial transaction ordering and open access are handled through decentralised consensus. Layer 2 architectures bypass that bottleneck by introducing private coordination over transaction ordering.
Forced inclusion exists because once that coordination layer exists, censorship and access dependency become real risks.
The architecture therefore creates a new problem in order to work around the old one, then introduces an emergency mechanism to mitigate the consequences of the new problem.
This is not simplification. It is architectural complexity masquerading as resilience.
Even setting that aside, forced inclusion is not equivalent to continuous neutral market access. A fallback process is not the same as open participation.
More importantly, delayed access in financial markets is often economically indistinguishable from denied access.
Timing is not incidental in financial infrastructure. It is frequently the determining factor in economic outcomes.
A trade delayed during a rapid market move may execute at a materially worse price. A liquidation opportunity processed too late may disappear entirely. Access to arbitrage, collateral management, or risk mitigation during periods of market stress can lose all practical value if execution is delayed.
Financial infrastructure is not judged by whether access eventually becomes possible. It is judged by whether access remains reliable when timing matters most. Forced inclusion mechanisms are structurally poorly suited to this requirement.
Submitting transactions directly to the base layer is typically slower, materially more expensive, and operationally more complex than ordinary Layer 2 interaction.
Users may need to submit transactions directly to Ethereum, pay substantially higher fees, wait for Layer 1 confirmation, and then wait further for the Layer 2 environment to recognise or process the inclusion.
This is not equivalent to normal participation. It is degraded emergency access.
Forced inclusion may also introduce new operational challenges of its own.
The mechanism exists to preserve access when the normal sequencing process fails, but this does not necessarily make it economically neutral.
In many Layer 2 architectures, transaction execution costs and proof generation costs are not perfectly aligned. A transaction that is relatively inexpensive to execute may still impose disproportionate proving or operational costs on the system responsible for processing it.
This creates the possibility that emergency access mechanisms become targets for economic abuse.
More broadly, the existence of these concerns highlights a recurring pattern throughout Layer 2 architecture. Additional complexity is introduced to compensate for limitations created elsewhere in the design.
A sequencer is introduced to bypass the throughput limitations associated with direct participation in blockchain consensus. Forced inclusion is then introduced to mitigate the censorship and access risks created by sequencer dependence. Additional mechanisms may then be required to mitigate the consequences of those emergency procedures.
The result is a growing stack of compensating controls.
Each individual mechanism may be defensible in isolation, but the overall architecture becomes increasingly dependent on layered exceptions, fallback processes, and specialised operational assumptions.
This is fundamentally different from solving a problem at its source.
It is the creation of increasingly sophisticated procedures for managing the consequences of architectural tradeoffs.
The burden is also not equally distributed.
Sophisticated actors with automated infrastructure, engineering resources, and capital are far better positioned to detect sequencer failure, route transactions through fallback mechanisms, and absorb higher execution costs. Ordinary users are not.
This creates asymmetric access precisely when market infrastructure should be most neutral.
In stressed conditions, the participants best equipped to exploit emergency access are likely to be the same sophisticated actors already advantaged by speed, automation, and infrastructure scale.
That is not a trivial fairness concern.
For financial infrastructure, equal access during stressed market conditions is a core design requirement.
Most importantly, the existence of forced inclusion itself proves that sequencer dependency is real. If users need an override mechanism to escape censorship or operator failure, then censorship and operator dependency have not been eliminated. They have simply been given a contingency procedure.
A system that requires emergency recovery mechanisms to preserve access is not equivalent to continuously permissionless market infrastructure.
For serious financial applications, resilience under stress is not optional. It is the test that matters most.
Layer 2s Occupy the Least Attractive Middle Ground
For many financial applications, centralisation is not inherently disqualifying.
Traditional financial infrastructure already relies on centralised operators. Exchanges, custodians, brokers, payment processors, and clearing venues function through identifiable institutions operating within clearly defined legal and regulatory frameworks.
The reason these systems remain viable is not because users trust them less. It is because the trust relationship is explicit.
Responsibilities, liabilities, and obligations are understood in advance. When failures occur, users know who exercised control, which legal framework applies, which regulator has authority, and where accountability resides. Contractual obligations, regulatory oversight, legal recourse, and institutional reputation all provide mechanisms through which trust can be enforced.
This does not eliminate trust. It makes trust visible.
Performance is often a secondary benefit. Centralised operators can optimise infrastructure, coordinate activity efficiently, and avoid many of the costs associated with distributed consensus. These advantages help explain why centralised financial systems remain dominant.
However, the primary value proposition is clarity of responsibility.
Users understand who is operating the system and who is accountable when things go wrong.
Where trust minimisation and censorship resistance are genuinely required, the alternative is direct blockchain settlement.
Layer 1 blockchains make a different tradeoff.
Transaction ordering emerges through open consensus rather than private coordination. Access is permissionless by design. Trust assumptions are explicit, distributed, and economically enforced rather than delegated to a central operator.
The cost is lower performance, but the trust model is coherent.
Layer 2s attempt to position themselves between these two approaches.
They reintroduce centralised operational dependencies over transaction sequencing, access, proving infrastructure, and system coordination while continuing to market themselves using the language of decentralisation.
At the same time, they do not offer the direct neutrality, permissionless participation, or trust assumptions of settlement on the layer 1 itself.
The result is a hybrid structure that captures weaknesses from both models.
Compared with traditional centralised infrastructure, Layer 2 systems are operationally more complex, less transparent in their trust assumptions, and often dependent on technical fallback mechanisms rather than straightforward operator accountability. They frequently rely on privileged actors while lacking the clear jurisdictional boundaries, contractual relationships, and legal accountability that justify centralisation elsewhere in finance.
Compared with direct blockchain settlement, they introduce privileged coordination, weaker neutrality guarantees, and derivative trust assumptions around transaction ordering, access, and system operation.
If explicit centralisation is acceptable, simpler systems with clearer accountability already exist.
If meaningful decentralisation is required, direct blockchain settlement provides stronger guarantees.
Layer 2s therefore risk occupying the least defensible position between the two.
Too centralised to deliver the strongest benefits of decentralisation.
Too structurally compromised to compete with purpose-built centralised financial infrastructure on accountability, clarity, simplicity, and operational reliability.
Layer 2s are best understood not as the fulfillment of blockchain trustlessness, but as a compromise marketed as its continuation.