For years, a blockchain was one chain doing everything. The modular thesis breaks that apart into specialized layers for execution, settlement, consensus, and data availability. This guide explains the new stack, why rollups need a data layer, and what the design buys and costs.

A modular blockchain is a blockchain that splits the core jobs a network must perform across separate, specialized layers, instead of having a single chain do all of them at once. To see why that is a meaningful idea, you have to know the four jobs every blockchain has to handle: execution, which means running transactions and smart contracts; settlement, which means finalizing results and resolving disputes; consensus, which means agreeing on the order of transactions; and data availability, which means making sure the transaction data is actually published so anyone can check it. 

A traditional blockchain, now called monolithic, does all four itself, on one chain, which is simple and tightly integrated but runs into a hard ceiling on how much it can scale, because one chain doing everything can only go so fast before it becomes congested or expensive. The modular approach unbundles those jobs, letting different layers each specialize in one of them, and that unbundling has become the dominant way ambitious blockchains now scale. This guide explains the four functions, the difference between monolithic and modular designs, how rollups and data availability layers fit together, the leading examples, and the real trade-offs the modular path involves.

The reason this matters is that scaling has been blockchain’s defining challenge for a decade, captured in the so-called trilemma, the observation that a single chain struggles to be simultaneously scalable, secure, and decentralized, and usually has to sacrifice one. Monolithic chains tend to push hard on scale at some cost to decentralization, or preserve decentralization at the cost of speed. 

The modular thesis offers a different escape from the trilemma: if no single chain has to do everything, then each layer can optimize for its own job, and the system as a whole can reach a scale no monolithic chain easily matches while preserving strong security and decentralization where it counts. 

By 2026 this thesis moved from theory to the dominant architecture, with specialized data availability networks serving dozens of execution chains and a whole stack of modular components in production. Understanding the modular design is therefore close to understanding where blockchain infrastructure as a whole is heading.

The four jobs of a blockchain

Everything about modularity follows from understanding the four functions a blockchain performs, so it is worth taking each in turn. Execution is the actual computation: when you swap tokens or run a smart contract, execution is the process of taking your transaction, applying it, and updating the network’s state to reflect the new balances. It is the layer users interact with most directly, and it is computationally heavy, because every transaction has to be processed. Settlement is the layer that provides finality and a home for dispute resolution: it is where the results of execution are anchored and made authoritative, the bedrock that other layers can treat as the final word on what happened, and where, in some designs, proofs are verified or fraudulent claims are challenged.

Consensus is the mechanism by which the network’s participants agree on a single, ordered history of transactions, so that everyone shares the same view of what happened and in what sequence, which is what stops double spending and keeps the ledger consistent. Data availability is the one most people have never heard of and the one that turns out to be central to modular design. It is the guarantee that the data behind every transaction is actually published and obtainable, so that anyone can download it, check that the rules were followed, and reconstruct the state if needed. If transaction data is not available, no one can verify whether the network cheated, which means data availability is a quiet but essential foundation of trust. In a monolithic chain, all four of these jobs happen together in one tightly bound system. The modular insight is that they do not have to, and that pulling them apart lets each be done far better.

Monolithic versus modular

The cleanest way to grasp modularity is to contrast it directly with the monolithic model it departs from. A monolithic blockchain bundles all four functions into a single integrated chain. Every full node executes every transaction, participates in consensus, stores all the data, and treats the chain itself as the settlement layer. The great virtue of this design is simplicity and tight integration: everything lives in one place, applications can interact seamlessly, and there are no seams between layers to manage. 

A well known high performance chain that prizes raw speed exemplifies the monolithic approach, pushing a single integrated chain to process enormous throughput by demanding powerful hardware from its nodes. The cost of the monolithic design is the ceiling it imposes: because every node must do everything, the chain can only scale so far before either fees rise, congestion sets in, or the hardware requirements grow so heavy that fewer participants can run a node, which erodes decentralization.

A modular blockchain breaks the bundle apart so that different layers handle different jobs. A typical modern arrangement separates execution from the rest: specialized execution layers run the transactions and smart contracts, while a different layer or layers handle settlement, consensus, and data availability. The flagship example is the rollup-centric design, where lightweight execution chains called rollups process transactions off to the side and then lean on a robust base layer for settlement and data availability. 

The benefit is specialization: an execution layer can be tuned purely for fast, cheap transaction processing without also bearing the full weight of securing the entire system, because it borrows security from the base layer beneath it. The system as a whole can then scale by adding many execution layers on top of a shared foundation, multiplying capacity in a way a single monolithic chain cannot. Monolithic favors integration and simplicity; modular favors specialization and scale, and that is the core of the design choice.

Rollups: the execution layer of the modular world

