Preconfirmations, Flashblocks, Shreds: How Blockchains Become Faster Than 1 Second
This post explains why blockchains need 10–200 ms confirmations to compete with Web2, and how different solutions aim to achieve this.
Blockchains were never designed for real-time applications. Bitcoin confirms roughly every ten minutes, Ethereum every twelve seconds, and even most Layer-2 blockchains still operate with one to two second block times. This is sufficient for settlement, but it is poorly suited for trading, gaming, or any application where users expect sub-second feedback. In contrast, traditional IT systems-from high-frequency trading engines to simple web APIs-routinely confirm actions within one to fifty milliseconds.
To reduce this gap, blockchain designs introduce new mechanisms: pre-confirmations, Flashblocks, miniblocks, shreds, slots, and streamed execution. The terminology differs across ecosystems, but the underlying idea is consistent:
Give the user a (pre-confirmation) before the blockchain’s block is finalized.
Rather than waiting for the next complete block, these systems stream smaller pieces of a block as it is being constructed and provide early guarantees that a transaction is already locked in. Solana was the first network to fully adopt this model through streaming shreds, and Ethereum Layer-2s are now extending the same approach with Flashblocks, preconfirmers, miniblocks, and increasingly low-latency sequencing layers.
This post explains why block production is slow by design, why confirmation times in the 10–200 millisecond range matter for competing with Web2 systems, and how different architectures-Solana, Base, Unichain, Arbitrum, Taiko, and MegaETH-are achieving these faster execution speeds.
1. Solana: Shreds, Slots, and Streaming Confirmation
Solana organizes time into slots of ~400–600 ms. Within each slot, the leader doesn’t wait to build a full block. Instead, it collects transactions, splits the block into small pieces called shreds, and streams these across the network while anchoring them to the Proof of History (PoH) sequence. This allows nodes to see the block forming in real time, not just after it’s finished.
For UX, this is a game-changer. Applications can treat a transaction as “good enough” once its shred is seen and locally verified, even though finality still requires more slots. Solana also implements local fee markets, isolating congestion at the account level, and integrates MEV-aware infrastructure like Jito with sub-second auction cycles. The result is continuous block production, which is why Solana feels fast.
Key points:
Slots last ~400–600 ms.
Shreds stream across the network during each slot, anchored to PoH.
UX benefit: Transactions are visible before finality.
Additional optimizations: Local fee markets and MEV-aware infrastructure.
Solana made block production continuous, driving its perception of speed.
2 Flashblocks / Rollup Boost on L2s
Base and Unichain adopt a similar concept for rollups. Their canonical block times are around 1–2 seconds, but within each block, the sequencer emits Flashblocks every 200 ms. The sequencer continuously builds the next block, slicing it into mini-batches of transactions, each with a cryptographic commitment.
Users see these Flashblocks as preconfirmations: transaction order is fixed within each slice, and the sequencer promises inclusion in the upcoming block unless something goes wrong. This enables wallet UIs to show “confirmed (pre)” in 200–500 ms, rather than waiting for the full block.
However, this introduces some risk. If the sequencer crashes or a TEE (trusted execution environment) fails, a Flashblock can be invalidated. To mitigate this, Unichain ties Flashblocks to TEEs and slashing mechanisms, positioning them between mempool hints and finality.
Key points:
Flashblocks: Preconfirmation every 200 ms.
UX improvement: Fast confirmation, users see a fresh view of the chain.
Risks: Sequencer failure or censorship can invalidate preconfirmed transactions.
Base and Unichain use Flashblocks to reduce latency and transform UX.
3 Taiko: Based Pre-confirmations
Taiko, as a based rollup, must align its block times with Ethereum (~12 seconds) but introduces based preconfirmations. Preconfirmers commit to specific transaction sequences and sign cryptographic promises to include them in the upcoming block. This guarantees a meaningful confirmation long before the block arrives, reducing practical latency to 2–3 seconds.
While not aiming for millisecond responsiveness, Taiko’s decentralized preconfirmers improve UX by reducing trust assumptions without relying on ultra-fast hardware.
Key points:
Preconfirmations signed by multiple preconfirmers.
Reduced UX latency: Approximately 2–3 seconds.
Decentralized approach: Avoids relying on a single sequencer.
Taiko’s focus is on smoother UX with trust-minimized improvements rather than extreme latency.
4 Arbitrum: fast blocks plus Timeboost
rbitrum adopts a different approach: it makes the real blocks very fast—~250 ms on mainnet, down to 100 ms on Orbit chains. There is no separate preblock layer because the block itself is fast enough. On top of this, Arbitrum adds Timeboost, an auction for low-latency ordering.
This setup allows MEV-sensitive users to pay for priority, while others benefit from the natural fast cadence of the chain. As a result, confirmations arrive every 0.1–0.25 seconds, and ordering can be explicitly customized.
Key points:
Fast blocks: Mainnet ~250 ms, Orbit chains ~100 ms.
Timeboost: Express lane auction for low-latency ordering.
Fast confirmations: 0.1–0.25 seconds.
Arbitrum makes the block fast and adds an auction for priority ordering.
5. MegaETH: Mini-Blocks Every 10 ms
MegaETH takes latency to the extreme with a two-layer system: mini-blocks streaming every 1–10 ms, and slower EVM blocks that bundle mini-blocks into canonical batches posted to Ethereum.
Mini-blocks provide immediate UX confirmation, while EVM blocks preserve Ethereum compatibility and security. This setup makes MegaETH feel like a centralized trading engine, with orders settling in real-time, while still routing final settlement through Ethereum.
Key points:
Mini-blocks: Streamed every 1–10 ms for real-time UX.
EVM blocks: Slower canonical batches for Ethereum security.
High throughput: Up to 100,000+ TPS.
MegaETH offers “Ethereum security, CEX-like latency.”
6. Hyperliquid: Latency-Tuned Perp-Chain
Hyperliquid is designed for perpetuals and optimized for low latency. Traders run non-validating nodes close to core infrastructure, and the protocol offers configurable options (CPU, I/O, buffering) to reduce execution time as much as possible.
While Hyperliquid doesn’t specify an exact target for block times, it’s clear that the chain is designed to minimize latency as much as hardware allows. It’s optimized for an on-chain order book rather than general-purpose smart contracts, making it a DeFi-native low-latency chain.
Key points:
Custom nodes: Traders run non-validating nodes close to core infrastructure.
Tuned for latency: Configuration options for reduced execution time.
Specialized chain: Focused on perpetuals and low-latency execution.
Hyperliquid is built for speed, prioritizing low-latency over general-purpose functionality.
Challenge 1. What happens when a preconfirmation is wrong?
Even with streaming miniblocks or Flashblocks, none of these systems can guarantee that every early confirmation will exactly match the final block. A preconfirmed transaction can still be:
reordered, due to MEV, censorship, or express-lane auctions,
dropped, because of sequencer failure or TEE malfunction,
conflicted, when two transactions cannot be executed together.
When this happens, the UX layer must reconcile what the user observed at 50–200 milliseconds with what ultimately lands on-chain. Different ecosystems attempt to manage this gap in different ways.
Some introduce revert protection, defining rules or probabilistic guarantees under which preconfirmations may be invalidated. Others rely on slashing and bonding, where preconfirmers lock capital and are penalized if they break their inclusion promise. Wallets increasingly experiment with risk-aware UI, distinguishing between “soft confirmed” (≈50 ms), “firm confirmed” (≈1–2 seconds), and fully finalized states.
For DeFi applications, this raises two practical questions. First, who absorbs the loss if a trade is executed based on a preconfirmation that later fails? Second, how should this risk be priced in a transparent and predictable way?
The naïve approach—simply voiding incorrect preconfirmations—leads to poor user experience. A user may pay for priority execution, receive a confirmation within 100 milliseconds, and then observe the transaction being reordered or dropped after the final block. If this occurs frequently, preconfirmations lose credibility, and users stop relying on them altogether.
Challenge 2. Pricing preconfirmations remains unresolved
There is still no widely accepted model for pricing preconfirmations. Any viable design must satisfy several constraints at once. It must be economically efficient, with fees reflecting actual revert risk. It must be MEV-aware, avoiding hidden arbitrage opportunities. It must be fair, rather than degenerating into another latency race dominated by a small number of bots. And it must remain robust under adverse network conditions.
These constraints leave several open design questions. Should preconfirmations have a dedicated fee market, separate from gas pricing? How should priority rights be allocated—through per-block auctions, time-sliced access, or application-level guarantees? When a preconfirmation is violated, how should users be compensated, and who ultimately bears the cost? Finally, coordination across domains remains unclear. If multiple chains each operate their own preconfirmation or micro-block systems, how should ordering guarantees be composed across them?
Today, each ecosystem is effectively running its own experiment. Solana explores streamed execution tightly coupled with MEV auctions. Base and Unichain test 200 ms Flashblocks backed by TEEs. Arbitrum focuses on fast blocks combined with express ordering lanes. Taiko emphasizes decentralized preconfirmers. MegaETH pushes ultra-fine-grained mini-blocks.
The engineering mechanisms already exist. What is still missing is the economic layer: the market design that determines how these guarantees are priced, enforced, and integrated.
Closing Thoughts
All presented solutions for fast user pre-confirmations have one clear pattern in common. Blockchain speed improves as soon as block producers stop waiting for full blocks and instead stream partial commitments—shreds, Flashblocks, miniblocks, and preconfirmations. Users receive feedback in tens of milliseconds rather than seconds, even though final settlement remains unchanged.
Solana demonstrated that continuous block construction can make a blockchain feel real-time. Ethereum rollups are now applying the same principle through different mechanisms: millisecond-scale miniblocks, 200 ms Flashblocks, based preconfirmations, and explicit ordering lanes.
Once execution reaches this speed, new challenges become unavoidable. Preconfirmations must be priced, reverts must be handled fairly, and MEV must be managed when ordering decisions occur at millisecond granularity.
Blockchains are transitioning from batch processing to streaming execution. Blocks, pre-confirmations, and min-blocks form a continuous flow of commitments rather than discrete events. Solana initiated this shift; Ethereum rollups are now exploring how far it can be pushed while still settling securely to Ethereum.
This transition will define the next phase of blockchain and DeFi UX.