Layer 1 blockchain

Kaspa ticker KAS

No public-data lookups yet
3 reviewed developments
40 cited sources

Summary

Proof-of-work block DAG. The work function in the node code is kHeavyHash: a cSHAKE256 hash, a 64 by 64 matrix multiplication derived from the block header, then a second cSHAKE256 hash. Miners publish blocks that point to every tip they know, so blocks mined at nearly the same time are all kept. GHOSTDAG colours blocks that fit a well-connected set (bounded by the parameter k, set to 124 by the Crescendo upgrade, which raised the target block rate) blue and the rest red, then orders all blocks and accepts transactions in that order, skipping ones that conflict with earlier accepted transactions. Value sits in unspent outputs guarded by Kaspa script, which the Toccata upgrade (active 30 June 2026) extended with covenants and zero-knowledge proof checks. 1 4 8 15 19 20 21 22

Design

System: Layer 1 blockchainKaspa is a block DAG rather than a single chain: a block may reference several parents, so parallel blocks are kept instead of orphaned. GHOSTDAG still puts every block into one agreed order and follows a selected chain, so the usual base-layer comparisons apply, with the block-rate and finality caveats recorded in this profile.
Settlement family: Its own design
Scarce resource: Work (proof of work)
State model: UTXO
Finality: Probabilistic
Who makes blocks: Miners, solo or through pools, propose blocks by proof of work. A red block's miner is not paid for it directly: node code pays the reward of red blocks to the miner of the block that merges them.
Fork choice: Each node inherits the blue set of the tip with the most blue work in its past and follows that selected chain. The paper's security bound (about half the hashrate) holds only if real network delay stays within the delay bound built into k; if delay exceeds it, the hashrate needed to attack shrinks. Nodes also refuse to reorganize below a finality depth of 432,000 blocks (about 12 hours). DAGKNIGHT, which drops the fixed delay bound, is proposed, not active.

Qualifications

Block interval · Partial. The 100 ms target is for a DAG of parallel blocks, not a single chain. Block rate is not confirmation time and not transactions per second.
Finality · Partial. Confirmation confidence is probabilistic, but nodes also refuse reorganizations deeper than the finality depth (about 12 hours at 10 blocks per second). A 2020 research note describes a conflict below that point as needing community handling; current node behaviour in that case was not re-verified.
Tps · Unknown. No sourced and classified transaction-rate figure for Kaspa itself was found. Transaction-rate figures published by Kaspa-connected layers describe those layers, not Kaspa, and are not used.
History retention · Partial. Ordinary nodes keep only about 30 hours of block and transaction data; older history is available only from archival operators, and proofs of old inclusion are an unfinished draft proposal.
Settlement family · Partial. Kaspa is an independent network with its own consensus (GHOSTDAG), code base and Kaspa script, which guards unspent outputs with checks such as lock-time and sequence, so its settlement family is recorded as other.

Tradeoffs

This view follows one way of thinking about design priorities, often called the blockchain trilemma. The design-priorities lesson sets out the counter-view. Read the design-priorities lesson.

Emphasizes

Scalability and Security Contested

Gives up

A light home node and on-node history. The published node minimums are 8 cores, 16 GB RAM, a 640 GB SSD and about 80 Mbit/s of sustained bandwidth, ordinary nodes keep only about 30 hours of block data, and GHOSTDAG's security leans on an assumed bound on network delay rather than on slow blocks.Kaspa's own site presents the design as delivering decentralization as well as speed and proof-of-work security. Whether it does depends on how many people can meet the node requirements and on how hashrate is spread across pools, neither of which this review measured, so the reading of which corners Kaspa favours is marked as disputed.

Full node at home

Demanding 9 15 16 23The Toccata node guide lists minimums of 8 CPU cores, 16 GB RAM, 640 GB SSD and 10 MB/s (about 80 Mbit/s), preferring 12-16 cores, 32 GB and 1 TB; it raised disk and bandwidth over the Crescendo guide (256 GB, about 40 Mbit/s). Storage stays bounded because nodes prune block data after about 30 hours. Full history needs an archival node: the wiki gave 1.9 TB in February 2025, before the switch to 10 blocks per second.

Throughput claims

Theoretical peak: 10 8 14 15Theoretical peak; not comparable across chains or with observed load.Blocks per second: the protocol's target block rate (100 ms target time per block) since the Crescendo upgrade of 5 May 2025. This is not a transaction rate.The node guides say their minimum specs (now 8 cores, 16 GB RAM, 640 GB SSD) suffice to sync and follow the network at this rate.A design target that difficulty adjustment aims for, not a measured rate; no rate measured over a stated time window was classified for this profile. Blocks are produced in parallel and may carry overlapping or conflicting transactions, so blocks per second says nothing direct about accepted transactions per second. How many transactions fit in a block depends on the block mass limit and each transaction's mass; ignores propagation, state growth and spam load. Whether typical home connections sustain the stated bandwidth was not measured.