The most important modular component to understand is the rollup, because rollups are how the modular vision actually gets used today. A rollup is a separate chain that handles execution, processing transactions quickly and cheaply off the main chain, and then posts a compressed record of what it did back down to a base layer for security. The name comes from the way it rolls up many transactions into a single batch and submits that batch to the base chain, so the base chain does not have to process each transaction individually but can still serve as the ultimate source of truth. This is the mechanism that lets a modular system scale: thousands of transactions happen cheaply on the rollup, and only a condensed summary touches the expensive, highly secure base layer.

There are two main families of rollup, distinguished by how they convince the base layer that their batched transactions are valid. Optimistic rollups assume the transactions are honest by default and allow a window during which anyone can challenge a fraudulent batch by submitting a fraud proof, with the base layer settling the dispute. Zero knowledge rollups instead generate a cryptographic validity proof for each batch, mathematically showing the transactions were processed correctly, which the base layer verifies without re running them. 

Both achieve the same goal of inheriting the base layer’s security while doing execution elsewhere, and both depend critically on one thing: the data behind their transactions must be available, so that anyone can verify the rollup’s claims or reconstruct its state. A rollup that posted only a summary without making the underlying data available would be asking the world to trust it blindly, which defeats the purpose. This is exactly why data availability, the obscure fourth function, becomes the linchpin of the entire modular architecture.

Data availability: the linchpin

Data availability deserves its own section because it is the function that modular design elevated from an afterthought to a centerpiece. When a rollup posts its batch of transactions, the crucial requirement is that the full transaction data be published somewhere accessible, so that anyone can check the rollup did its job honestly, challenge it if not, and rebuild the state if the rollup operator disappears.

Where that data gets published, and how cheaply, turns out to be one of the biggest factors in how well a modular system performs, because publishing data is a major part of what a rollup pays for. If the base layer makes data publication expensive, rollups are expensive; if a layer makes it cheap, rollups become dramatically cheaper.

This created demand for a new kind of specialized chain whose entire job is data availability: a data availability layer. Rather than executing transactions or settling disputes, such a chain exists purely to order data and keep it available cheaply and reliably for the rollups that depend on it. The pioneering example is a network built specifically as a modular data availability layer, which uses an elegant technique called data availability sampling to scale. Instead of requiring every node to download an entire block to confirm the data is there, lightweight nodes each randomly sample a small number of pieces of the block. 

With enough independent samples, the network can be confident, to very high probability, that all the data is genuinely available, without anyone having to download all of it. Combined with techniques that let each application fetch only its own slice of data, this lets a data availability layer serve many rollups at once, cheaply and at scale. By 2026, such a layer was providing data availability for dozens of rollups, a concrete sign that the modular separation of data availability into its own specialized network had become real, working infrastructure.

The leading modular stacks

It helps to see how these pieces assemble into real systems, because the modular world is not one design but a few competing and complementary stacks. The most influential is the rollup-centric roadmap of the leading smart contract platform, which deliberately reoriented itself around modularity. Rather than trying to scale by making its own base layer process everything faster, it chose to become primarily a settlement and data availability foundation, with the heavy execution pushed out to a thriving ecosystem of rollups built on top. 

A pivotal upgrade introduced a dedicated, cheaper space for rollups to post their data, often called blob space, which slashed the cost of data availability and, with it, the fees rollups charge users, bringing many transactions down to a fraction of a cent. Further upgrades aim to expand that data capacity dramatically over time. The result is a layered system: a secure base layer for settlement and data, and many execution focused rollups handling the day-to-day activity cheaply above it.

Alongside this sits the specialized data availability layer approach, where rollups choose to post their data to a purpose built data availability network instead of, or in addition to, the base settlement layer, often to get even lower costs. There is also a connection to another modular idea covered elsewhere: shared security through restaking, where a pool of staked capital can be used to secure new services, including data availability layers, letting them inherit strong economic security on day one rather than bootstrapping their own. 

Together, these pieces form a menu of modular components, settlement layers, data availability layers, execution rollups, and shared security providers that teams can mix and match to assemble a custom chain. A project can launch its own rollup tuned for gaming or social applications, point it at whichever data availability layer is cheapest, and settle to whichever base layer it trusts, without building a validator set or a full monolithic chain from scratch. That composability of infrastructure, the ability to assemble a chain from specialized parts, is the practical payoff of the modular thesis and a large part of why it spread so quickly.

An analogy: the restaurant and the food court

Because the modular stack has so many pieces, an analogy can anchor the whole idea before the trade offs pile up. Think of a monolithic blockchain as a single restaurant that does everything under one roof: it grows its own ingredients, cooks every dish, seats the diners, and washes the dishes, all with the same staff in the same building. The advantage is seamless coordination, since everything happens in one place and nothing has to be handed off. The limitation is capacity: that one kitchen can only cook so many meals at once, and if you want to serve far more people, you either build an enormous, expensive kitchen that few can staff, or you accept long waits and high prices when demand surges. A single integrated chain faces the same ceiling, because every node has to do every job.

