Every blockchain has a rhythm. Like a heartbeat, it pulses at regular intervals, and with each pulse, a new batch of transactions becomes part of the permanent record. The time between these pulses is what we call block time.

If you've ever sent Bitcoin and watched your wallet for that first confirmation, you've felt block time firsthand. You hit send, and then... you wait. Maybe you refresh the page. Check again. Wonder if something went wrong. Finally, roughly 10 minutes later, that first confirmation appears. That's Bitcoin's block time at work.

This is the second article in Performance Race - a five-part series exploring how blockchains chase speed without losing their principles. And we’re starting with block time: the tempo that dictates how fast a network moves and how quickly users see results.

To catch up, refer to the previous article:

Part 1: Performance Metrics →

Transaction Bundling

Why do blockchains work this way at all? Why not process each transaction as it arrives?

The answer lies within decentralization. Thousands of computers scattered around the world maintain identical copies of a shared ledger. The internet isn’t instant, so messages take time to travel, a transaction sent from New York takes a moment to reach Singapore.

If each computer updated the ledger the moment it received a transaction, the result would be chaos: every node would see transactions in a different order, producing countless conflicting versions of the ledger.

Blocks prevent this. They create synchronization points. Instead of adding transactions constantly, the network agrees: every set interval - 10 minutes, 10 seconds, 400 milliseconds - most pending transactions are bundled into a single block that everyone confirms together. It’s like agreeing to board the train at scheduled times instead of whenever you please.

Spectrum of Speed

Different blockchains have chosen wildly distinct block times, and these choices reveal their priorities:

When Bitcoin was created, a ten-minute block time seemed like a reasonable compromise: fast enough to be practical, yet slow enough to keep the network synchronized across 2009-era internet speeds. This interval gives blocks plenty of time to propagate globally before the next one arrives.

Ethereum and Solana took different approaches. Ethereum aimed to be more than money, offering a platform for applications that demand faster updates, twelve seconds feels more like a slow page load than a wait for paint to dry. Solana, on the other hand, embraces near-instant blocks. At roughly 400 milliseconds, its updates arrive before you can blink, delivering an experience closer to traditional, real-time apps.

UX Perspective

Let's make this concrete. Imagine buying a digital collectible, an NFT of some artwork you’re fond of. You click "purchase" and confirm it in your wallet. Now what?

On Bitcoin (if such a marketplace existed there), you'd wait an average of 10 minutes before the transaction appears in a block. During that time, you're in limbo. Did it work? Should you close the browser? What if someone else buys it first? The seller also waits, unsure if they'll actually get paid.

On Ethereum, that wait drops to around 12 seconds on average. Still noticeable but not agonizing. The marketplace might show a loading spinner that actually completes before you get frustrated.

On Solana, the transaction likely appears in a block within half a second. The experience feels immediate, almost like a regular website. Click, brief pause, done.

Note: Block times are averages each network actively targets, not guarantees. Sometimes you get lucky because your transaction lands just before a block is produced, other times you’ve just missed one and wait for the next. The “luck” is in timing your submission, not in the block time itself.

First Confirmation Issue

Here's where it gets tricky. Getting into a block doesn't mean your transaction is truly final. It just means the network has acknowledged your transaction. On blockchains with faster block times, there’s a small chance a block could be “orphaned” essentially, replaced by an alternative version of history that a different part of the network agreed on.

Exchanges handle this by waiting for multiple confirmations. Bitcoin might require six blocks (~1 hour) for large deposits, which makes reversing a transaction is practically impossible.

Faster block times make things more complex. When blocks arrive every 400 ms, there's less time for the entire network to agree on each block before the next one arrives, increasing temporary conflicts. The network eventually resolves these conflicts, but they happen more frequently.

The tradeoff here is quicker initial feedback, but sometimes more confirmations are needed for full certainty.

Beyond UX

Block time affects more than just how long you wait for confirmation. It ripples through the entire system:

A decentralized game can’t run in real time with 10-minute blocks, it becomes barely feasible at 12 seconds and truly interactive below one. The same compression of time reshapes finance: between blocks, prices shift and arbitrage opens or disappears, so faster chains tighten those windows and force new trading strategies.

Then why doesn't every blockchain choose the fastest possible block time? Why isn't everyone doing sub-second blocks? Because speed isn't free.

Reactive in Focus

As an EVM chain, Reactive evaluated Ethereum’s 12-second block time before charting its own path. Ethereum’s timing balances network propagation, validator participation across diverse hardware, and consensus safety, all critical factors for a decentralized network.

Reactive initially tested 3–4-second blocks to boost responsiveness, but the results showed instability at those speeds. Nodes struggled to maintain consensus reliability, and without a sequencer in our early design, validation needed more breathing room.

Having settled on 7 seconds as the optimal choice, faster than Ethereum’s conservative approach but stable enough to provide:

• Reliable block propagation for all participants
• Consistent validator participation regardless of hardware
• Minimal chain reorganizations
• Sustainable decentralization over time

This choice delivers a 40% improvement in speed over Ethereum's timing. Reactive’s architecture could theoretically support even faster blocks in the future, but such changes would require extensive codebase modifications. For now, the 7-second block time is a proven equilibrium between performance and reliability, with ongoing research on pushing blocks even faster.

Closing Thoughts

Block time is deceptively simple. It seems like just a number - 10 minutes, 12 seconds, 400 milliseconds. But contained within that interval is a fundamental choice about what a blockchain values most.

This single parameter cascades through everything: the anxious wait for a purchase confirmation, the feasibility of real-time applications, the frequency of temporary conflicts. Faster isn't always better, and slower isn't necessarily safer. Each blockchain's block time reveals its philosophy.

Bitcoin's 10 minutes says: "We're building something meant to last centuries, and we can afford to be patient". Solana's 400 milliseconds declares: "The future demands speed, and we'll engineer our way to it". Ethereum's 12 seconds stakes out middle ground: "We want smart contract interaction without sacrificing the principles that make blockchains matter".

But block time is just one dimension of performance. A blockchain with fast blocks can still feel slow if each block only holds a handful of transactions. A network with enormous blocks is useless if they arrive once an hour.

About Reactive Network

Reactive is an EVM-compatible execution layer for dApps built with Reactive contracts. These contracts differ from traditional smart contracts by using inversion-of-control for the transaction lifecycle, triggered by data flows across blockchains rather than by direct user input.

Reactive contracts listen for event logs from multiple chains and execute Solidity logic in response. They can determine autonomously when to transmit data to destination chains, enabling conditional cross-chain state changes. The network delivers fast and cost-effective computation via a proprietary parallelized EVM implementation.

Website | Blog | Twitter | Telegram | Discord | Reactive Docs