The deep answer
What is Kaspa?
Kaspa is what happens when proof-of-work stops pretending every block must stand in a single-file queue.
It is a fair-launched, fixed-supply, proof-of-work currency and sequencing layer built around a blockDAG. Instead of throwing away honest blocks that arrive at nearly the same time, Kaspa includes them, orders them through GHOSTDAG, and uses that structure to make proof-of-work fast without swapping miners for validators.
Proof-of-work, not staking
Kaspa keeps the Nakamoto idea: open mining, work first, consensus after.
BlockDAG, not one chain
Parallel blocks are included and ordered instead of being treated as wasted accidents.
10 blocks per second
Crescendo moved mainnet from 1 BPS to 10 BPS on May 5, 2025.
Fair launch, fixed supply
No premine, no ICO, no hidden allocation, and about 28.7B KAS maximum supply.
The problem
Bitcoin found neutrality. It paid in waiting time.
Nakamoto consensus works because miners compete outside the ledger. The chain with the most accumulated work becomes the accepted history. That design is simple, open, and brutally hard to fake.
The weakness is not proof-of-work itself. The weakness is the single chain. If blocks arrive faster than the network can spread them, honest miners build parallel blocks. Old chains call those blocks stale or orphaned. Their work does not help grow the accepted chain, and the effective gap between honest miners and attackers shrinks.
That is why classic proof-of-work chains keep block rates slow. They are not slow because miners are slow. They are slow because a single chain has to avoid too many honest forks.
The move
Kaspa keeps the work and changes the shape.
In a blockDAG, a block can point to multiple previous blocks, not just one parent. Miners reference the tips they know about. Blocks that would have been discarded by a chain can remain part of the ledger structure.
GHOSTDAG then classifies blocks and produces a shared order. The common shorthand is blue and red blocks. Blue blocks are well-connected to the honest cluster. Red blocks are still visible to consensus, but they do not carry the same ordering weight. The selected parent chain and accumulated blue work give nodes a consistent way to converge on the same history.
This is the core of Kaspa: not a faster block-time tweak, but a different consensus structure for proof-of-work.
Kaspa does not discard honest parallel work. It turns it into ordered history.
That one design choice is why Kaspa can discuss 10 BPS, 100 BPS, real-time sequencing, and proof-of-work in the same system.
Why Kaspa is superior
Kaspa is superior to every competing L1 design.
The reason is not hype. Kaspa keeps proof-of-work fairness and open mining, fixes the single-chain orphan bottleneck with GHOSTDAG, reaches high block rates on mainnet, lowers miner variance, and keeps programmability on a path toward verifiable execution instead of turning every node into a shared VM bottleneck. For decentralized base-layer money and sequencing, it is the strongest architecture in crypto.
Compared with Bitcoin-style chains
Kaspa keeps proof-of-work and removes the old single-chain penalty. It changes the ledger from a line into a DAG, orders the DAG, and attacks the throughput-security bottleneck at the consensus layer instead of accepting slow blocks as destiny.
Compared with proof-of-stake systems
Kaspa does not need validator committees, delegated stake, slashing politics, or stake-weighted governance to decide ordering. Mining remains permissionless and external to the ledger state, which is exactly why the base layer stays neutral.
Compared with fast L1s
Kaspa speed is not built on a small leader set, special hardware assumptions, or a giant monolithic VM. It keeps a lean UTXO base layer and pushes programmability toward verifiable execution instead of making every node execute every app.
History
The short version is already long.
Kaspa did not appear as a quick fork with a faster block-time setting. It came out of a long research line around how to generalize Nakamoto consensus without losing the point of Nakamoto consensus.
The unsolved problem: Nakamoto consensus is secure, but slow
Bitcoin proved that open proof-of-work could create neutral digital money. The price was latency. If blocks come too quickly, honest miners often find blocks at the same time, older chains discard those parallel blocks, and security drops as orphan rate rises.
PHANTOM and GHOSTDAG turn the chain into a DAG
Kaspa grew from the research line around GHOST, SPECTRE, PHANTOM, and GHOSTDAG. The key move was to stop pretending only one block can be useful at a time. GHOSTDAG gives a practical ordering rule for a proof-of-work blockDAG.
Mainnet launches as fair proof-of-work
Kaspa launched publicly with no premine, no ICO, no pre-sale, and no allocation. Every KAS in circulation had to be mined. That matters because the social layer of a money protocol begins at issuance.
Rusty Kaspa becomes the engine room
The node stack was rewritten in Rust, giving Kaspa the performance headroom needed for a serious block-rate increase. The rewrite turned the theory into production infrastructure rather than a paper trophy.
Crescendo moves mainnet to 10 BPS
Crescendo raised the mainnet block rate from 1 block per second to 10 blocks per second. That means roughly 864,000 blocks per day, much faster inclusion, and dramatically lower mining-reward variance than slow-block proof-of-work chains.
Toccata, vProgs, DAGKnight, and higher block rates
The current frontier is programmability and stronger responsiveness: covenants and ZK verification through Toccata, verifiable programs for off-chain execution with on-chain proof checking, and DAGKnight as the next major consensus research path.
High block rate changes miner reality.
Slow proof-of-work chains create brutal variance. Bitcoin has roughly 144 blocks per day. Kaspa at 10 BPS has roughly 864,000 blocks per day. That does not make every miner profitable, but it does change the payout rhythm.
More frequent blocks mean smaller, more frequent rewards. For miners, especially smaller miners, variance falls. Pools become less mandatory as a survival tool. That matters because mining centralization often begins as variance management.
The cleaner claim is this: Kaspa makes fast proof-of-work practical enough that mining can stay open while users get near-real-time inclusion.
What is waiting next: programmability without surrender.
The interesting future is not "Kaspa gets smart contracts" in the lazy sense. The interesting future is whether Kaspa can add serious programmability while keeping the base layer fast, proof-of-work, and lean.
Toccata and covenants
Toccata is the next hard-fork track described by Kaspa developer material. It bundles covenant and script upgrades, covenant IDs, ZK verifier precompiles, and sequencing commitments. It gives the base layer sharper tools without turning Kaspa into a bloated VM chain.
vProgs
vProgs, short for verifiable programs, are Kaspa Research draft work for programs that execute off-chain but publish data and cryptographic proofs to Kaspa. The design goal is sovereignty plus synchronous composability: independent programs that can still interact atomically through one fast proof-of-work sequencer.
DAGKnight
GHOSTDAG uses a fixed latency parameter. DAGKnight is designed to remove that hardcoded assumption and let consensus adapt to observed network conditions. If the network is healthy, confirmations can converge faster; if the network is under stress, safety wins and confirmation depth stretches.
100 BPS ambitions
Kaspa public material frames 100 blocks per second as a long-range direction, not a casual website number. Getting there requires consensus work, node performance, pruning, networking, and sober engineering. The important part is that Kaspa has a research path for it.
What still has to prove itself.
Kaspa already proved that a live proof-of-work blockDAG can run at 10 BPS on mainnet. The next claims are harder. vProgs need specs, implementations, prover economics, developer tooling, and actual useful applications. DAGKnight needs production-grade implementation and careful activation. Higher BPS needs networking and node performance to keep up.
That is why the correct Kaspa thesis is not "everything is solved." It is better than that: the old proof-of-work bottleneck was not a law of nature, and Kaspa has already shipped the first major break from it.