Ten blocks per second is a block rate, not a transaction rate. This page derives the transaction rate from it.
The arithmetic
A block is capped at 500,000 grams of compute mass, and the network produces ten blocks every second. Multiply:
5,000,000 grams per second of capacityAn ordinary payment - one input, two outputs, one signature - runs a little over 2,000 grams. Divide:
5,000,000 / 2,000 ≈ 2,500 transactions per secondThe ceiling is in the low thousands of transactions per second, on the base layer. No rollups, sidechains, sequencers, or bridges are involved.
The figure depends on the traffic mix. Multi-signature spends carry more compute mass and land fewer per second; a covenant call carries more still. Capacity is measured in grams, so the transactions-per-second figure is a consequence of the traffic mix rather than a constant.
Three per-block limits
Compute is the dimension that usually binds first, but every block is capped on all three at once:
| Dimension | Per-block limit | What it bounds in practice |
|---|---|---|
| Compute | 500,000 grams | Validation work. The binding constraint for ordinary payments. |
| Transient | 1,000,000 grams | Block body size - about 250 KB, since transient mass is serialized bytes × 4. |
| Storage | 500,000 grams | How fast the UTXO set can grow. |
A block fills up when any one of the three runs out. A block of dust-creating transactions exhausts storage long before compute; a block of large scripts exhausts compute long before size. Toccata doubled the transient limit specifically so that block body size would not be the binding constraint.
One further limit: a block may carry transactions from at most fifty non-native subnetwork lanes, each with its own gas ceiling. That bounds how much of a block any single specialized workload can claim, so a busy lane cannot crowd out ordinary payments.
Duplicates reduce useful throughput
The DAG can carry more transactions than the ledger will count.
A transaction may legitimately appear in several parallel blocks. It is accepted once - the second copy tries to spend coins that are already gone - so every duplicate is capacity that produced nothing. Raw block throughput and useful throughput differ by the amount of overlap between parallel blocks.
This is what the mempool’s weighted sampling exists to prevent. Miners building templates at the same instant draw different transactions rather than the same top-of-the-list ones, which keeps overlap low without any coordination between them.
The measure of how well that is working is effective TPS: a ratio of what the DAG delivered to what it could have delivered given the transactions available. A value of one means capacity is going to distinct transactions; zero means the DAG is carrying copies while unique transactions wait.
What the network actually does
Ceilings describe capacity, not demand. Real throughput tracks what people are sending, and mainnet has historically run far below its ceiling - which is the reason fees sit near the relay floor and inclusion takes about a second.
The live numbers are charted: average TPS, max TPS, and transaction count.
Why the ceiling is where it is
The limits above are not arbitrary. Each one is a bound on what a node must do to keep up in real time, and the binding constraint on all of them is that a Kaspa node has to run on ordinary hardware.
- Compute is bounded by validation speed. A node must fully validate ten blocks a second, forever, on consumer processors.
- Transient is bounded by bandwidth. Blocks have to reach the whole network within a fraction of a second, or GHOSTDAG starts coloring honest blocks red.
- Storage is bounded by memory. The UTXO set is the one thing pruning never discards, so its growth rate is a permanent commitment.
Raising any of them raises the cost of running a node. The limits are set to keep verification affordable on consumer hardware.
See Also: Blocks, The Crescendo Hard Fork