05 · Modular Blockchain
Modular Blockchain Architecture
Specialized layers, more moving parts, new failure modes, and a UX that must explain where time and risk live.
By John Wright-Nyingifa · Product Designer building infrastructure for DeFi, DePIN, and autonomous agents.
Live Signal · March 2026
Total L2 TVL peaked at $49B (Oct 2025), currently $38-44B. 100+ Ethereum L2/L3 mainnets tracked on L2Beat, but activity concentrates in the Big Three: Arbitrum (~44% TVL), Base (~33%), OP Mainnet (~6%). All three hit Stage 1 with live permissionless fraud proofs. Caldera deployed 100+ rollups. Conduit launched the first ZK rollup stack via OP Succinct (1-hour finality vs 7-day). Celestia commands ~50% DA market share at 55x cheaper than ETH blobs.
Modular blockchains split what monolithic chains do "in one place" into specialized layers. The payoff is scale and flexibility. The cost is more moving parts, new failure modes, and a UX that must explain where time and risk live.
The enterprise wave makes this urgent: Robinhood, Kraken, Uniswap, and Sony are all operating dedicated L2s. Dozens of generic L2s launched in 2023-2024 became ghost towns. Activity is consolidating on 5-10 major chains while hundreds of app-specific chains exist in the long tail.
The Modular Stack
Where computation happens: transaction execution, state transitions, local fees and block constraints. Execution can be fast, but it is not necessarily final.
Where ordering happens: transaction ordering, batch formation, inclusion guarantees and censorship policy. Often the biggest UX lever because it determines how quickly users see progress.
Where data needed to reconstruct state is published. Ensures anyone can verify and rebuild the chain state. Prevents "state without data" attacks. DA is a liveness + transparency promise.
Where disputes resolve and economic finality anchors. Often an L1 or shared settlement layer. Provides the ultimate "truth" about what counts.
How correctness is proven: fraud proofs (optimistic), validity proofs (ZK), or hybrid designs. Answers: "Was this execution correct?"
The operational plumbing: relayers, indexers, provers, RPC infrastructure, watchers and monitoring. Often the source of "it's stuck" incidents.
Where the security budget comes from: shared validator sets, restaking, shared sequencer sets, settlement-layer security.
MODULAR STACK (March 2026) EXECUTION 100+ rollups live ├─ Arbitrum One $17B TVL, Stage 1, fraud proofs live ├─ Base $14B TVL, Stage 1, 60%+ of L2 transactions ├─ OP Mainnet $2.6B TVL, Stage 1, Superchain ecosystem └─ 100+ others Enterprise (Robinhood, Kraken, Sony) + app-chains DATA AVAILABILITY ├─ Celestia 50% market share, $0.07/MB (55x < ETH blobs) ├─ EigenDA V2 100 MB/s throughput └─ ETH Blobs $3.83/MB, native but expensive SEQUENCING ├─ Espresso $28M Series B (a16z), HotShot consensus ├─ Astria Middleware blockchain, decentralized sequencer └─ Radius Encrypted mempool, trustless ordering RAAS ├─ Caldera 100+ rollups (ApeChain, RARI, Injective) └─ Conduit 40+ mainnets (Zora, Gitcoin), first ZK stack
Data Availability
Users don't care about blobs, but they feel blob delays.
DA works by publishing chunks of transaction data as blobs. Commitments are posted on a settlement layer. Users don't see blobs, but they feel the delays when blob publishing is slow.
Data availability sampling lets nodes check "is the data probably available?" without downloading everything. Many small checks, high confidence when enough samples succeed.
Commitments (hashes, polynomial commitments) ensure data cannot be altered without detection and reconstructors can verify they got the right pieces.
When data is missing: verification may stall, withdrawals/finality may pause, the system may enter degraded mode. Design goal: do not pretend progress is happening when DA is unavailable.
Spikes from: airdrops and mints, NFT launches, market volatility, MEV-driven bursts. Users experience this as: "Why did my confirmation take longer than normal?" "Why can't I withdraw yet?"
Sequencers
The operational heart of rollups.
Sequencers collect transactions, order them, and produce batches that get posted for settlement/verification.
A commitment is the chain saying "here is the ordered list." Commitment is not finality. The UX must separate these clearly.
Is ordering first-come-first-served? Can the sequencer reorder? Are there fairness constraints? These are UX issues because they change perceived reliability.
In ZK rollups, proving can be parallelized, queued, or outsourced to prover networks. Proving becomes a throughput bottleneck.
If sequencing is decentralized: leaders rotate, performance varies by leader, failover introduces micro-delays.
Sequencer failure looks like: transactions not included, transactions included but not published, increased reorg risk. Starknet's 9-hour outage (Sept 2025) showed what this feels like to users.
SEQUENCER PIPELINE
Mempool → Sequencer → Batch → Publish → Prove/Challenge → Settle
│ │ │ │ │ │
User txns Ordering Group DA layer Fraud/validity L1 finality
arrive + policy + seal publishes proof system anchorsCross-Layer Flows
A single user action may cross execution, sequencing, DA, settlement, and verification.
Cross-domain actions start with a source-chain event, a message payload, and a commitment to that message.
To execute elsewhere, the system needs proof that the message is real and final enough.
Routers/solvers validate: liquidity availability, trust tier of bridges, latency vs user constraints.
A single action may cross: execution (rollup), sequencing (rollup sequencer), DA (blob publishing), settlement (L1), verification (fraud/validity). Five systems behind one "Send" button.
"Included" (sequencer accepted) → "Available" (data published) → "Verified" (proof/challenge resolved) → "Settled" (economic finality). Four stages that most UIs collapse into "Confirmed."
WHAT THE USER SEES vs WHAT'S HAPPENING User view: ┌──────────────────────────────────┐ │ Sending 1 ETH to 0x4a... │ │ ◐ Confirming... │ └──────────────────────────────────┘ System view: ① Sequencer receives tx (instant) ② Sequencer orders & batches (2s) ③ Batch posted to DA layer (seconds-minutes) ④ DA confirms availability (seconds) ⑤ Proof generated or challenged (1hr ZK / 7 days optimistic) ⑥ Settlement on L1 (12-15 min for L1 finality) The user sees step 1. Steps 2-6 are invisible. When step 3 or 5 fails, the user has no idea why.
UX Implications
Make phases explicit: Submitted → Included by sequencer → Data available → Verified → Settled. Each with estimated time.
Instead of "Pending," map to: sequencer queue, DA publishing delay, prover queue, settlement confirmation. Users need to know where the wait lives.
"Fast confirmation" (sequencer) and "Final confirmation" (settlement/verification). Two tiers users can learn once and apply everywhere.
When a task spans layers, show: what changed now, what remains to finalize.
Normal / Degraded / Down, with estimated inclusion time range. Visible on every L2 interface.
Available / Delayed / Unavailable. Withdrawals: Enabled / Paused. Ambient until something breaks.
UX Implications
→ Show the pipeline, not the layers. When "pending," which layer is it pending on? Arbitrum's 7-day challenge vs Conduit's 1-hour ZK finality are fundamentally different.
→ Sequencer transparency. Starknet's 9-hour outage showed what happens when users can't see health. Based rollups (Taiko) solve this architecturally.
→ DA health as ambient indicator. Celestia at 50% market share means half of rollups depend on it. Show status, don't foreground it until it breaks.
→ Design for consolidation. The Big Three own 83%+ of TVL. Multi-chain interfaces should prioritize them.
Glossary
Whether the data needed to verify state is accessible.
Service/network that orders transactions for a rollup.
The layer that anchors final economic truth.
Proving execution correctness (fraud proofs or validity proofs).
Published data unit used for DA.