Headline figures are not comparable across chains. A theoretical peak is never a like-for-like number.

Scaling layers

Igra Network (self-described based rollup) · Rollup, mainnet 26 27
Kaspa miners order Igra transactions carried inside Kaspa transactions; EVM execution runs off Kaspa. Igra's launch materials describe attesters who stake IGRA to validate execution state and bridge parameters governed by the project until a DAO takes over within 24 months. They do not describe Kaspa itself verifying Igra state proofs, so users trust Igra's attesters and bridge governance. Public mainnet access per Igra's own announcement of 19 March 2026. (as of Sep 27, 2026)
Kasplex L2 (EVM) · Rollup, mainnet 28 29
Listed as rollup-style because Kasplex's relayer repository describes a service that takes EVM transactions and posts them to the Kaspa network, signed with the relayer's Kaspa key, so Kaspa miners order them. The fetched sources do not use the words based rollup and do not say how the layer's state is validated, who can censor or delay the relayer, or how bridged KAS is secured. The node repository ships a mainnet configuration (a geth node plus a syncer, chain ID 202555); the mainnet launch date was not confirmed from a primary source. (as of Sep 27, 2026)

Capabilities

Capabilities of Kaspa: how each one is provided, or its research status
Capability	How it is provided	Notes and sources
Account abstraction	Structured assessment pending	Not yet assessed for any chain.
Atomic swaps	Unknown	Not yet assessed under the current definitions; Kaspa script has the operations that hash-locked, time-locked contracts need (SHA-256 hashing, equality checks, and absolute and relative lock-time checks, all active in the node's script engine), building blocks with which such swaps can be built, and the Silverscript compiler ships a transfer-with-timeout example. No reviewed specification, wallet tooling or deployed cross-chain swap service was found. 18 25
Authenticated data publication	Built into the protocolLimited scope	Protocol, limited: a publisher can put data in a transaction payload, which blocks commit to, and sequencing commitments (KIP-15, KIP-21) let based applications prove the order of their own activity, so readers can find the commitment, fetch the data from nodes and check it. The limit is retention: ordinary nodes prune that data after about 30 hours, after which only archival operators hold it. No off-chain publish-and-subscribe service was found. 9 13
Light clients	Built into the protocolLimited scope	Protocol, limited: block headers commit to the UTXO set, so a new node can start from a recent pruning point and check the UTXO set it downloads from an untrusted peer. Limits: light proofs that an old transaction was included (proof of chain membership) are only a draft proposal, and wallets usually rely on a node's RPC, which is not light verification. 5 9
Native staking or delegation	Structured assessment pending	Not yet assessed for any chain.
On-chain governance	Structured assessment pending	Not yet assessed for any chain.
Parallel execution	Structured assessment pending	Not yet assessed for any chain.
Payment or state channels	Unknown	No payment or state channel network on Kaspa was reviewed. The layers listed for Kaspa in this profile are rollup-style, not channels.
Programmable spending	Native (protocol or core-team software) Earlier definition	Outputs are locked by Kaspa script (Schnorr and ECDSA signatures, multisig, pay-to-script-hash, timelocks). Crescendo added transaction introspection; Toccata (30 June 2026) added full covenants, covenant IDs that track a covenant's lineage, and verification of Groth16 and RISC Zero proofs. Kaspa stays output-based: the Toccata docs say it does not become an account-style contract chain. 7 10 11 12 17 18
Protocol-verified messaging	Structured assessment pending	Not yet assessed for any chain.
Reversible transfers or recovery	Unknown	Not yet assessed under the current definitions; timelocks plus covenants (since the Toccata upgrade) are building blocks with which scripts can force funds back to a set destination or release them after a delay. Silverscript's examples include a last-will contract with a cold-key path and a transfer-with-timeout refund; these are compiler examples, not audited wallet products, and no cited source shows one live on mainnet. The network cannot reverse a confirmed payment. 11 18 25
Rollups	Partial (layer not stated) Earlier definition	Two EVM layers post their transactions to Kaspa: Igra Network, which calls itself a based rollup, and Kasplex L2, whose relayer posts EVM transactions to Kaspa. Kaspa miners order their transactions, but the reviewed materials do not show Kaspa verifying either layer's state; Igra relies on staked attesters. Toccata's proof-verification opcode makes designs checked by Kaspa itself possible; adoption by these layers was not verified. 10 26 27 28 29
Shielded transfers	Structured assessment pending	Not yet assessed for any chain.
Signed partial offers	Unknown	Not yet assessed under this row's current definition.

Reading these values

How this feature is provided: Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
Structured assessment pending: The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
Unknown: The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
Earlier definition: Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
Reading across rows: The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.

Definitions, schema version and review history

Ecosystem & custody

Ecosystem products for Kaspa
Product type	Status	Notes and sources
Automated market makers	ThinZealous Swap	Zealous Swap's whitepaper describes a constant-product (x times y equals k) AMM for the Kaspa ecosystem. Its published contracts are Solidity code built with EVM tooling, so it runs on an EVM layer connected to Kaspa rather than in Kaspa script; which layer hosts it was not confirmed from a primary source. No AMM running on Kaspa covenants was verified. Liquidity depth was not measured. 30 31 As of Sep 27, 2026.
Issuer-native stablecoins	None found	Circle's USDC address list and Tether's supported-protocols page do not list Kaspa. Stablecoins reported on Kaspa-connected layers are bridged or wrapped: Igra announced bridged USDC (USDC.e) over Hyperlane, and third-party wrapped stablecoin tokens were reported but not verified from a primary source. 26 32 33 As of Sep 27, 2026.
Algorithmic stablecoins	Unknown	Algorithmic stablecoins on Kaspa-connected layers were not reviewed. As of Sep 27, 2026.
Bridges	ThinIgra canonical bridge (KAS to iKAS), Hyperlane to Igra	Igra says KAS locked on Kaspa backs iKAS one-for-one on Igra, and that Hyperlane connects Igra to other chains, including bridged USDC. How KAS moves onto Kasplex L2 was not found in the reviewed sources. No bridge carrying KAS to Ethereum or other major chains was verified. Risk: These bridges are young and depend on the L2 project's contracts, attesters, relayers and governance (Igra keeps control of bridge parameters until a planned DAO handover), not on Kaspa proof of work. Bridged KAS or USDC is only as safe as those parties. 26 27 As of Sep 27, 2026.
Block explorers	Established in the ecosystemkaspa.stream, kas.fyi	kaspa.stream is the explorer linked from kaspa.org; kas.fyi runs an explorer and a documented data API. Both are provider data, not independent validation, and ordinary Kaspa nodes do not keep history beyond about 30 hours, so explorers rely on archival data. 9 24 34 35 As of Sep 27, 2026.
Hardware wallets	ThinLedger (through KasVault)	See the custody section: Ledger Wallet's code has Kaspa behind a feature switch that is off by default, and Ledger's Kaspa page points users to the third-party KasVault wallet; Trezor says it does not support Kaspa. 36 37 39 As of Sep 27, 2026.

Hardware-wallet custody

Hardware-wallet custody for Kaspa
Device maker	Status	What users can and cannot do
Ledger	PartialKasVault (third-party wallet), the route Ledger's Kaspa page namesSame as native: No	Can: Connect a Ledger device to KasVault and review and sign Kaspa transactions on the device, per Ledger's Kaspa page Cannot: Add a KAS account in Ledger Wallet (formerly Ledger Live), as far as readable sources show: its code keeps Kaspa behind a feature switch that is off by default, and Ledger's Kaspa page sends users to KasVaultFirst-party support exists in Ledger Wallet's code but is switched off by default, and no readable Ledger source shows it turned on for users, so the working route today is KasVault. Who maintains KasVault and the Kaspa device app, which Ledger models are supported and whether KasVault handles tokens or covenant outputs were not verified. 36 38 39 40 As of Sep 27, 2026.
Trezor	None foundSame as native: No	Cannot: Use a Trezor device for KAS; Trezor states it does not currently support Kaspa 37 As of Sep 27, 2026.

Public data

iKnow Blockchain has no public-data lookups for Kaspa yet. This is a limit of the service, not a statement about the network.

Public-data lookups for Kaspa
Lookup	Status	What it covers and its limits
Address or account	Not available yet	Public-data lookups for this chain are not built yet.
Tokens and assets	Not available yet	Public-data lookups for this chain are not built yet.
NFTs	Not available yet	Public-data lookups for this chain are not built yet.
Transactions	Not available yet	Public-data lookups for this chain are not built yet.

A lookup covers one address or transaction from one provider. It is never a complete wallet, and an error or private value is reported as unknown, not zero. About public data · Connect your AI

Sourced developments

Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.

Publication date · newest first

Published Sep 22, 2026ProtocolVerified against sources

Rusty Kaspa v2.1.0 released with P2P protocol version 11

The node release streams large sync payloads in 20 MiB chunks, lowers the maximum network message size from 1 GB to 256 MB, adds other hardening and patches a path-traversal issue in the web dashboard. It is not a hard fork.
- Implementation:Released
- Release:v2.1.0 published 2026-09-22
- Activation:not a consensus change
Date basis: GitHub release publication timestamp 2026-09-22T13:55:36Z.

Source: Kaspa developers (kaspanet) — Rusty Kaspa v2.1.0 (external site)
Published Jun 30, 2026ProtocolVerified against sources

Toccata hard fork activated on Kaspa mainnet

The Toccata upgrade activated at DAA score 474,165,565, adding covenants, covenant IDs, zero-knowledge proof verification in script and per-application sequencing commitments (KIPs 16, 17, 20 and 21). The default minimum relay fee rose from 1 to 100 sompi per gram.
- Proposal:KIPs 16, 17, 20 and 21 marked Active
- Implementation:implemented in Rusty Kaspa v2.0.0 and v2.0.1
- Release:released 2026-06-05 (v2.0.0) and 2026-06-15 (v2.0.1)
- Activation:active on mainnet since 2026-06-30
Date basis: Activation date stated on kaspa.org/developments ('live on mainnet since June 30, 2026') and in the Toccata developer guide; the v2.0.0 node release carrying the fork was published on 2026-06-05.

Sources: Kaspa (kaspa.org) — Developments (external site) · Kaspa developers (kaspanet) — Mainnet Toccata Release - v2.0.0 (external site) · Kaspa developers (kaspanet) — Mainnet Toccata Release - v2.0.1 (external site) · Kaspa developers (kaspanet) — Kaspa Toccata Hardfork Node Setup Guide (external site) · Kaspa Docs (kaspanet) — Toccata Dev Guide (external site)
Published Mar 19, 2026Ecosystem projectNot independently verified

Igra Labs announced public mainnet for its EVM layer on Kaspa

Igra Labs announced that Igra Network, an EVM layer that uses Kaspa to order its transactions, opened public mainnet access, with KAS bridged as iKAS for gas and Hyperlane links to other chains.
- Implementation:mainnet announced by the project
- Release:public mainnet announced 2026-03-19
- Activation:project-reported; not independently verified
Date basis: Project press release dated 2026-03-19.

Sources: Igra Labs via Chainwire — Igra Network Launches Public Mainnet as Decentralized EVM Layer on Kaspa's Proof-of-Work BlockDAG (external site) · Igra Labs via Chainwire — Igra Network Announces IGRA Public Token Sale (external site)

Topics your AI can explain

Your AI can explain these topics for Kaspa through the connection, with sources.

What Kaspa is: a proof-of-work block DAG
GHOSTDAG: how Kaspa orders parallel blocks
Kaspa's UTXO model and covenants
Fees on Kaspa: mass, grams and sompi
Confirmations, the finality window and pruning
Common misconception: ten blocks per second is not a transaction rate
Layers built on Kaspa: Igra and Kasplex L2

Known gaps

What this profile's review did not establish:

Maximum supply and the emission curve were not verified from a primary page (the kaspa.org tokenomics page returned not found); only the existence of a month-by-month subsidy table in node code was checked.
The proof-of-work function is taken from node source code (kHeavyHash); no separate written specification of it was reviewed.
DAGKNIGHT is a proposed upgrade, not active; its timing was not verified.
Igra's and Kasplex L2's technical documentation could not be read (an unreadable Notion page and a GitBook redirect), so their state validation and bridge control rest on launch announcements and repositories only.
Kasplex L2's mainnet launch date, how its state is validated and how KAS reaches it were not confirmed from a primary source; the fetched repositories do not call it a based rollup.
Igra's mainnet status is taken from its March 2026 announcement; later operating status was not re-checked from a primary source.
Which Kaspa-connected layer hosts Zealous Swap, and its liquidity, were not verified.
Third-party wrapped stablecoins reported on Kaspa token standards were not verified from a primary source.
No payment or state channel projects on Kaspa were reviewed.
Current node behaviour when a conflicting history reaches below the finality depth was not re-verified; the reviewed description is a 2020 research note.
Node hardware figures are publisher minimums; whether home connections sustain about 80 Mbit/s was not measured.
The archival size figure (1.9 TB) predates the switch to 10 blocks per second; current archival size is unknown.
No sourced and classified transaction-rate figure for Kaspa itself was found.
Ledger device-app maintainer and model coverage were not verified; KasVault's site gives only a one-line self-description. Ledger's remote feature-switch settings could not be read, so whether Kaspa is switched on in Ledger Wallet for some users is unknown.
Mining pool concentration was not reviewed.
Covenant-based token standards introduced with Toccata (for example the KCC20 examples in Silverscript) were not reviewed for maturity or wallet support.

Sources

Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.

All 40 sources were checked in the last 30 days.

PHANTOM and GHOSTDAG: A Scalable Generalization of Nakamoto Consensus (ePrint 2018/104) (external site)IACR Cryptology ePrint Archive · retrieved Sep 27, 2026
The DAG KNIGHT Protocol: A Parameterless Generalization of Nakamoto Consensus (ePrint 2022/1494) (external site)IACR Cryptology ePrint Archive · retrieved Sep 27, 2026
Kaspa Improvement Proposals (KIPs) index (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
KIP 2: Upgrade consensus to follow the DAGKNIGHT protocol (Proposed) (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
KIP 6: Proof of Chain Membership (Draft) (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
KIP 9: Extended mass formula for mitigating state bloat (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
KIP 10: New Transaction Opcodes for Enhanced Script Functionality (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
KIP 14: The Crescendo Hardfork (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
KIP 15: Canonical Transaction Ordering and Sequencing Commitments (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
KIP 16: New Transaction Opcodes for Verifiable Computation (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
KIP 17: Covenants and Improved Scripting Capabilities (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
KIP 20: Covenant IDs (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
KIP 21: Partitioned Sequencing Commitment with O(activity) Proving (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
Rusty Kaspa: Kaspa full node (Rust) (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
Kaspa Toccata Hardfork Node Setup Guide (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
Kaspa Crescendo Hardfork Node Setup Guide (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
Toccata Dev Guide (external site)Kaspa Docs (kaspanet) · retrieved Sep 27, 2026
rusty-kaspa txscript opcodes (source) (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
rusty-kaspa coinbase and reward processing (source) (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
rusty-kaspa proof-of-work state and hashing (source) (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
rusty-kaspa proof-of-work hashers: cSHAKE256 domains ProofOfWorkHash and HeavyHash (source) (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
Some of the intuition behind the design of the invalidation rules for pruning (external site)Kaspa Research forum · retrieved Sep 27, 2026
Node (including archival node requirements) (external site)Kaspa Wiki · retrieved Sep 27, 2026
Kaspa (external site)Kaspa (kaspa.org) · retrieved Sep 27, 2026
Silverscript: language and compiler targeting Kaspa script (external site)Kaspa developers (kaspanet) · retrieved Sep 27, 2026
Igra Network Launches Public Mainnet as Decentralized EVM Layer on Kaspa's Proof-of-Work BlockDAG (external site)Igra Labs via Chainwire · retrieved Sep 27, 2026
Igra Network Announces IGRA Public Token Sale via Continuous Clearing Auction (external site)Igra Labs via Chainwire · retrieved Sep 27, 2026
Kasplex L2 node deployment (mainnet and testnet syncer) (external site)Kasplex · retrieved Sep 27, 2026
Kasplex Relayer: posts EVM transactions to the Kaspa network (external site)Kasplex · retrieved Sep 27, 2026
Zealous Swap whitepaper (external site)Zealous Swap · retrieved Sep 27, 2026
Zealous Swap contracts (Solidity, Hardhat) (external site)Zealous Swap · retrieved Sep 27, 2026
USDC contract addresses (external site)Circle · retrieved Sep 27, 2026
Supported protocols (external site)Tether · retrieved Sep 27, 2026
kaspa.stream block explorer (external site)kaspa.stream · retrieved Sep 27, 2026
kas.fyi developer platform: data types (external site)kas.fyi · retrieved Sep 27, 2026
Kaspa wallet: secure your Kaspa with Ledger (external site)Ledger · retrieved Sep 27, 2026
Kaspa on Trezor (external site)Trezor · retrieved Sep 27, 2026
KasVault: the frontend interface for your Ledger device (external site)KasVault · retrieved Sep 27, 2026
Ledger Wallet feature switch for Kaspa (shared/feature-flags/src/flags/team-coin-integration/currencyKaspa.ts) (external site)Ledger (LedgerHQ/ledger-live) · retrieved Sep 27, 2026
Ledger Wallet feature switch defaults (shared/feature-flags/src/define.ts) (external site)Ledger (LedgerHQ/ledger-live) · retrieved Sep 27, 2026

Report an error

Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.

Report an error about Kaspa Corrections log

Funding disclosure

Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding