KAS is the native coin people send, receive, mine, and pay fees with.
Beginner answer
What is Kaspa?
Kaspa is a live proof-of-work blockDAG network. It keeps Bitcoin-style mining and UTXO ownership, and GHOSTDAG orders parallel blocks into one payment history.
The limits get their own page: Risks and Open Questions covers adoption, node load, and the security budget.
Plain model
The simple picture
Miners spend real energy, hardware, and operating time to produce each block. That is Proof of Work, and Kaspa runs on it.
A wallet spends specific unspent outputs, called UTXOs, rather than debiting one running balance.
The core move
Parallel blocks are the whole design
A block takes time to reach the rest of the world, so when blocks are produced faster than they propagate, miners keep building on information that is already out of date and keep producing competing blocks. A single chain can only keep one of each pair. Bitcoin's answer is to make blocks rare, roughly one every ten minutes, so collisions are rare too. It works, and it is why a Bitcoin payment settles at the pace it does.
Kaspa takes the other road: keep the fast blocks and fix the ordering. A block references every tip its miner could see, so two blocks found a moment apart both land in the record as parents of whatever gets mined next. That shape is what the word blockDAG names, and GHOSTDAG reads the resulting graph and derives the order.
What you feel is inclusion speed. Mainnet produces ten blocks per second, so a broadcast transaction usually appears inside a block in about a second. What you should not assume is settlement: appearing in a block and being safe from reversal are separate events, and the gap between them is what confirmations measure.
The rest of Kaspa is deliberately unadventurous. Supply is capped and released on a fixed emission schedule with no premine, and application rules built on top inherit that base without changing it.
The ordering rule
How GHOSTDAG turns a graph into one line
Every block names the tips its miner could see when it started hashing. Those references are the whole data structure.
The k cap below decides color. Blocks that stay inside it join the blue set; the rest are marked red and keep their place, their parents, and their transactions.
Each block picks the parent carrying the most blue work as its selected parent. Chain those picks together and you get the closest thing Kaspa has to Bitcoin's longest chain.
Walk that spine from genesis to the current tip, absorbing each mergeset in turn with blue blocks ahead of red ones, and every block in the graph ends up in a single line.
The cap is the part worth slowing down for. Follow a block's parent links back and you get its past; follow them forward and you get its future. What is left over is its anticone: the blocks that came neither before it nor after it. A single chain has no way to rank an anticone, which is why it discards one side of it. GHOSTDAG ranks it instead, using one behavioral difference between honest miners and hidden ones. An honest miner publishes a block the second it is found, so within a propagation delay everyone else sees it and starts referencing it, and its anticone stays small by construction. A miner building a secret history does the opposite. Nobody can reference blocks they were never shown, so withheld blocks surface later carrying wide anticones. The security parameter k caps how many blue blocks may sit in any blue block's anticone, and its value is derived from block rate and expected network delay, so a faster network needs a larger k for the same safety margin.
The first spend of a coin wins, any conflicting spend later in the sequence is rejected, and that is how a graph with no single newest block still produces exactly one payment history. Every node runs the identical procedure over the identical graph, so they all derive the identical order without voting, messaging, or a committee. Blue work is also the tiebreak between competing histories: Bitcoin compares chains by accumulated work, Kaspa compares them by accumulated work in the blue set, and an attacker whose blocks are colored red is spending real electricity that buys no weight in that comparison. Losing blocks stop being waste, so the block rate can rise without the orphan rate eating the security budget.
Confirmations
Fast is not final
Your wallet broadcasts the transaction and nodes pick it up.
A miner mines it into a proof-of-work block.
GHOSTDAG places it against the blocks mined in parallel.
Nodes accept it under Kaspa's consensus rules.
Reversal risk keeps falling as more blocks stack proof-of-work on top of it.
On a single chain a confirmation is easy to picture: one more block stacked on the block holding your payment. Kaspa has no single stack. Your block sits in a graph, and what piles up on it is blue work, the proof-of-work carried by every later blue block whose history includes yours. Undoing the payment means producing a competing set of blocks heavy enough to outweigh the one the network already accepted, and every new block referencing your transaction raises that bill. Wallets and explorers report the result as a confirmation count. At 10 BPS those references arrive quickly, which is why Kaspa's risk curve drops steeply in the first seconds. Steeply is not vertically.
Finality depth answers a different question: how far back the protocol will let anyone rewrite. It is a consensus parameter, it sits far deeper than any payment wait, and once history is buried past it nodes reject a reorganization outright, which is also what makes pruning safe.
Kaspa publishes no universal confirmation count, and a single number would be the wrong shape of answer. Three things move the honest one. The value at stake sets how much an attacker stands to gain. Current hash rate and its spread set what competing work would cost to produce. Whether the payment can be undone outside the protocol counts too, because a shipping hold or a customer relationship tolerates a thinner wait than handing over a good nobody can claw back. Exchanges and payment processors publish their own deposit policies, and those are the numbers that govern what a user experiences.
Throughput
Ask "TPS of what?"
Status checked August 1, 2026: Kaspa mainnet runs the Crescendo-era 10 BPS network. Toccata went live at DAA 474,165,565 and changed proof and covenant capacity. Plain payment TPS tracks the 10 BPS network and transaction mix.
| Workload | Answer | Why the number changes |
|---|---|---|
| Simple L1 payments | Roughly 2.5k to 3.4k TPS for plain transfers. | Set by 10 BPS and block-mass limits against simple transaction mass. |
| Covenant or programmable L1 transactions | Job by job, usually below simple-payment TPS. | Covenants add script work, state rules, covenant IDs, extra outputs, and storage effects. |
| ZK proof or settlement transactions | Fewer, heavier L1 transactions. One proof or settlement transaction can carry many off-chain app actions. | Set by the proof system, proof size, check cost, batch size, proving time, and settlement design. |
| Effective ZK app or future vProg throughput | App by app, and it can beat raw L1 transaction TPS. | Count app actions per proof batch or settlement cycle. State access and prover work are the real limits. |
None of that makes throughput unlimited. A proof proves a statement about chosen inputs, so outside facts still need an anchor: a light client, finality certificate, reporter set, oracle, or challenge process.
Where the payment numbers come from
Kaspa mainnet makes ten blocks per second. Current mainnet params cap compute and storage block mass at 500,000, which gives a budget of 5,000,000 transaction mass per second before policy, fees, relay, storage shape, and real mempool behavior come in. A signed plain P2PK-style 1-input, 1-output payment costs roughly 1.6k mass by the code's careful math; add a change output and a 1-input, 2-output payment runs closer to 2.0k mass. Divide the block budget by those shapes and the count lands around 250 to 300 simple transactions per block, the mid-2k to low-3k TPS lane at 10 BPS. Leaner shapes and rounding push the top end to the often-quoted 3.4k TPS. Benchmarks built on fake minimum-size transactions score higher than that, and what they measure is a lab ceiling.
A raw count of transactions per block hides the real limit, which is mass. The implementation measures three dimensions: compute mass from serialized bytes, script-public-key bytes, and signature-operation or compute-budget work; transient byte mass; and storage mass. Each is normalized against its own block limit, and a transaction is charged the largest of the three rather than their sum. Anything that makes a transaction bigger, from extra outputs to covenant metadata to proof bytes, crowds out the simple transfers competing for the same budget. Kaspa's docs put the payload ceiling around 25 KB when payload data dominates a standard transaction, because the standard transaction mass ceiling and transient byte accounting still apply on top of it.
Toccata leaves the payment limit alone. Transient mass rises from 500,000 to 1,000,000 at activation, while the compute and storage reference limit holds at 500,000, and the Toccata guide ties that rise to fitting STARK-sized proofs. Toccata also adds v1 transaction fields such as output covenant data and input compute commitments, and raises the standard minimum relay fee. It is mostly an upgrade to what L1 transactions can say and check.
| Piece | What it adds | TPS implication |
|---|---|---|
| KIP-17 covenants | Transaction introspection and script tools for stateful UTXO rules. | More expressive transactions run heavier than simple payments. |
| KIP-20 covenant IDs | A 32-byte covenant identifier that gives covenant state a lineage. | Backs asset rules, at the cost of extra data and checking work. |
| KIP-16 ZK precompile | OpZkPrecompile for proof paths such as Groth16 and RISC0-Succinct. | Proof transactions spend L1 room on checking work, not on moving coins. |
| KIP-21 sequencing commitments | Partitioned lane commitments. | Cuts app proving cost. It is not itself an end-user TPS number. |
vProgs remain roadmap architecture. Toccata ships the parts vProg-style systems need without shipping vProgs. KIP-21 stops every prover from having to follow the whole DAG for every app: its partitioned commitment design targets O(activity) proving, so a prover for one app lane tracks only that lane. Current params cap user-lane churn at 50 non-coinbase lanes per block and 1,000,000,000 gas per lane, which at 10 BPS is a worst-case 500 user-lane updates per second, and user transaction throughput still needs its own transaction-shape math on top. The public kaspanet/vprogs repo shows where the build is headed. Michael Sutton's Argent is an actor-based language and compiler that already builds multi-contract covenant apps into Silverscript, with an audit as the gate its README sets before real use.
Live vs next
What's live, what's not
| Claim | Status | Safer wording |
|---|---|---|
| Kaspa is Proof of Work, 10 BPS, ordered by GHOSTDAG | Live | All three describe current mainnet in the Crescendo era. |
| Toccata has activated on mainnet | Activated | Toccata crossed its mainnet activation score. That protocol switch is live; app, wallet, explorer, and SDK support still need their own checks. |
| July 2026 is a sudden emission cliff | Misleading | Emission steps down once a month, keyed to DAA score rather than the calendar. July 2026 sits inside one of those scheduled steps. |
| GHOSTDAG is DAGKnight, or DAGKnight is current mainnet consensus | Research | DAGKnight is a separate, later consensus design, still research and implementation work. Current mainnet consensus runs GHOSTDAG. |
| 10 BPS means payments are final immediately | No | 10 BPS is live and speeds up inclusion. Reversal risk falls as proof-of-work stacks up, so a recipient waits for the depth the amount at stake deserves. |
| The blockDAG means unlimited TPS | No | Throughput is bounded by block capacity, mempool policy, fees, and demand. |
Anything not listed here goes through the claims checker, which sorts a claim into live, testnet, targeted, roadmap, research, wrong, unsupported, or out of scope.
Read next