There's a useful distinction that most people don't make: the difference between getting included in a block and waiting for enough blocks to pass. These are separate problems with different causes, and the fix for one does nothing about the other.
Transaction speed actually has three layers: how quickly a miner or validator picks up your transaction, how often blocks are produced on the network you're using, and how many confirmations the receiving party requires before they'll release funds. All three can be rate-limiting independently.
Block space is scarce. At any given moment, there are more pending transactions than can fit in the next block. Miners and validators have an economic incentive to include transactions that pay the most — so they sort the mempool by fee and fill blocks from the top down.
Send a low-fee transaction during a congested period, and it'll sit in the mempool until either the congestion clears or someone's node drops it. This is the mechanism behind "stuck" transactions — not a bug, just the fee market working as designed.
Ethereum's EIP-1559 (live since August 2021) restructured this with a two-part fee: a base fee that's burned and adjusts automatically based on block fullness, plus a priority tip that goes to the validator. The base fee establishes a floor — transactions below it can't be included — while the tip determines your position among eligible transactions. This made fee estimation significantly more predictable. Wallets can now read the current base fee and set the tip accordingly, which reduced stuck transactions without requiring users to guess at the entire fee.
Bitcoin doesn't have this structure. Its fee market is a pure auction: highest sats-per-byte wins. During congestion periods — halving cycles, Ordinals demand spikes — low-fee transactions can wait hours.
Even a high-fee transaction has to wait for the next block. This is a protocol-level constraint, not a market one.
Bitcoin produces blocks roughly every 10 minutes, adjusted dynamically by the difficulty algorithm. There's variance — blocks can come in 2 minutes or 40 minutes depending on chance. You can't pay a higher fee to make the next block arrive sooner.
Ethereum slots tick every 12 seconds. That's much faster, but "fast slots" doesn't mean fast finality. Economic finality on Ethereum PoS occurs at a checkpoint roughly every 64 slots — about 12.8 minutes — when a supermajority of validators attest to the chain. A transaction in the first slot of an epoch is finalized around 12-15 minutes later, not in 12 seconds.
Solana runs at ~400ms per slot, though its history of outages has complicated "time to finality" estimates in practice.
Once a transaction is included in a block, it's technically settled — but not necessarily trusted. The practical question is how many subsequent blocks need to be built on top before a recipient is confident the transaction won't be orphaned in a chain reorganization.
Bitcoin exchanges typically require 3-6 confirmations before crediting deposits. At 10 minutes per block, 6 confirmations means roughly an hour of waiting even for a fast, high-fee transaction. This isn't a fee problem — it's a trust problem. The exchange is waiting for enough work to pile up that reversing the transaction becomes economically prohibitive.
Ethereum's PoS finality checkpoint solves this differently. Once finalized, reversing requires burning at least one-third of all staked ETH — a constraint expensive enough that most applications treat finalized blocks as final. The result: Ethereum transactions finalize in 12-15 minutes regardless of exchange policy, not because exchanges are slow but because the protocol defines finality this way.
Optimistic rollups like Arbitrum and Optimism settle on Ethereum L1, but they introduce a 7-day challenge window for withdrawals. This isn't arbitrary bureaucracy — it's the time fraud proofs need to detect and challenge an invalid state transition. Fast bridges work around this by fronting liquidity immediately and taking the risk of waiting for the 7-day window themselves.
ZK rollups don't have this problem structurally. Zero-knowledge proofs can be verified immediately, so L2-to-L1 settlement can happen in minutes or hours rather than days. In practice, proof generation takes time and gas costs influence how often proofs are submitted — but the 7-day wait isn't a fundamental constraint the way it is for optimistic systems.
Ethereum's fee market has become materially more navigable post-EIP-1559, and wallets have gotten better at setting fees correctly. Stuck transactions are less common than they were in 2020-2021.
The more significant shift is ZK proof generation speed improving. As proving time drops and amortization improves, ZK rollup settlement to L1 gets faster. The long-term direction points toward withdrawal periods measured in minutes, not days — but that's still in progress. Not every L2 is there yet.
Single-slot finality (SSF) is on Ethereum's research roadmap. If implemented, it would collapse the 12-15 minute finality window down to a single 12-second slot. That's meaningful for applications that care about time-to-finality, but it's a long-horizon item, not a near-term one.
Transaction speed is primarily a function of fee market conditions, block production schedules, and confirmation requirements — not some abstract "blockchain slowness." Confirmation: ZK rollup withdrawal times shortening, fee estimation accuracy continuing to improve, stuck transactions declining as tooling matures. Invalidation: A protocol change to Bitcoin's 10-minute block target (extremely unlikely), or if optimistic rollup fraud proof windows are successfully shortened via governance without compromising security.
Now: On Ethereum, read the current base fee before submitting. On Bitcoin, check mempool depth when time matters. For L2 withdrawals, understand whether you're using a fast bridge or waiting natively.
Next: ZK rollup settlement times shortening across more networks over the next 12-24 months.
Later: Single-slot finality on Ethereum — multi-year timeline, not settled research yet.
Exchange delays are not blockchain delays. When a platform shows a pending transfer for hours, that's often an internal batch process, compliance check, or liquidity management decision — not a stuck on-chain transaction. These are operationally separate problems and require different diagnoses.
Transaction speed also has nothing to do with value size. Sending 1 BTC confirms in the same time as sending 1,000 BTC, assuming the same fee. The blockchain doesn't know what anything is worth.




