What is Modular Blockchain? Rollups, Data Availability, and New Stacks

For many years, blockchain has been the one chain that does it all. The modular theory divides it into specialized layers for execution, settlement, consensus, and data availability. This guide explains the new stack, why rollups need a data layer, and what your design requires and costs.

A modular blockchain is a blockchain that divides the core jobs that the network needs to perform into separate specialized layers, rather than doing them all at once on a single chain. To understand why it’s a meaningful idea, you need to know the four jobs every blockchain has to handle. Execution refers to the execution of transactions and smart contracts. Conciliation means establishing an outcome and resolving a dispute. consensus. It means agreeing on the order of transactions. Data availability. This means that the transaction data is actually public and available for anyone to see.

Traditional blockchains, now called monolithic, run all four on one chain. It’s simple and tightly integrated, but there’s a hard upper limit to how much it can scale because there’s only so much speed you can go before one chain running everything becomes congested and expensive. A modular approach does not bundle these jobs, but instead makes different layers specialized for one of each job. That bundling is now the primary way to scale ambitious blockchains. This guide explains the four features, the differences between monolithic and modular designs, how rollups and data availability layers fit together, key examples, and the practical tradeoffs involved with the modular path.

This is important because scaling has been a defining challenge for blockchain for a decade and is captured in the so-called trilemma. The trilemma is the observation that a single chain struggles to be scalable, secure, and decentralized at the same time, and one usually has to be sacrificed. Monolithic chains tend to either increase scale at the expense of decentralization or maintain decentralization at the expense of speed.

Modular theory provides another way out of the trilemma. When a single chain doesn’t need to do everything, each layer can be optimized for its own job, and the entire system can reach scales that monolithic chains can’t easily match, while maintaining the strong security and decentralization that’s important.

By 2026, the paper had moved from theory to mainstream architecture, with a specialized data availability network serving an entire stack of dozens of execution chains and modular components in production. Therefore, understanding modular design is almost the same as understanding where blockchain infrastructure as a whole is headed.

Four roles of blockchain

Everything about modularity comes from understanding the four functions that a blockchain performs, so it’s worth understanding each in turn. Execution is the actual calculation. When exchanging tokens or executing smart contracts, execution is the process of taking the transaction, applying it, and updating the network state to reflect the new balance. This is the layer that users interact with most directly and is computationally intensive as it has to process all transactions. Reconciliation is a layer that provides finality and a home for dispute resolution. It is where the outcome of a settlement is fixed and given authority, it is the foundation that other layers can treat as the final information about what happened, and in some designs, it is where evidence is verified or fraudulent claims are challenged.

Consensus is a mechanism by which network participants agree on a single, ordered transaction history, where everyone shares the same view of what happened and in what order, preventing double spending and maintaining ledger consistency. Data availability is something most people have never heard of, but it turns out to be central to modular design. This ensures that the data behind every transaction is actually public and retrievable, so anyone can download the data, verify that the rules are followed, and rebuild the state if necessary. If transaction data is not available, no one can verify whether the network was fraudulent. This means that data availability is a silent but essential foundation of trust. In a monolithic chain, all four of these jobs run simultaneously in one tightly coupled system. The modular insight is that you don’t need to separate them, and that you can run each much more efficiently by separating them.

Monolithic and modular

The clearest way to understand modularity is to directly contrast it with the monolithic model from which it started. A monolithic blockchain bundles all four functions into a single integrated chain. Every full node executes all transactions, participates in consensus, stores all data, and treats the chain itself as a settlement layer. The big advantage of this design is its simplicity and tight integration. Everything is in one place, applications can interact seamlessly, and there are no seams between the layers you manage.

The well-known high-performance chains that emphasize raw speed are an example of a monolithic approach, requiring powerful hardware in the nodes, allowing a single unified chain to handle massive throughput. The cost of a monolithic design is the upper limit it imposes. Because every node has to do everything, the chain can only scale until fees rise, congestion sets in, or the hardware requirements become so heavy that fewer participants can run a node and decentralization suffers.

Modular blockchains split bundles so that different layers handle different jobs. A typical modern configuration decouples execution from the rest. A specialized execution layer executes transactions and smart contracts, while another layer handles settlement, consensus, and data availability. A typical example is a rollup-centric design, where a lightweight execution chain called a rollup processes transactions aside and relies on a robust base layer for settlement and data availability.

The advantage is specialization. Because the execution layer borrows security from the base layer below it, it can be tuned solely for fast and cheap transaction processing without taking on full responsibility for ensuring the security of the entire system. By adding many execution layers on top of a shared foundation, the entire system can be scaled, doubling capacity in a way that is not possible with a single monolithic chain. Monolithic prioritizes integration and simplicity. Modular emphasizes specialization and scale, and that is the core of the design choice.

Rollup: The execution layer of a modular world

