Kaspa: A Technical Experiment in High-Speed PoW
$KAS
Kaspa’s core value is not simply that it is “faster.” Its real significance lies in demonstrating that a PoW public chain does not necessarily have to mean low throughput and slow confirmation. Through BlockDAG and GHOSTDAG, Kaspa redesigns the way blocks are organized while preserving the security model of PoW.
Traditional blockchains use a linear structure. When multiple blocks are produced almost simultaneously, the network ultimately selects only one block to extend the main chain, while the others become orphaned blocks. Kaspa adopts a BlockDAG structure, allowing parallel blocks to coexist. GHOSTDAG then classifies and orders these blocks through blue/red coloring and sequencing. As a result, parallel blocks are no longer merely wasted work; they are incorporated into the ledger structure, improving the block utilization efficiency of the PoW network.
After the Crescendo hard fork, the Kaspa mainnet increased from 1 BPS to 10 BPS, reducing the target block interval from 1,000 milliseconds to 100 milliseconds. This shows that Kaspa’s high-speed performance is not achieved by abandoning PoW, introducing PoS, or relying on a centralized sequencer. Instead, it scales within the PoW framework through the BlockDAG consensus structure.
Kaspa’s technical roadmap can be understood in three steps.
The first step is high-speed PoW settlement. BlockDAG GHOSTDAG enables the PoW network to support a much higher block production rate and deliver a faster transaction confirmation experience.
The second step is resource control. A high-speed chain must control state bloat. KIP-9’s extended mass formula manages transaction resource consumption through compute mass and storage mass, preventing large numbers of low-value UTXOs from creating long-term storage pressure for full nodes.
The third step is enhanced UTXO programmability. KIP-10 introduces transaction introspection opcodes and 8-byte arithmetic, allowing scripts to read structural information such as transaction inputs, outputs, and amounts. However, KIP-10 itself is not full Covenants. More precisely, KIP-10 provides the foundation for Covenants; full Covenants mainly correspond to KIP-17, while Covenant IDs correspond to KIP-20.
Toccata is Kaspa’s upcoming major upgrade direction. It involves KIP-16, KIP-17, KIP-20, and KIP-21, and will push Kaspa toward supporting Covenants, ZK proof verification, and more advanced UTXO programming capabilities at the L1 level. However, before Toccata is activated on mainnet, these capabilities should be described as upcoming or planned, rather than as features already fully available on the current mainnet.
Therefore, Kaspa should not be understood simply as “a faster Bitcoin” or just another high-performance public chain. What truly matters is that it continues to evolve along the PoW UTXO technical path: using BlockDAG to increase throughput, mass accounting to control state costs, and Covenants together with ZK precompiles to expand programmability.
Kaspa’s technical significance is that it reopens the evolutionary space for PoW public chains. PoW does not have to remain only a low-speed settlement layer. Through new consensus structures and script extensions, it can move into a new stage of high-speed confirmation, resource-controlled execution, and verifiable computation.