Every block names the tips its miner could see: those references are the data structure.
Beginner answer
What is Kaspa?
Kaspa is a live proof-of-work blockDAGBlocks arrive in parallel, all kept: a graph, not a line. network, coin KAS: Bitcoin-style mining, UTXOA coin spent whole, replaced by change., GHOSTDAG order.
Limits get their own page: Risks and Open Questions.
The core move
Parallel blocks are the whole design
A block takes time to reach the rest of the world; outrunning that produces competing blocks a single chain keeps only one of. Bitcoin's fix: rare blocks.
Why rare blocks are the fix, and what it costs
At a ten-minute interval, propagation delay is small, so collisions are rare and cheap to discard; the cost lands on confirmation time.
Bitcoin, 1 every 10 minKaspa mainnet, 10/s
Checks against Decker & Wattenhofer's stale rate (1.69%): 10.3 s.
Each thrown-away block cost real electricity and bought nothing.
A model, not Bitcoin today.
Single chain so far: 0 kept, 0 thrown away
kept, on the chainthrown away, off it
BlockDAG so far: 0 kept, 0 thrown away
every block kept, each pointing at the parents it saw
The collision formula, the 72% figure, and the paper it checks against
Blocks arrive at random, a Poisson process with rate λ, colliding when the next is found before the first finishes spreading:
p = 1 − e−λd (λ = block rate, d = propagation delay); discarded share = λd ÷ (1 + λd)
At λd = 2.51, discarded share is about 72% (inferred). Verified against the PHANTOM/GHOSTDAG paper (eprint.iacr.org/2018/104).
Kaspa keeps the fast blocks and fixes the order instead: a block points at every tip its miner could see, and GHOSTDAG orders them.
The ordering rule
How GHOSTDAG turns a graph into one line
The k cap decides colorWell-connected blocks are blue, less-compatible ones red..
Each block picks the parent with the most blue workAccumulated PoW of blue blocks. as its selected parent.
Walk that spine, absorbing each mergesetPast blocks a new block pulls in. blue-first.
Miners don't take turns: they publish whenever they find a block, so more than one can arrive at once.
Advanced: hide blocks, then release them
Mine secretly, then release: see what the network did.
Your blocks are hidden. No one else can see or build on them yet.
The rest of the network is not waiting: it keeps mining and publishing while you stay hidden.
Set k, how many uncounted neighbors a block may have and still count
Caps unseen neighbors still counted: lower locks out sooner, raise counts more.
The block graph
Scroll to see more →
counted in the order
locked out
Hover or tap any block to see why.
Linear order
The one order every node agrees on.
Without it, two people could be told different owners for the same coin.
How the colors get decided
The DAG has no single "now," so Kaspa's answer is the virtual block: never mined, standing in for what a node saw.
A single chain can't rank an anticoneBlocks in neither a block's past nor its future., so it discards one side. GHOSTDAG ranks it: honest miners publish instantly, hidden ones surface late.
An attacker's red blocks buy no weight; a higher block rate doesn't burn security budget like a single chain would.
Confirmations
Fast is not final
Your wallet broadcasts it; nodes pick it up.
A miner mines it into a block.
GHOSTDAG places it against parallel blocks.
Nodes accept it under consensus rules.
Reversal risk falls as blocks stack on top of it.
Kaspa has no single stack to count, so it publishes no universal count. This prices the wait.
What actually sets a safe wait, and how finality depth differs
At ten blocks a secondWritten 10 BPS. Kaspa ran at one block a second until Crescendo, DAA score 110,165,000., risk drops steeply. Finality depthThe threshold past which old history counts as settled. goes deeper.
Throughput
Ask "TPS of what?"
TPS is not one number: it depends on the transaction, cheap for payment, costly for proof.
Four workload types, and why the TPS number moves
| Workload | Answer | Why the number changes |
|---|---|---|
| Simple L1 payments | About 2,450 TPS for a payment with change, 3,070 without. | Set by the block rate 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. |
| ZKZero-knowledge: a proof that a statement is true without revealing the data behind it, so a script can accept a claim about work done elsewhere without seeing that work. 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: outside facts still need an anchor.
Build a transaction and see which mass dimension gets charged
Kaspa charges a transaction for the room it takes, counted as massCostliest work, only that..
Build the transaction
This frees as much state as it creates, so storage mass is 0.
Switch the input script: a plain signature, a covenant, or a proof check
How many fit in a block
0 transactions like this fit in a block
0 transactions per second at ten blocks a second, if every block were full of this shape.
Three limits, each its own budget; whichever empties first sets the count.
Show the mass formulas
Transaction size
size = 94 (fixed header: version, in/out counts, locktime, subnetwork id, gas, payload hash, payload length) + payload_bytes + inputs × (118 fixed bytes: outpoint 36, sig-script length field 8, signature script ~66, sequence 8; +2 if covenant/v1) + outputs × (52 fixed bytes (value 8, version 2, script-length field 8, P2PK-style script 34) + 34 per output, if that output carries a covenant id)Compute mass
compute_mass = size × mass_per_tx_byte (1) + Σ(2 + output_script_len) × mass_per_script_pub_key_byte (10) + script_mass script_mass = inputs × 1 sigop × GRAMS_PER_SIGOP_COUNT_UNIT (1000) [simple] = inputs × compute_budget_units × GRAMS_PER_COMPUTE_BUDGET_UNIT (100) [covenant]Transient mass
transient_mass = size × TRANSIENT_BYTE_TO_MASS_FACTOR (4)Storage mass (KIPKaspa Improvement Proposal: the process that specifies, reviews, and merges a protocol change. Nothing on this site counts as shipped without a merged KIP and a release tag.-0009)
C = STORAGE_MASS_PARAMETER (1,000,000,000,000) utxo_plurality(output) = ceil((63 + script_bytes + 32 if covenant else 0) / 100) A P2PK-style output (script 34) has plurality 1. A covenant-carrying output (63 + 34 + 32 = 129 bytes) crosses the 100-byte unit and has plurality 2, which squares its weight below. storage_mass = max(0, outputs × plurality² × C / out_amount_sompi − inputs × C / in_amount_sompi) in_amount_sompi assumes no fee: total out value split evenly across inputs.Which dimension binds
Compute and storage share a 500,000 block-mass limit; transient's limit is 1,000,000, so it is normalized to the same scale before comparison: transient_norm = transient_mass × 500,000/1,000,000. tx_mass = max(compute_mass, storage_mass, transient_norm) tx_per_block = floor(500,000 / tx_mass) TPS = tx_per_block × 10 blocks/secondModels a standard shape with no fee; real TPS is lower once relay and mempool behavior apply. Verified against mass code, params, constants. Offline.
Where the payment numbers come from
Mainnet caps block mass at 500,000: 5,000,000 mass/second before fees. A plain payment costs roughly 1.6k mass, 2.0k with change: 250–300 per block, 2,450–3,070 per second (quoted 3.4k TPS at leaner shapes; payload ceiling about 25 KB). Toccata's transient mass rises to 1,000,000.
| 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. Little of that room goes to 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: 50 lanes/block, 1,000,000,000 gas/lane, worst-case 500 updates/second.
Two ledger models
Why parallel spends don't collide
An account balance is one number every payment takes a turn writing. A UTXO wallet holds separate coins, so nobody waits.
Same 1,650 KAS, same five payments, two ways of keeping the books.
Account model
1,650one balance, in KAS
UTXO model (Kaspa)
At ten blocks a second, the five payments can land in any order across five blocks. Separate coins make order irrelevant; one shared balance forces four to wait.
Which spend wins, and who decides
A wallet can sign two spends of one coin and broadcast both, but rusty-kaspa refuses any block that carries both, so the real race is between two blocks landing at once. GHOSTDAG orders every block first, then replays its spends against the unspent set: whichever spend lands earlier takes the coin, the later one fails, and every node reaches the same answer.
- Coin structure: rusty-kaspa,
consensus/core/src/tx.rs. An input names a whole prior output; an output carries a value and an optional covenant binding. - One block, one spend per coin: block body validation.
- Order first, replay after: the mergeset acceptance loop.
Covenants
A coin that can carry its own rule
That isolation cuts both ways. A Kaspa script reads only the spend it sits in, and cannot call another app's live state the way one contract calls another. Since Toccata activated at DAA score 474,165,565, a coin can instead carry its own rule, checked like a signature.
What Toccata turned on, KIP by KIP, and what it did not
A UTXO can require a matching next output: vaults, escrow, refunds.
Covenant IDs give state a tracked lineage, blocking fake lookalikes.
A script checks a chosen proof instead of L1 running every step.
Sequencing commitments let an app prove its lane, not the whole DAG.
Shared state many users mutate: still roadmap. See status.
Apps anchor state to Kaspa ordering, no separate sequencer.
No virtual machine, no accounts, no global state. Demo: build on Kaspa. KIP-17/20/16/21, Sutton.
Three rungs of app state, and which ones are live
So Kaspa's app layer is covenantsA rule attached to a coin, checked on every spend, governing how it moves., not an account-based virtual machine. Three rungs, only the first running:
| What it does | How far it reaches | Status |
|---|---|---|
| Covenants, covenant IDs, ZK proof checks | Rules the network enforces on the one spend being checked. | Live on mainnet since Toccata, at DAA score 474,165,565 |
| Two separately built apps in one transaction | Both apps are spent and remade together, so both land or neither does. | Demos only unaudited and offline, in Argent |
| Many users writing one app's state | An order book or a pool that everyone edits at once. | Roadmap vProgs, zero releases |
What each of the three rungs actually is, with the KIP behind it
KIP-17 lets a script check only the spend it sits in. KIP-20 adds covenant IDs, a lineage tag consensus tracks, so a covenant's record cannot be forged. KIP-16 checks a zero-knowledge proof inside a spend, without replaying the work. None reads another covenant's live state.
Argent's Inter-Covenant Communication joins two apps' state into one spend. Its README: "still under active development and is not yet release-ready."
vProgs targets many users mutating one app's state, the case the other two miss. Its README: "early development / prototype phase," zero releases, zero tags.
- KIP-17, KIP-20, KIP-16: all Active on the KIP tracker.
- Toccata activation: rusty-kaspa v2.0.0.
- argent-lang/argent, and what the compiler does.
- kaspanet/vprogs and Michael Sutton's design notes.
Live vs next
What's live, what's not
Four claims people repeat, checked against mainnet, with safer wording
| Claim | Status | Safer wording |
|---|---|---|
| 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. |
| 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. |
| Ten blocks a second means payments are final immediately | No | The block rate 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 claim fact-check.
Sources
Check it yourself
Kaspa Research carries the lineage; Rusty Kaspa is the code. Kaspa.com's Learn Kaspa has glossaries.
Watch the network: a live read of Kaspa's own public API, not a simulation
Real blocks, live from Kaspa's public API. Checks every 9s.
0
blocks racing for the same spot right now. Kaspa doesn't make them wait in line.
Measuring the network's real pace…
Reading the first blocks…
Checking every 9 seconds.
0%
of the blocks this page has watched this session carried nothing but the miner's own reward.
Kaspa's measured baseline: about 0.9 TPS, 88.3% of raw transaction count coinbase (site data, api.kaspa.org, 2026‑08‑22).
An empty block is not a fault; the network makes room for ten a second.
What this page shows, what it can't, and why
What this shows, and what it can't
tipHashes from api.kaspa.org/info/blockdag, every 9 seconds. Red: too late. Empty: only a coinbase. covenant: a verified covenantId. One API read per visit.
api.kaspa.org/info/blockdag (every 9s), api.kaspa.org/blocks/{blockId} (capped at 16). Baseline: data/l1-chains.json, 2026-08-22. Nothing stored or sent elsewhere.
params, mass code, Toccata guide, v2.0.0/v2.0.1, KIP-16/17/20/21, argent-lang/argent.