
The Overlooked Areas of Modularity: Execution, Settlement, and Aggregation Layers
TechFlow Selected TechFlow Selected

The Overlooked Areas of Modularity: Execution, Settlement, and Aggregation Layers
Modular stacks are not only about DA and sequencing layers being noteworthy.
Author: Bridget Harris
Translation: Luffy, Foresight News
In terms of attention and innovation, not all components of the modular stack are created equal. While many projects have previously innovated in data availability (DA) and sequencing layers, only recently have execution and settlement layers started gaining recognition as integral parts of the modular stack.
The shared sequencer space is highly competitive, with numerous projects such as Espresso, Astria, Radius, Rome, and Madara vying for market share. Additionally, there are Rollup-as-a-Service (RaaS) providers like Caldera and Conduit that build shared sequencers for Rollups constructed on their platforms. These RaaS providers can offer more favorable fees because their underlying business models do not solely depend on sequencing revenue. Many Rollups also choose to run their own sequencers to capture the associated fees.
The sequencer market is unique compared to the DA landscape, which is essentially an oligopoly dominated by Celestia, Avail, and EigenDA. This makes it difficult for smaller new entrants outside these three giants to successfully disrupt the space. Projects either leverage "existing" options (like Ethereum), or select one of the mature DA layers based on their technical stack type and consensus needs. Although using a DA layer saves significant costs, outsourcing the sequencer is not an obvious choice—primarily due to the opportunity cost of forgoing sequencer revenue (from a fee perspective, not security). Many also believe DA will become commoditized, but in crypto we’ve seen that strong liquidity moats combined with unique (hard-to-replicate) underlying technology make it extremely difficult to commoditize any layer within the stack. Regardless of these debates, many new DA and sequencer products continue to emerge. In short, for some modular stacks, “each service has several competitors.”
I believe that execution and settlement (as well as aggregation) layers remain relatively underexplored, but they are beginning to iterate in novel ways to better align with the rest of the modular stack.
Relationship Between Execution and Settlement Layers
Execution and settlement layers are tightly integrated, with the settlement layer serving as the place where final state execution outcomes are defined. The settlement layer can also enhance the results from the execution layer, making the execution layer more powerful and secure. In practice, this could mean various functions—for example, the settlement layer may act as an environment where fraud disputes from the execution layer are resolved, proofs are verified, and connections to other execution layers are established.
It's worth noting that some teams directly support custom execution environments within their own protocols. Repyh Labs, for instance, is building an L1 called Delta. This design is essentially the opposite of a modular stack, yet it offers flexibility within a unified environment and provides technical compatibility advantages, as teams don’t need to spend time manually integrating each part of a modular stack. Of course, the downside is isolation from broader liquidity, inability to pick best-in-class modular layers for your design, and higher overall costs.
Other teams opt to build L1s focused on a core function or application. Hyperliquid is one such example, having built a dedicated L1 for its flagship native application—a perpetual contracts trading platform. While users must bridge from Arbitrum, their core architecture does not rely on Cosmos SDK or other frameworks, enabling customized iteration and optimization tailored to their primary use case.
Advancements in the Execution Layer
In the previous cycle, the only advantage generic alt-L1s had over Ethereum was higher throughput. This meant that if a project wanted significantly better performance, it essentially had to build its own L1 from scratch—mainly because Ethereum itself lacked the necessary technology. Historically, this simply meant embedding efficiency mechanisms directly into general-purpose protocols. In this cycle, however, these performance improvements are being achieved through modular designs, and crucially, on top of Ethereum—the dominant smart contract platform. As a result, both existing and new projects can now leverage next-generation execution infrastructure without sacrificing Ethereum’s liquidity, security, or community moat.
Currently, we’re also seeing increasing mix-and-match of different VMs (execution environments) as part of shared networks, offering developers greater flexibility and customization at the execution layer. For example, Layer N allows developers to run general-purpose Rollup nodes (e.g., SolanaVM, MoveVM, etc. as execution environments) and application-specific Rollup nodes (e.g., perpetual DEX, orderbook DEX) atop its shared state machine. They are also working toward full composability and shared liquidity across these different VM architectures—an on-chain engineering challenge historically difficult to achieve at scale. Each application on Layer N can asynchronously pass messages across consensus with zero latency, typically a major source of “communication overhead” in crypto. Each xVM can also utilize different database architectures—be it RocksDB, LevelDB, or custom synchronous/asynchronous databases built from scratch. Interoperability works via a “snapshot system”—an algorithm similar to Chandy-Lamport—allowing chains to transition to new blocks asynchronously without system pauses. On the security front, fraud proofs can be submitted if state transitions are incorrect. With this design, their goal is to minimize execution time while maximizing overall network throughput.