The most important modular component to understand is rollups. Because rollups are how modular vision is actually used today. Rollups are another chain that handles execution, processing transactions from the main chain quickly and cheaply, and posting a compressed record of what was executed back to the base layer for security. The name comes from the way it rolls up many transactions into one batch and sends that batch to the base chain. Therefore, the base chain does not have to process each transaction individually and acts as the final source of truth. This is a mechanism that allows expansion of modular systems. Rollups cheaply generate thousands of transactions and only apply condensed summaries to the expensive, highly secure base layer.

There are two main families of rollups, differentiated by how they convince the base layer that batched transactions are valid. Optimistic rollup assumes transactions are honest by default, and the base layer resolves disputes, allowing a period during which anyone can contest fraudulent batches by providing evidence of fraud. Zero-knowledge rollup instead generates a proof of cryptographic validity for each batch, mathematically indicating that the transaction was processed correctly, and the base layer validates the transaction without re-executing it.

Both achieve the same goal of inheriting base layer security while running elsewhere. Also, both are crucially dependent on one thing. That means the data behind the transaction must be available so that anyone can validate the rollup’s claims or reconstruct its state. A rollup that only provides a summary without disclosing the underlying data defeats the purpose of asking the world to blindly trust it. This is precisely why data availability, the nebulous fourth feature, is central to the entire modular architecture.

Data availability: Required

Data availability deserves its own section because the modular design elevates it from an afterthought to a core feature. When a rollup posts a batch of transactions, a key requirement is that the complete transaction data be published somewhere accessible so that anyone can check whether the rollup worked correctly, challenge it if it didn’t, and rebuild the state if the rollup operator disappears.

Data publishing is a major part of the cost of rollups, so where and how cheaply data is published proves to be one of the biggest drivers of a modular system’s performance. If the base layer incurs a cost to expose data, rollups also incur a cost. If layers cost less, rollups become dramatically cheaper.

This has created a demand for a new kind of specialized chain, the data availability layer, whose entire role is data availability. Such chains exist not to perform transactions or resolve disputes, but purely to order data and make it available cheaply and reliably to rollups that depend on it. A pioneering example is a network built specifically as a modular data availability layer. It uses a sophisticated technique called data availability sampling to scale. Instead of requiring all nodes to download the entire block to ensure that the data is present, each lightweight node randomly samples a small portion of the block.

With enough independent samples, the network can be confident with a very high probability that all the data is truly available, without anyone having to download everything. Combined with techniques that allow each application to get only its own slice of data, this allows the data availability layer to serve many rollups at once, cheaply and at scale. By 2026, such layers will provide data availability for dozens of rollups. This is a concrete sign that separating data availability on a modular basis into its own specialized network has become a working infrastructure.

Main modular stack

Because the modular world is not one design, but several competing and complementary stacks, it helps to see how these parts are assembled into a real system. The most impactful is the rollup-centric roadmap of the major smart contract platforms, with a deliberate pivot around modularity. Rather than trying to scale by processing everything faster in our own base layer, we chose to primarily be the foundation for payments and data availability, and pushed out a ton of execution to a thriving ecosystem of rollups built on top of it.

A pivotal upgrade introduced a dedicated, inexpensive space (often referred to as a blob space) for rollups to post data. This reduced data availability costs and associated rollup fees charged to users, reducing many transactions to a fraction of a cent. Further upgrades are intended to dramatically expand its data capacity over time. The result is a layered system. A secure base layer for payments and data, and a number of rollups focused on execution that cheaply handles day-to-day activities on top.

In addition to this, there are specialized data availability layer approaches, where rollups often choose to post data to a purpose-built data availability network instead of, or in addition to, the base payment layer to further reduce costs. There is also a connection to another modular idea described elsewhere. Shared security through re-staking. It uses a pool of staked capital to secure new services, including a data availability layer, allowing you to inherit strong financial security from day one rather than bootstrapping your own.

Together, these elements form a menu of modular components, payment layers, data availability layers, execution rollups, and shared security providers that teams can combine to assemble custom chains. Projects can launch their own rollups tailored for gaming and social applications, specify the cheapest data availability layer, and settle on a trusted base layer without having to build validator sets or a complete monolithic chain from scratch. Infrastructure composability, the ability to assemble chains from specialized parts, is a practical benefit of modular theory and is a large part of why it has become so popular.

Example: restaurant and food court

Since there are so many parts to a modular stack, an analogy can help ground the whole idea before the trade-offs add up. Think of a monolithic blockchain as a single restaurant that does everything under one roof. We grow our own ingredients, prepare all the food, serve the meals, and wash the dishes, all in the same building and with the same staff. Seamless coordination is an advantage because everything is done in one place and nothing has to be carried over. The limit is processing power. A kitchen can only cook a limited number of dishes at once, and if you want to serve more people, you either build a huge, expensive kitchen with few people to staff it, or you accept long wait times and high prices when demand spikes. A single integration chain faces the same ceiling because every node has to run every job.

