10 Blocks per Second: What Kaspa's Speed Means for Real Payments

Kaspa produces ten blocks every second. That single number — 10 BPS — is the headline, but it tells you very little about what changes for someone sending KAS, funding an escrow deal, or building a payment flow on top of the network. The interesting part is not the raw throughput. It is what that throughput does to confirmation semantics, time-lock precision, and the practical UX of self-custody tools.

This article breaks down the mechanism behind 10 BPS, explains how blockDAG and GHOSTDAG make it safe, and shows how Kaspa Forge's non-custodial toolkit uses fast blocks in production today.

Why "just speed up the blocks" does not work

The simplest way to produce more blocks is to shrink the target interval. Litecoin tried this (2.5 min vs Bitcoin's 10 min). Some chains go further. The problem is that a linear blockchain is a single-lane road: only one block can extend the tip at a time. If two miners find a block within milliseconds of each other, one becomes an orphan — valid work that the network throws away. Push the block rate to 10 per second on a linear chain and the orphan rate climbs above 90 %: most mined blocks never make it into the canonical history, hashrate is wasted, and security drops proportionally.

Kaspa sidesteps the orphan problem with a blockDAG. Instead of forcing a single chain, the protocol allows blocks to point to *several* parents. The result is a wide, branching graph where nearly every mined block ends up in the canonical history. Orphan rate drops toward zero even at 10 BPS, because there is no single-tip bottleneck for miners to collide against.

GHOSTDAG: ordering the chaos

A DAG of blocks is not useful on its own; you still need a total order for transactions. This is where GHOSTDAG comes in. The algorithm selects a *selected parent* for each block — the parent with the most accumulated "blue work" — then classifies every other block in the mergeset as blue (well-connected, contributing to security) or red (poorly connected, absorbed but not individually rewarded).

The selected chain — the path of selected-parent links — determines the canonical order of events. Reorgs can happen: the virtual block's selected tip can shift. But GHOSTDAG's robustness guarantee means the chain stabilizes very fast, up to a small suffix. In practice, blocks near the DAG's frontier may reorder; blocks even a few seconds back are effectively final.

This is not just theoretical. The Kaspa wiki describes the mergeset reward structure: every blue block in a chain block's mergeset earns its miner a coinbase output; red blocks in the DAA window earn a reward paid to the *chain block's* miner. The incentive alignment holds because blue work — not raw hashrate — is the scarce resource miners compete for. Miners are rewarded for connectivity, not just speed.

The DAA at 10 BPS

Difficulty adjustment on a 10-block-per-second network requires a different design than Bitcoin's 2,016-block window (which spans ~2 weeks). Kaspa's DAA uses a moving window of 2,641 blocks, counting backward from the virtual block's perspective, including blue blocks and red blocks that fall within the window.

At 10 BPS, the full DAA window spans roughly:

2,641 blocks ÷ 10 blocks/sec ≈ 264 seconds ≈ 4.4 minutes

Difficulty recalculates almost continuously. A sudden hashrate spike is absorbed within minutes, not weeks. A hashrate drop does not leave the network crawling for hours until the next adjustment. The algorithm keeps the average block rate close to the target under volatile mining conditions.

For developers building on Kaspa, there is a second consequence. DAA score — the running counter of blue blocks plus merged-and-rewarded red blocks — serves as the protocol's clock. Covenant opcodes, time-locks, and age checks all reference DAA score rather than wall-clock time. At 10 BPS, each DAA tick is roughly 100 ms:

This mapping is deterministic. Unlike Bitcoin — where a "24-hour" time-lock might resolve anywhere between 20 and 30 hours depending on hashrate luck — a Kaspa covenant delay of 864,000 DAA ticks resolves in *exactly* 24 hours (±seconds).

What confirmations look like in practice

On Bitcoin, "6 confirmations" means ~60 minutes. On Ethereum, ~75 seconds. What does "confirmation" mean on a 10-BPS DAG?

A transaction included in the next block appears in the DAG within ~100 ms on average. But inclusion alone is not security: the block must be part of the selected chain (or at least blue) and deep enough that a reorg is vanishingly unlikely. Because GHOSTDAG stabilizes quickly, a handful of blocks — a fraction of a second — provides strong probabilistic finality for typical amounts. For larger sums, waiting a few seconds (tens of blocks) adds substantial security margin.

The practical numbers:

A payment that "confirms while the buyer is still on the page" is not hyperbole at 10 BPS. It is the normal case.

How Kaspa Forge puts fast confirmations to work

Fast blocks are not an abstract metric. They shape every timing decision in Kaspa Forge's non-custodial toolkit — Kaspa Safe, Kaspa Escrow, and the payment flows we are building on the same platform.

Escrow funding

In Kaspa Escrow, a P2P deal starts when the buyer sends KAS to an on-chain covenant address (escrow.sil, a Toccata contract on mainnet). The backend watcher polls for UTXO changes every 10 seconds. At 10 BPS:

1. The funding transaction is included in the next block (~100 ms after broadcast). 2. The watcher detects the new UTXO on its next poll cycle (≤10 s). 3. With a configurable confirmation threshold (blue-score based), the deal transitions to funded within seconds of the deposit.

Compare this to a hypothetical Bitcoin-based escrow: 10-minute blocks × 3 confirmations = 30 minutes of staring at "awaiting payment." The escrow covenant itself does not care about wall-clock time — its disputeWindow and arbiterDeadline parameters are denominated in DAA ticks — but the faster the ticks, the more precisely the contract maps to real-world hours. A dispute window preset of 72 hours (2,592,000 DAA) resolves in *exactly* 72 hours, not "somewhere between 68 and 80."

Vault delays

Kaspa Safe vaults use an owner-chosen withdrawal delay. When a user initiates a withdrawal, the UTXO must age past the delay threshold (in DAA ticks) before the keyless complete() path unlocks. At 10 BPS:

• A one-hour delay = 36,000 DAA ticks. Exactly one hour.
• The alarm key can cancel at any point during that window (the cancel() path resets the vault state instantly, within one block).
• Dead-man-switch inheritance uses the same age check: if the owner stops checking in, the heir can claim after inheritDelay ticks — again, per-second precision.

The consequence for self-custody UX is significant. On a slow chain, a "one-hour delay" is an approximation that users must mentally hedge. On Kaspa, it is a timer.

Payment flows

The payment acceptance flow we are designing uses HD-derived addresses per order, with a gateway watcher polling the node for incoming UTXO. The confirmation threshold is a single environment variable (KASPA_CONFIRMATIONS). At 10 BPS, even a conservative value of 100 confirmations is 10 seconds. The buyer sees "confirmed" almost immediately. Partial payments — multiple UTXOs arriving in separate transactions within the same second — are summed automatically.

The fee structure reinforces this: Kaspa's base fee is 0.0001 KAS per UTXO utilized. With 10 blocks per second providing enormous throughput, there is no fee pressure from congestion under current demand. Payments settle cheaply and quickly.

Trade-offs and honest limits

10 BPS is not free. The most obvious cost is data volume: ten blocks per second means the DAG grows fast. A Kaspa archival node stores substantially more data than a Bitcoin node of the same age. State bloat — the growing UTXO set, block headers, and the DAG structure itself — is an active research area. The Kaspa wiki lists several related KIPs (extended mass formula, sparse difficulty windows, transient storage handling) aimed at mitigating this problem without sacrificing throughput.

The DAA is more complex than Bitcoin's simple moving average. At 2,641 blocks spanning only ~4.4 minutes, the window must filter statistical noise while remaining responsive. The implementation accounts for blue vs. red classification within the window — a layer of complexity that a linear chain never needs to think about. This is not a flaw; it is a design trade-off that enables the block rate. But it means the difficulty algorithm is harder to reason about from first principles.

Security assumptions are different, not weaker. GHOSTDAG's robustness guarantee is probabilistic. Applications that need absolute finality (not just overwhelming probability) must still wait — the difference is that the wait is measured in seconds, not hours. Developers should choose confirmation thresholds appropriate to their risk model rather than importing numbers from other chains.

There is also a human-factors dimension. Sub-second inclusions can create a false sense of irreversibility for users accustomed to slower chains. A transaction that is "confirmed" in one second is not the same as one that has survived 10 minutes of mining on Bitcoin — the depth-in-DAG is shallower, even if the probabilistic security is already high. Tools built on top of the protocol should communicate this honestly rather than hiding behind a green checkmark.

The bottom line

Kaspa's 10 BPS is the output of a concrete protocol design — blockDAG for parallel block absorption, GHOSTDAG for canonical ordering, and a fast-adapting DAA — that changes what "confirmation" means in practice. For self-custody tools like Kaspa Safe and Kaspa Escrow, it means deposits that land in seconds, time-locks with per-second precision, and payment flows where the buyer does not need to walk away and come back in an hour.

The trade-offs are real: more data, more protocol complexity, ongoing research into state management. But for anyone building or using on-chain tools today, the practical difference is tangible. A vault delay of one hour means *exactly* one hour. An escrow deposit confirms while the buyer is still on the page. That is what 10 blocks per second actually buys you.