Kaspa explained: a blockDAG, ten blocks a second, and how multisig works

Most proof-of-work chains make blocks one at a time: a miner finds a block, everyone builds on it, and any competing block found at the same moment is thrown away. Kaspa starts from a different question — what if parallel blocks weren't wasted at all?

The answer is a blockDAG, and it's why Kaspa can produce ten blocks every second while staying proof-of-work. With Kaspa support coming to SSP, here's what makes it different and how multisig works on it.

From chain to DAG

In Bitcoin, if two miners find blocks at nearly the same time, the network temporarily forks. One block eventually wins and the other becomes an orphan — the work behind it is simply lost. To keep orphans rare, Bitcoin targets one block every ten minutes, long enough for each block to reach the whole network before the next is found.

Kaspa removes that constraint. Each new block can reference several previous blocks instead of one, so blocks created in parallel all become part of the ledger. The structure stops being a single chain and becomes a directed acyclic graph — a DAG.

A DAG on its own has a problem: if two parallel blocks contain conflicting transactions, which one counts? Kaspa's consensus protocol, GHOSTDAG, solves this by ordering all blocks consistently. It identifies the well-connected majority of blocks built by honest miners and ranks everything into a single agreed order, so every node reaches the same verdict about which transaction came first.

The result is that Kaspa can run at ten blocks per second — the rate since its 2025 Crescendo upgrade — without the orphan waste that would cripple a chain at that speed. It still uses proof-of-work to secure the ledger.

What that means in practice

• Fast confirmations. Transactions are picked up within a second or so. As with any chain, confirmation depth still matters for larger amounts — each block built on top makes a transaction harder to undo — but that depth accumulates quickly.
• Coins, not accounts. Kaspa uses the UTXO model, like Bitcoin: your balance is a set of individual coins, and spending combines some of them and sends change back to you.
• Pruning. Kaspa nodes don't keep the full history forever; older block data is pruned after roughly a day and a half. The current state is always verifiable, but long-term transaction history lives with indexers and explorers rather than every node.
• Small units. One KAS is 100,000,000 sompi, Kaspa's smallest unit.

Fees are measured in "mass"

Bitcoin prices block space in bytes. Kaspa prices it in mass, which combines several costs:

• Size — how many bytes the transaction takes.
• Signature operations — each signature check adds a fixed amount, so a multisig spend weighs more than a single-key one.
• Storage — a rule known as KIP-9 makes transactions that create lots of tiny outputs expensive, to stop the ledger being filled with dust.

For everyday sends this is invisible: fees are small. But it explains a few Kaspa quirks, like why sending a very small amount of change back to yourself can be refused, and why wallets sometimes need to consolidate many small coins before a large payment.

How multisig works on Kaspa

Kaspa has deliberately few address types. A kaspa:q address is controlled by a single key. A kaspa:p address is a pay-to-script-hash address: it commits to a script, and spending requires revealing that script and satisfying it.

A multisig vault is a kaspa:p address whose script says "M of these N keys must sign". Kaspa uses Schnorr signatures, supports up to 20 keys per script at the consensus level, and relays standard transactions with up to 15. Two details make it pleasant to work with:

• The transaction ID doesn't include signatures. You know a transaction's final ID before anyone has signed it, which makes coordinating signatures across devices simpler.
• There's no SegWit or Taproot layer. Kaspa has just three standard output types — single-key, its ECDSA variant, and pay-to-script-hash — so there's only one kind of multisig vault to get right.

One subtlety matters for security. A Kaspa signature commits only to the amount of the specific input it signs, not every input's amount. A careful multisig wallet therefore has each signer look up the coins being spent on its own, rather than trusting amounts supplied by another device.

Kaspa in SSP

SSP is adding Kaspa with the same 2-of-2 model as every other chain: your vault is a kaspa:p address built from one key in SSP Wallet and one on SSP Key, and each device independently checks what it's signing. SSP Enterprise will support Kaspa vaults with M-of-N approval.

It isn't available yet — Kaspa support is in final testing, and it'll be announced with release notes when it ships. The library behind it, @runonflux/kaspa-core, is already open source for anyone who wants to read or reuse it.

The honest summary

Kaspa takes a familiar idea — proof-of-work securing a UTXO ledger — and removes the one-block-at-a-time bottleneck by letting blocks form a DAG. The result is fast blocks, fees based on mass rather than bytes, and a clean multisig design built around one script type.

As with any chain, what keeps your coins safe isn't the block rate. It's who controls the keys — and, with multisig, how many of them have to agree.