Imagine a food court instead. The building offers shared infrastructure, tables, security, and the guarantee that the space remains open and orderly, with a number of specialized vendors handling the cooking, each focused on one dish and tailored to serve customers quickly and inexpensively. In this diagram, the shared building is the base layer that provides payments and data availability, and the individual vendors are the rollups that handle execution.

No single vendor needs to provide its own security or build its own facilities. We all inherited from that building, so we can purely focus on getting the food out fast. Food courts can serve far more people than a single restaurant because capacity increases by adding vendors rather than taxing one kitchen. This is exactly how modular systems scale by adding layers of execution on top of a shared foundation.

In this analogy, costs are also honestly captured. A food court is more complex than a single restaurant. There are more independent operators, one vendor can be problematic, and shared spaces require more coordination to keep functioning. If you want a dish that combines ingredients from three different vendors, you will have to carry trays between vendors. This is more hassle than ordering everything in one kitchen. Similarly, moving assets and configuring applications between separate rollups is more cumbersome than operating within one unified chain. And all the vendors depend on the building. If the shared infrastructure fails to keep the lights on and the doors open, all vendors will suffer, just as rollups inherit weaknesses in the data availability and payments layers below.

Food courts trade the seamless simplicity of a single restaurant for much greater capacity and specialization, and in return they accept more complexity and more handoffs. That’s exactly the bargain that modular blockchain creates, and by looking at it as a food court rather than a single restaurant, you can intuit both the appeal and the cost.

What you get with modularity

Having explained the architecture, it’s worth understanding exactly what the real benefits of a modular approach are. It explains why modular approaches have become mainstream. The biggest advantage is scalability. By decoupling execution from the base layer and allowing many rollups to run in parallel on a shared foundation, modular systems can handle much more total activity than a single monolithic chain. This is because capacity is added by stacking execution tiers rather than loading one chain. This is compounded by an inexpensive data availability layer that reduces the core cost of performing rollups. This is why modern rollup transaction fees are down to just a few cents for a simple transfer.

The second advantage is professionalism and flexibility. Because each layer focuses on one job, it can be optimized far beyond what a generalist chain can achieve. The data availability layer is radically efficient at keeping data available, the execution rollup can be tailored to specific use cases, and the payment layer can prioritize security and finality. This also gives flexibility and sovereignty to the builder. Rather than recreating established layers, teams can choose their own execution environment and rules to launch chains tailored to their needs, while inheriting security and data availability.

The third benefit is improved decentralization at the verification level. Techniques such as data availability sampling allow lightweight nodes to verify that the network is operating honestly without running expensive hardware. This means more common participants can help keep the system honest, countering the tendency for high-performance monolithic chains to concentrate power in the hands of those who can afford powerful machines. Scalability, specialization, and verifiable decentralization are the real prizes that modular designs compete for, and they pursue them by refusing to have the entire load on a single chain.

Trade-offs and criticism

No architecture is free, and any honest discussion of modularity requires weighing its actual cost against the monolithic simplicity it replaces. The first cost is complexity. Modular systems have many moving parts, execution in one layer, data in another, payment in a third, bridges and proofs that connect them, and that complexity creates a larger surface area for bugs, misconfigurations, and failures than a single integrated chain. More layers means more potential for problems and more seams to secure. The second cost is fragmentation. When activities are spread across many separate rollups, fluidity and users are also fragmented, making moving assets and configuring applications between different execution layers cumbersome, slow, or potentially risky, sacrificing some of the seamless configuration capabilities that a single monolithic chain provides, allowing any application to interact with any other application instantly.

The third cost is a more subtle security consideration. A rollup’s safety depends on the layers below it, so if the data availability layer it relies on fails to maintain data availability, or the payment layer it relies on is compromised, the rollup inherits its weaknesses. Therefore, modular systems must reason carefully about the reliability assumptions of all the layers they rely on, and chains that use less secure data availability layers to save cost are creating substantial trade-offs with security, even if they are not always obvious to users.

Advocates of the monolithic approach argue that tight integration provides a simpler, more configurable, and more uniformly secure system, and that high-performance monolithic chains have shown that a single chain can scale further than the modular camp once envisioned. The honest conclusion is that monolithic and modular are not strictly better or worse, but represent different bets. Monolithic is a bet that integration and raw single-chain performance will win, modular is a bet that specialization and stacking will win. By 2026, it’s clear that modular betting has become the dominant architecture for ambitious new infrastructures, but the trade-offs of complexity, fragmentation, and layered trust are real, and the debate over which approach will ultimately prevail is far from settled.

FAQ

This article is educational information and does not constitute investment advice. Blockchain architectures, projects, and technical details are rapidly evolving, and the discussion here reflects the state of the art as of June 25, 2026. Please check the latest information from primary sources before relying on anything discussed here.