What Is Kaspa (KAS)?#
Kaspa (KAS) is an open-source Proof-of-Work Layer 1 network that uses a blockDAG: a directed acyclic graph of blocks. Its GHOSTDAG consensus protocol orders blocks produced in parallel, allowing the network to work with a higher block rate than a conventional single-chain design.
KAS is the native coin used to transfer value, pay transaction fees and reward miners. The public network launched on 7 November 2021.
Kaspa’s current mainnet targets ten blocks per second. Its development also extends into programmable spending conditions and proof verification through the Toccata upgrade.
For a quick reference to the network, mining algorithm and project resources, see the Kaspa directory profile on Chainquiry.
Why Kaspa Uses a BlockDAG#
A conventional blockchain organises accepted blocks into a single chain. When miners discover competing blocks at similar times, the network eventually follows one branch. Valid blocks outside that selected history can become stale.
Increasing block production makes simultaneous discoveries more common. This creates a design challenge: how can a network process more blocks while maintaining agreement between participants who receive information at different times?
Kaspa changes the structure of the ledger. Blocks can reference multiple predecessors, creating a graph of related blocks. Parallel production becomes something the consensus protocol handles directly.
Imagine two miners finding blocks before either hears from the other. Kaspa can retain both blocks in the graph and use its ordering rules to establish their relationship to the wider history.
Keeping parallel blocks does not make conflicting payments valid. Nodes must still apply transaction rules and resolve attempts to spend the same funds twice.
How GHOSTDAG Works#
GHOSTDAG provides an efficient approach to the ordering problem described in the PHANTOM research.
It evaluates relationships between blocks, distinguishes blocks according to their compatibility with the protocol’s concurrency assumptions, and derives an agreed ordering.
The PHANTOM and GHOSTDAG paper sets out the design and its security analysis. Those results depend on stated assumptions about adversarial mining and network behaviour.
For readers, three concepts are useful to separate:
- BlockDAG: the structure connecting blocks.
- GHOSTDAG: the consensus rules used to organise that structure.
- kHeavyHash: the mining algorithm used to produce Proof of Work.
These names describe different parts of the same network.
Origins, Launch and Distribution#
Kaspa grew from research associated with Yonatan Sompolinsky and other researchers into how Proof-of-Work networks could operate with parallel blocks. Its research history predates the public launch.
The community-maintained launch timeline records the mainnet announcement on 7 November 2021. It also documents early network changes, including a split and subsequent hard fork later that month.
Project documentation describes a launch without a premine, ICO or reserved coin allocation. New coins were issued through mining.
That describes the issuance mechanism. It does not establish equal ownership or prove that early participants had identical access to information, equipment or capital. Assessing present-day distribution requires separate evidence, and one blockchain address does not necessarily represent one person.
Crescendo and Ten Blocks Per Second#
The Crescendo upgrade activated in May 2025 and increased Kaspa’s mainnet target from one to ten blocks per second. The Crescendo release notes document the change.
At that target, the average interval between blocks across the network is approximately 0.1 seconds. Individual intervals still vary.
A block rate is different from a transaction rate. Blocks contain transactions, and transaction capacity depends on their size, validation cost and protocol limits. Ten blocks per second therefore does not mean ten transactions per second.
A rapid block rate also needs to be distinguished from settlement confidence. A payment appearing in a wallet, being accepted by the network and satisfying an exchange’s deposit policy are different events.
Comparing security requires more than counting blocks. The surrounding consensus assumptions, mining resources, network conditions and acceptance policy matter.
How Kaspa Mining Works#
Kaspa uses kHeavyHash Proof of Work. Miners perform computational work to compete for rewards, while nodes check that blocks and transactions follow the protocol.
Dedicated hardware exists for this algorithm. For example, BITMAIN’s KS5 specifications identify kHeavyHash and KAS as its intended algorithm and coin.
This matters when reading older mining guides. A guide written around early CPU or GPU participation does not establish that the same equipment is economically competitive today.
Mining results depend on several changing factors:
- The miner’s share of network hashrate.
- Hardware efficiency and acquisition cost.
- Electricity, cooling and maintenance expenses.
- Block rewards, transaction fees and pool charges.
- Uptime, network difficulty and the market value of KAS.
Running a node is a separate activity. A node validates network data; simply operating one does not provide a mining reward.
KAS also does not secure the base network through Proof-of-Stake staking. Any service advertising yield on deposited KAS should be assessed according to that service’s own mechanism and risks.
KAS Supply and the Emission Schedule#
Kaspa’s scheduled total issuance is approximately 28.7 billion KAS.
The Kaspa tokenomics documentation explains why published estimates can differ slightly. Early reward behaviour, rounding and emission calculations affect the final figure. Approximately 28.7 billion is therefore more useful than presenting one integer as perfectly exact.
After its initial issuance phase, Kaspa entered a schedule of monthly reward reductions. Over twelve monthly reductions, the issuance rate approximately halves.
The monthly multiplier is the twelfth root of one-half, equivalent to a reduction of approximately 5.61% each month.
The policy concerns issuance over time. Raising the block rate does not automatically multiply the number of new coins issued per second: the subsidy per block is adjusted accordingly.
As subsidies decline, transaction-fee income becomes more relevant to mining incentives. Whether future activity produces sufficient fee revenue is an economic question that cannot be settled by the emission schedule alone.
Kaspa Compared With Bitcoin#
Both networks use Proof of Work and native coins, but their ledger structure and issuance schedules differ.
| Feature | Kaspa | Bitcoin |
|---|---|---|
| Native coin | KAS | BTC |
| Ledger structure | BlockDAG | Blockchain |
| Consensus approach | Proof of Work with GHOSTDAG ordering | Proof of Work with selection by accumulated work |
| Mining algorithm | kHeavyHash | SHA-256d |
| Target block production | Ten blocks per second | One block approximately every ten minutes |
| Scheduled supply | Approximately 28.7 billion KAS | 21 million BTC |
| Subsidy reductions | Monthly, approximately halving the issuance rate each year | Every 210,000 blocks, approximately four years |
Bitcoin’s developer documentation and project FAQ describe its chain selection, mining and monetary rules.
The table compares technical parameters. It does not rank the networks’ overall security, liquidity or usefulness. Those assessments require broader evidence.
A high block rate can improve responsiveness while also placing demands on infrastructure. Bitcoin’s longer operating history and Kaspa’s newer architecture are both relevant when comparing their development and operational experience.
What Toccata Added to Kaspa#
The Toccata upgrade expanded Kaspa’s mainnet programmability. Current project documentation records activation on 30 June 2026, at DAA score 474,165,565.
The Toccata release ties the upgrade to several Kaspa Improvement Proposals.
Covenants and Programmable UTXOs#
A UTXO is an unspent transaction output: a spendable piece of value subject to conditions.
Covenants allow conditions to constrain the transaction that spends an output. For example, a spending rule can require the transaction to create a successor output with an authorised state.
KIP-17 extends transaction inspection and scripting capabilities. KIP-20 introduces identifiers that help track covenant continuity across UTXO transitions.
These mechanisms support stateful applications, provided their scripts correctly enforce the intended rules.
Proof Verification and Application Sequencing#
KIP-16 introduces facilities for verifying supported zero-knowledge proofs through Kaspa Script.
KIP-21 provides commitments to application-specific transaction ordering, helping proving systems work with the activity relevant to an application.
Together, these changes expand what developers can verify through the base network. An individual application still needs correct implementation, testing and a clear account of its dependencies.
Kaspa’s approach remains rooted in UTXOs. EVM-compatible applications or networks associated with its ecosystem should be evaluated separately from the base-layer scripting model.
What Is Live and What Remains in Development?#
As reviewed on 26 September 2026, the project’s current documentation makes the following distinctions:
| Component | Documented status |
|---|---|
| GHOSTDAG and ten-block-per-second operation | Live on mainnet |
| Toccata consensus features | Live on mainnet |
| Silverscript covenant tooling | Available, with tooling maturity and audit status requiring attention |
| Full vProgs capabilities | Future development direction |
| DAGKnight consensus upgrade | Planned successor; described as upcoming |
The Kaspa developer overview distinguishes deployed consensus features from evolving development tools.
DAGKnight is a separate research and upgrade effort. Its research paper investigates consensus that can adapt to network conditions without relying on the same fixed latency parameter.
A published paper, software release and mainnet activation represent different stages. Future performance targets should be assessed alongside implementation, testing and deployment evidence.
Wallets, Fees and Ecosystem Tokens#
Kaspa’s wallet information provides routes to supported self-custody tools. A wallet manages access to funds; using one safely depends on protecting its keys or recovery information and choosing the correct network.
Fees should be checked in current software. The Toccata node guide documents changed minimum relay and submission fee policies, making some older fixed-fee examples outdated.
Native KAS should also be distinguished from assets created through additional protocols. Kasplex, for example, documents KRC20 and other ecosystem products.
A token using Kaspa-related infrastructure has its own issuance rules, software dependencies and market risks. Its existence does not make it equivalent to KAS or establish an endorsement by the network’s developers.
Trade-Offs and Questions Worth Following#
Kaspa’s design raises useful research questions alongside its technical achievements.
Mining incentives: declining subsidies make the relationship between usage, fees and mining revenue increasingly relevant. Future profitability cannot be inferred from block speed.
Participation and concentration: hardware access, pool distribution and operating costs affect who can participate effectively. A decentralisation assessment needs current measurements.
Infrastructure requirements: the Toccata node guide specifies CPU, memory, storage and bandwidth requirements. Higher performance should be considered alongside the cost of independent verification.
Application maturity: a live consensus feature does not establish that every wallet, bridge or application using it is equally mature. Each product needs its own assessment of code, audits and operational controls.
Market exposure: technical capability does not determine a coin’s price. Liquidity and price volatility remain separate considerations.
These questions provide a practical framework for following the project as its software and ecosystem develop.
Frequently Asked Questions#
Is Kaspa a Blockchain?#
Kaspa is commonly grouped with Layer 1 blockchains, but its ledger is structured as a blockDAG. This allows blocks produced in parallel to participate in the consensus ordering process.
Does Kaspa Have Smart Contracts?#
Kaspa supports native covenant-based programmability following Toccata. The exact capabilities and maturity of a particular application depend on its implementation and tooling.
Can Kaspa Still Be Mined With a GPU?#
Older GPU mining software and guides exist, but dedicated kHeavyHash hardware is available. Technical compatibility alone does not establish profitability.
Is KAS an ERC-20 Token?#
Native KAS belongs to the Kaspa network. Wrapped representations and ecosystem tokens must be distinguished from the native coin.
Continue Your Kaspa Research#
The most useful next step is to connect explanations with evidence: review the current node releases, follow protocol proposals and inspect the assumptions behind applications you intend to use.
The Kaspa profile on Chainquiry collects core network details and project links. For another approach to Proof-of-Work design, explore our DigiByte Insights article, which examines its multi-algorithm architecture.
Kaspa is a useful case study in how a Proof-of-Work network can change its ledger structure and programming model. Its longer-term significance will depend on how those capabilities are maintained and used.
Research Note#
Reviewed on 26 September 2026 using protocol research, public source repositories, release notes and project documentation. This is a document-based editorial review, not an independent node test, security audit or measurement of adoption.
Chainquiry provides independent cryptocurrency research. Coverage is not an investment recommendation. Verify important details through current primary sources.