Layer N
To push further into customization, Movement Labs leverages the Move language—originally designed by Facebook and used in networks like Aptos and Sui—for its VM/execution layer. Move offers structural advantages over other frameworks, particularly in security and developer flexibility—two historically critical issues when building on-chain applications using existing technologies. Importantly, developers can still write in Solidity and deploy on Movement. To enable this, Movement created a fully bytecode-compatible EVM runtime that can coexist with the Move stack. Their Rollup, M2, leverages BlockSTM parallelization, enabling higher throughput while still accessing Ethereum’s liquidity moat (historically, BlockSTM was limited to alt-L1s like Aptos, which notably lack EVM compatibility).
MegaETH is also advancing the execution layer, particularly through its parallelization engine and in-memory database, allowing the sequencer to store the entire state in memory. Architecturally, they leverage:
-
Native code compilation, which delivers superior L2 performance (programs gain significant speedups if computation-heavy, and still see over 2x acceleration even if not).
-
Relatively centralized block production, but decentralized block validation and confirmation.
-
Efficient state synchronization, where full nodes do not need to re-execute transactions but instead apply state deltas to their local databases.
-
An optimized Merkle tree update structure (traditional tree updates consume large storage); their approach uses a new trie data structure efficient in both memory and disk usage. In-memory computation allows them to compress chain state into memory, so transaction execution accesses memory rather than disk.
Another recently explored and iterated design within the modular stack is proof aggregation: defined as a prover that creates a single succinct proof from multiple succinct proofs. First, let’s examine the value of the aggregation layer and its history and current trends in crypto.
The Value of the Aggregation Layer
Historically, in non-crypto markets, aggregators capture less market share than platforms:

While I’m not certain this applies universally in crypto, it holds true for decentralized exchanges, cross-chain bridges, and lending protocols.
For example, 1inch and 0x—two major DEX aggregators—have a combined market cap of around $1 billion, only a fraction of Uniswap’s ~$7.6 billion. The same goes for cross-chain bridges: Li.Fi and Socket/Bungee, as bridge aggregators, hold smaller market shares compared to platforms like Across. Although Socket supports 15 different bridges, its total bridging volume is actually similar to Across (Socket — $2.2B, Across — $1.7B), while Across represents only a small portion of Socket/Bungee’s recent volume.
In lending, Yearn Finance was the first decentralized yield aggregation protocol, with a current market cap of about $250 million. In contrast, platforms like Aave (~$1.4B) and Compound (~$560M) command higher valuations.
Traditional financial markets show a similar pattern. ICE US and CME Group each have market caps of around $75 billion, while “aggregators” like Charles Schwab and Robinhood have market caps of approximately $132 billion and $15 billion, respectively. In Charles Schwab—which routes customer orders across many venues including ICE and CME—the proportion of volume routed through them is disproportionate to their market cap share. Robinhood handles about 119 million options contracts monthly, compared to ICE’s ~35 million—even though options are not central to Robinhood’s business model. Still, ICE is publicly valued about five times higher than Robinhood. Thus, as application-level aggregation interfaces, Charles Schwab and Robinhood route customer order flow to various venues, yet despite high volumes, their valuations remain lower than ICE and CME.
As consumers, we assign less value to aggregators.
However, this may not hold true in crypto if the aggregation layer is embedded directly into a product/platform/blockchain. If an aggregator is tightly integrated into the chain itself, clearly this represents a different architecture—and I’m curious how this will evolve. One example is Polygon’s AggLayer, which allows developers to easily connect their L1s and L2s into a network that aggregates proofs and enables unified liquidity across chains built with CDK.

AggLayer
This model works similarly to Avail’s Nexus interoperability layer, which includes proof aggregation and sequencing auction mechanisms, enhancing the power of its DA offering. Like Polygon’s AggLayer, every chain or Rollup integrated with Avail gains interoperability within Avail’s existing ecosystem. Moreover, Avail pools ordered transaction data from diverse blockchain platforms and Rollups—including Ethereum, all Ethereum Rollups, Cosmos chains, Avail Rollups, Celestia Rollups, and hybrid constructs like Validiums, Optimiums, and Polkadot parachains. Developers from any ecosystem can build permissionlessly atop Avail’s DA layer while leveraging Avail Nexus for cross-ecosystem proof aggregation and message passing.

Avail Nexus
Nebra focuses on proof aggregation and settlement, capable of aggregating across different proof systems. For example, it can aggregate proofs from xyz and abc systems into a single agg_xyzabc (rather than aggregating within each system separately, resulting in agg_xyz and agg_abc). The architecture uses UniPlonK, which standardizes verifier work across circuit families, making cross-PlonK circuit proof verification more efficient and feasible. Essentially, it uses zero-knowledge proofs themselves (recursive SNARKs) to scale the verification component—typically the bottleneck in such systems. For clients, “last-mile” settlement becomes easier, as Nebra handles all batch aggregation and settlement; teams only need to modify API contract calls.
Astria is exploring interesting designs around how their shared sequencer works in conjunction with proof aggregation. They leave execution entirely to the Rollup, which runs execution layer software on a given namespace provided by the shared sequencer—essentially just an “execution API,” a way for Rollups to ingest data from the sequencing layer. They can also easily add support here for validity proofs to ensure blocks do not violate EVM state machine rules.

Here, products like Astria serve as step #1 → #2 (unordered transactions → ordered blocks), execution layer/Rollup nodes handle #2 → #3, and protocols like Nebra act as the final mile #3 → #4 (executed blocks → succinct proofs). Nebra could also theoretically represent a fifth step, where proofs are aggregated and then verified. Sovereign Labs is also researching a similar concept for the final step, where proof-aggregation-based bridges are central to their architecture.

Overall, some application layers are beginning to incorporate underlying infrastructure—partly because retaining only the upper application layer may create incentive misalignments and high user adoption costs if they don’t control the base stack. On the other hand, as competition and technological advances continue to drive down infrastructure costs, integrating applications/app-chains with modular components is becoming cheaper. I believe this dynamic will grow stronger—at least for now.
With all these innovations—execution layer, settlement layer, aggregation layer—higher efficiency, easier integration, stronger interoperability, and lower costs become possible. All of this ultimately leads to better applications for users and a better development experience for builders. It’s a winning combination that fuels more innovation—and faster innovation cycles.
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