Now picture a food court instead. The building provides the shared foundation, the tables, the security, the guarantee that the space stays open and orderly, while many specialized vendors handle the cooking, each focused on one cuisine and tuned to serve its customers quickly and cheaply. In this picture the shared building is the base layer providing settlement and data availability, and the individual vendors are the rollups handling execution. 

No single vendor has to provide its own security or build its own premises; they all inherit that from the building, so they can concentrate purely on serving food fast. The food court can serve vastly more people than the single restaurant, because capacity grows by adding vendors instead of straining one kitchen, which is exactly how a modular system scales by adding execution layers on a shared foundation.

The analogy also captures the costs honestly. A food court is more complex than a single restaurant: there are more independent operators, more things that can go wrong with any one vendor, and more coordination required to keep the shared space working. If you want a dish that combines ingredients from three different vendors, you have to carry your tray between them, which is clumsier than ordering everything from one kitchen, just as moving assets or composing an application across separate rollups is more awkward than operating within one integrated chain. And every vendor depends on the building: if the shared foundation fails to keep the lights on or the doors open, every vendor suffers, just as a rollup inherits the weaknesses of the data availability and settlement layers beneath it. 

The food court trades the seamless simplicity of the single restaurant for far greater capacity and specialization, accepting more complexity and more handoffs in return. That is precisely the bargain the modular blockchain makes, and seeing it as a food court instead of a single restaurant makes both the appeal and the cost intuitive.

What modularity buys you

Having laid out the architecture, it is worth being precise about the genuine advantages the modular approach delivers, because they explain why it became dominant. The headline benefit is scalability. By separating execution from the base layer and letting many rollups run in parallel on top of a shared foundation, a modular system can process vastly more total activity than a single monolithic chain, because capacity is added by stacking execution layers instead of straining one chain. The cheap data availability layers compound this by driving down the dominant cost of running a rollup, which is why transaction fees on modern rollups have fallen to fractions of a cent for simple transfers.

The second benefit is specialization and flexibility. Because each layer focuses on one job, each can be optimized far beyond what a generalist chain could achieve: a data availability layer can be ruthlessly efficient at keeping data available, an execution rollup can be tuned for a specific use case, and a settlement layer can prioritize security and finality. This also gives builders flexibility and sovereignty: a team can launch a chain tailored to its needs, choosing its own execution environment and rules, while still inheriting security and data availability from established layers instead of recreating them. 

The third benefit is improved decentralization at the verification level. Techniques like data availability sampling let lightweight nodes verify that a network is behaving honestly without running expensive hardware, which means more ordinary participants can help keep the system honest, countering the tendency of high performance monolithic chains to concentrate power among those who can afford powerful machines. Scalability, specialization, and verifiable decentralization are the real prizes the modular design competes for, and it pursues them by refusing to make any single chain carry the whole load.

The trade-offs and criticisms

No architecture is free, and an honest account of modularity has to weigh its real costs against the monolithic simplicity it replaces. The first cost is complexity. A modular system has many moving parts, execution on one layer, data on another, settlement on a third, bridges and proofs connecting them, and that complexity creates more surface area for bugs, misconfigurations, and failures than a single integrated chain. More layers mean more things that can go wrong and more seams that must be secured. The second cost is fragmentation. When activity spreads across many separate rollups, liquidity and users fragment too, and moving assets or composing applications across different execution layers can become awkward, slow, or risky, sacrificing some of the seamless composability that a single monolithic chain offers, where every application can interact with every other instantly.

The third cost is a subtler security consideration. A rollup’s safety depends on the layers beneath it, so if the data availability layer it relies on fails to keep data available, or the settlement layer it trusts is compromised, the rollup inherits that weakness. Modular systems must therefore reason carefully about the trust assumptions of every layer they depend on, and a chain that uses a less secure data availability layer to save money is making a real trade off in safety, even if it is not always obvious to users. 

Defenders of the monolithic approach argue that tight integration delivers a simpler, more composable, more uniformly secure system, and that the high performance monolithic chains have shown a single chain can scale further than the modular camp once assumed. The honest conclusion is that monolithic and modular are not strictly better or worse but represent different bets: monolithic wagers that integration and raw single chain performance win, while modular wagers that specialization and stacking win. By 2026 the modular bet had clearly become the dominant architecture for ambitious new infrastructure, but the trade offs it carries, complexity, fragmentation, and layered trust, are real, and the debate over which approach ultimately prevails is far from settled.

Frequently Asked Questions

This article is educational information, not investment advice. Blockchain architectures, projects, and technical details evolve quickly, and the descriptions here reflect the state of the field as of June 25, 2026. Verify current information from primary sources before relying on anything described here.