Multicoin Partner: Why Modular Blockchains Are Overhyped
TechFlow Selected TechFlow Selected
Multicoin Partner: Why Modular Blockchains Are Overhyped
Modularity is great, but the key to building winning technology is figuring out which parts of the stack need to be integrated and which parts should be left to others.
Navigating Web3 tides with focused insightsAuthor: Kyle Samani, Partner at Multicoin Capital
Translated by: Luffy, Foresight News
Over the past two years, the blockchain scalability debate has centered on one core topic: modularity versus integration.
Note that discussions in crypto often conflate "single" and "integrated" systems. The technical debate between integrated and modular systems spans a 40-year history. This conversation in crypto should be framed through the same historical lens—it’s far from a new debate.
When considering modularity versus integration, the most important design decision blockchains can make is how much complexity to expose to application developers across the stack. Since blockchain customers are application developers, the ultimate design choices must consider their perspective.
Today, modularity is widely celebrated as the primary path to blockchain scalability. In this article, I will question that assumption from first principles, reveal the cultural myths and hidden costs of modular systems, and share conclusions I’ve drawn after six years of thinking about this debate.
Modular Systems Increase Development Complexity
So far, the biggest hidden cost of modular systems is increased development complexity.
Modular systems significantly increase the complexity application developers must manage—both within their own application context (technical complexity) and when interacting with other applications (social complexity).
In the context of crypto, modular blockchains theoretically allow for greater specialization, but at the cost of creating new complexities. These complexities—both technical and social—are being passed down to application developers, ultimately making it harder to build applications.
For example, consider OP Stack. To date, it appears to be the most popular modular framework. OP Stack forces developers to either adopt the Law of Chains (which introduces significant social complexity) or to fork and manage independently. Both options impose substantial downstream complexity on builders. If you choose to fork, will you gain technical support from other ecosystem participants (CEXs, fiat on-ramps, etc.) who must bear the cost of adapting to new technical standards? If you choose to follow the Law of Chains, what rules and constraints will apply to you today—and tomorrow?
Source: OSI Model
Modern operating systems (OS) are large, complex systems composed of hundreds of subsystems. A modern OS manages layers 2–6 in the diagram above. This is a canonical example of integrating modular components to manage the complexity exposed to application developers. Application developers don’t want to deal with anything below layer 7—that’s precisely why operating systems exist: they abstract away lower-layer complexity so developers can focus on layer 7. Therefore, modularity itself should not be the goal, but rather a means to an end.
Every major software system in the world today—cloud backends, operating systems, database engines, game engines, etc.—is highly integrated while also composed of many modular subsystems. Software systems tend to be highly integrated to maximize performance and minimize development complexity. Blockchains are no different.
Incidentally, Ethereum is reducing the complexity seen during the Bitcoin fork era of 2011–2014. Modular proponents often cite the Open Systems Interconnection (OSI) model, arguing that data availability (DA) and execution should be separated; however, this argument is widely misunderstood. A correct understanding of the current problem leads to the opposite conclusion: the OSI model is actually an argument for integrated systems, not modular ones.
Modular Chains Do Not Execute Code Faster
By definition, a common characterization of a “modular chain” is the separation of data availability (DA) and execution: one set of nodes handles DA, while another (or multiple) sets handle execution. These node sets need not overlap, though they can.
In practice, separating DA and execution does not inherently improve the performance of either; rather, some hardware somewhere must perform DA, and some hardware elsewhere must carry out execution. Separating these functions does not accelerate either task. While such separation may reduce computational costs, it does so only by centralizing execution.
It bears repeating: whether modular or integrated, some hardware somewhere must do the work, and splitting DA and execution across separate hardware does not fundamentally speed up or increase total system capacity.
Some argue that modularity allows multiple EVMs to run in parallel via rollups, enabling horizontal scaling of execution. While this is theoretically correct, this view actually highlights the limitation of the EVM as a single-threaded processor—not the fundamental premise of separating DA and execution in the context of scaling total system throughput.
Modularity alone does not improve throughput.
Modularity Increases Transaction Costs for Users
By definition, every L1 and L2 is a separate asset ledger with its own state. These isolated state fragments can communicate, albeit with longer transaction latency and greater complexity for both developers and users (via cross-chain bridges like LayerZero and Wormhole).
The more asset ledgers there are, the more fragmented the global state becomes across all accounts. This fragmentation is detrimental both for chains and for users spanning multiple chains. Consequences include:
-
Reduced liquidity, leading to higher slippage;
-
Higher total gas consumption (cross-chain transactions require at least two transactions across at least two asset ledgers);
-
Increased redundant computation across asset ledgers (thus reducing total system throughput): When the ETH-USDC price moves on Binance or Coinbase, arbitrage opportunities arise across every ETH-USDC pool on every asset ledger (you can easily imagine a world where over ten transactions occur across various ledgers each time the ETH-USDC price changes. Maintaining price consistency under fragmentation is an extremely inefficient use of blockspace).
Critically, creating more asset ledgers clearly increases costs across all these dimensions—especially those related to DeFi.
DeFi’s primary input is on-chain state (i.e., who owns which assets). When teams launch app-chains/rollups, they naturally create state fragmentation, which is highly detrimental to DeFi—both for developers managing application complexity (bridges, wallets, latency, cross-chain MEV, etc.) and for users (slippage, settlement delays).
The ideal condition for DeFi is for assets to be issued and traded within a single asset ledger and a single state machine. The more asset ledgers there are, the greater the complexity developers must manage and the higher the costs users must bear.
App Rollups Do Not Create New Revenue Opportunities for Developers
Proponents of app-chains/rollups argue that incentives will drive developers to build rollups instead of building on L1s or L2s so apps can capture MEV value themselves. However, this idea is flawed because running an app rollup is not the only way—and often not the best way—to capture MEV back into the application layer token. App-layer tokens can simply encode logic within smart contracts on general-purpose chains to recapture MEV into their own tokens. Consider several examples:
-
Liquidations: If the Compound or Aave DAO wants to capture a portion of the MEV flowing to liquidation bots, they can simply update their respective contracts so that part of the fees currently going to liquidators are redirected to their DAO—no new chain/rollup needed.
-
Oracles: Oracle tokens can capture MEV by offering back-running services. Beyond price updates, oracles could bundle arbitrary on-chain transactions guaranteed to execute immediately after a price update. Thus, oracles can capture MEV by providing back-running services to searchers, block builders, etc.
-
NFT Mints: NFT mints are rife with resale bots. This can be easily mitigated by coding in declining profit redistribution. For instance, if someone resells their NFT within two weeks of minting, 100% of the revenue goes back to the issuer or DAO. Over time, this percentage could gradually decrease.
There is no one-size-fits-all answer for capturing MEV into app-layer tokens. However, with minimal effort, developers can easily recapture MEV into their own tokens on general-purpose chains. Launching an entirely new chain is unnecessary, adds extra technical and social complexity for developers, and creates more wallet and liquidity issues for users.
App Rollups Cannot Solve Cross-Application Congestion
Many believe that app-chains/rollups ensure applications won’t suffer from gas spikes caused by other on-chain activity (e.g., popular NFT mints). This view is partly correct but mostly wrong.
This is a historical issue rooted primarily in the single-threaded nature of the EVM—not because DA and execution aren’t separated. All L2s pay fees to L1s, and L1 fees can spike at any time. During the memecoin craze earlier this year, transaction fees on Arbitrum and Optimism briefly exceeded $10. More recently, fees on Optimism surged following the launch of Worldcoin.
The only real solutions to fee spikes are: 1) Maximize L1 DA, and 2) Fine-grain fee markets as much as possible:
If L1 resources are constrained, usage peaks across individual L2s propagate to the L1, increasing costs for all other L2s. Therefore, app-chains/rollups cannot escape gas spikes.
The coexistence of multiple EVM L2s is merely a crude attempt to localize fee markets. It’s better than having a single fee market on one EVM L1, but it doesn’t solve the core issue. Once you recognize the solution is localized fee markets, the logical endpoint is per-state fee markets (not per-L2 fee markets).
Other chains have already reached this conclusion. Solana and Aptos naturally localize fee markets. This required years of engineering tailored to their respective execution environments. Most modular proponents severely underestimate the importance and difficulty of building localized fee markets.
Localized Fee Markets
By launching multiple chains, developers do not unlock real performance gains. When applications drive transaction volume, the costs across all L2 chains are affected.
Flexibility Is Overrated
Proponents of modular chains claim modular architectures offer greater flexibility. That statement is obviously true—but does it matter?
For six years, I’ve struggled to find application developers who meaningfully benefit from flexibility that general-purpose L1s cannot provide. To date, aside from three very specific use cases, no one has clearly explained why flexibility matters or how it directly helps scalability. The three specific cases where I’ve found flexibility to be important are:
Applications leveraging "hot" state. Hot state refers to state required for real-time coordination of certain operations, temporarily committed on-chain but not permanently stored. Examples of hot state:
-
Limit orders in DEXs, such as dYdX and Sei (many of which are eventually canceled).
-
dFlow for real-time coordination and identification of order flow (dFlow is a protocol facilitating decentralized order flow markets between market makers and wallets).
-
Oracles like Pyth, a low-latency oracle. Pyth runs as a standalone SVM chain. It generates so much data that the core Pyth team decided high-frequency price updates should go to a dedicated chain, then bridged to other chains via Wormhole as needed.
Chains modifying consensus. Prime examples are Osmosis (where all transactions are encrypted before reaching validators) and Thorchain (which prioritizes transactions within blocks based on fees paid).
Infrastructure requiring threshold signature schemes (TSS). Examples include Sommelier, Thorchain, Osmosis, Wormhole, and Web3Auth.
With the exception of Pyth and Wormhole, all the examples listed above are built using the Cosmos SDK and operate as independent chains. This strongly demonstrates the suitability and scalability of the Cosmos SDK across all three use cases: hot state, consensus modification, and TSS-based systems.
However, most projects in the above three use cases are not applications—they are infrastructure.
Pyth and dFlow are not applications—they are infrastructure. Sommelier, Wormhole, Sei, and Web3Auth are not applications—they are infrastructure. Among them, only one type of user-facing application exists: DEXs (dYdX, Osmosis, Thorchain).
For six years, I’ve asked Cosmos and Polkadot supporters about use cases enabled by their flexibility. I believe we now have enough data to draw some inferences:
First, infrastructure examples should not exist as rollups because they either generate too much low-value data (e.g., hot state, whose entire purpose is to avoid committing data back to L1), or because they perform functions intentionally tied to state updates on asset ledgers (e.g., all TSS use cases).
Second, the only type of application I’ve seen that benefits from changing core system designs is DEXs. Because DEXs are filled with MEV, and general-purpose chains cannot match CEX latency. Consensus underpins transaction execution quality and MEV, so changes to consensus naturally create innovation opportunities for DEXs. However, as mentioned earlier in this article, the primary input for spot DEXs is the assets being traded. DEXs compete for assets—and thus for asset issuers. Within this framework, standalone DEX chains are unlikely to succeed because asset issuers prioritize general smart contract functionality and developer ecosystem integration over DEX-specific MEV when issuing assets.
However, derivative DEXs do not compete for asset issuers. They primarily rely on collateral like USDC and oracle price feeds, and inherently must lock user assets to secure derivative positions. Therefore, if standalone DEX chains make sense at all, they are most applicable to derivatives-focused DEXs like dYdX and Sei.
Consider today’s existing general integrated L1 applications: games, DeSoc systems (e.g., Farcaster and Lens), DePIN protocols (e.g., Helium, Hivemapper, Render Network, DIMO, and Daylight), Sound, NFT marketplaces, and so on. None particularly benefit from the flexibility offered by modifying consensus. Their respective asset ledgers share a fairly simple, obvious, and common set of requirements: low fees, low latency, access to spot DEXs, stablecoins, and fiat channels such as CEXs.
I believe we now have enough data to conclude that the vast majority of user-facing applications share the same general requirements outlined above. While certain applications might optimize marginal variables via custom stack features, the trade-offs usually aren’t worth it (more bridges, less wallet support, fewer indexing/query tools, reduced fiat access, etc.).
Launching a new asset ledger is one way to achieve flexibility, but it rarely adds value and almost always introduces technical and social complexity with negligible net benefit to application developers.
Scaling DA Does Not Require Restaking
You’ll also hear modular proponents discuss restaking in the context of scalability. This is the most speculative argument made by modular chain advocates, but it’s worth addressing.
Roughly, it suggests that thanks to restaking (e.g., via systems like EigenLayer), ETH can be restaked infinitely across the crypto ecosystem, powering an infinite number of DA layers (e.g., EigenDA) and execution layers. Thus, scalability is solved from all angles while ensuring ETH’s value accrual.
While there is enormous uncertainty between current reality and theoretical future outcomes, we should assume all layered assumptions work exactly as advertised.
Currently, Ethereum’s DA is about 83 KB/s. With the rollout of EIP-4844 later this year, this will roughly double to ~166 KB/s. EigenDA could add an additional 10 MB/s, but under different security assumptions (not all ETH will be restaked to EigenDA).
By comparison, Solana currently offers ~125 MB/s of DA (32,000 shreds per block, 1,280 bytes per shred, 2.5 blocks per second). Solana is vastly more efficient than Ethereum and EigenDA. Moreover, according to Nielsen's Law, Solana’s DA continues to scale over time.
There are many ways to scale DA via restaking and modularity, but these mechanisms are unnecessary today and introduce clear technical and social complexity.
Build for Application Developers
After years of reflection, I’ve concluded that modularity itself should not be a goal.
Blockchains must serve their customers—application developers—and therefore should abstract away infrastructure-level complexity so developers can focus on building world-class applications.
Modularity is great. But the key to building winning technology is figuring out which parts of the stack need to be integrated and which can be left to others. For now, chains that integrate DA and execution inherently provide a simpler experience for end users and developers, and ultimately offer a better foundation for top-tier applications.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Multicoin Capital
