About 250 to 300 simple payment transactions per block at 10 BPS.
Capacity question
Kaspa TPS, explained by workload
There is no single Kaspa TPS number. For ordinary simple L1 payment transfers, the current mainnet estimate is roughly 2,500 to 3,400 transactions per second at 10 BPS, depending on transaction shape. That range does not carry over to covenant apps, ZK settlements, token rules, or future vProg-style systems.
Status checked June 27, 2026: Kaspa mainnet is the Crescendo-era 10 BPS network. Toccata is released and scheduled for DAA 474,165,565, but mainnet was still below that activation score during this check.
Direct answer
Ask "TPS of what?"
| Workload | Answer | Why the number changes |
|---|---|---|
| Simple L1 payments | Roughly 2.5k to 3.4k TPS for ordinary simple transfers. | This comes from 10 BPS, block-mass limits, and simple transaction mass. App metrics need workload-specific assumptions. |
| Covenant or programmable L1 transactions | Workload-specific. L1 transaction-per-second capacity can be lower than simple-payment TPS. | Covenants add script work, state constraints, covenant identifiers, output rules, inputs, outputs, fees, and storage effects. |
| ZK proof or settlement transactions | Usually fewer, heavier L1 transactions. One proof or settlement transaction can represent many off-chain app actions. | Capacity depends on proof system, proof size, verification cost, batch size, proving time, and settlement design. |
| Effective ZK app or future vProg throughput | App-specific. It can exceed raw L1 transaction TPS for a given app design. | The metric becomes app actions per proof batch or per settlement cycle, with state access and prover work as the real limits. |
Simple payments
Current simple-payment capacity
Kaspa mainnet currently produces roughly ten blocks per second. In the current mainnet parameters, the shared block mass limit is 500,000. That gives a rough budget of 5,000,000 transaction mass per second before policy, fees, propagation, storage shape, and real mempool behavior enter the discussion.
A signed ordinary P2PK-style 1-input, 1-output payment is roughly 1.6k mass in conservative code-based arithmetic. A 1-input, 2-output payment with change is closer to 2.0k mass. Divide the block budget by those shapes and the mental model lands around 250 to 300 simple transactions per block, or the mid-2k to low-3k TPS lane at 10 BPS. Leaner simple shapes and rounding explain why the upper end is often stated around 3.4k TPS.
For current simple payments, use roughly 2.5k to 3.4k TPS and state the assumption: transaction shape plus block mass. Artificial minimum-transaction ceilings can be higher, but they describe lab envelopes better than ordinary payment throughput.
That mental model applies to simple payments. It does not describe covenant apps, proof settlements, or token state machines.
Transaction shape, inputs, outputs, scripts, payload, fee policy, and whether the number is capacity, demand, or a lab result.
Mass model
Simple tx/block stops at payments
Kaspa capacity is constrained by transaction mass. A simple count of transaction envelopes hides the real limit. The implementation charges for serialized bytes, script-public-key bytes, signature-operation or compute-budget work, transient byte mass, and storage mass effects. Larger transactions consume more of the block budget.
Apps change the footprint. A transaction carrying more inputs, more outputs, larger scripts, covenant metadata, payload data, proof bytes, or state-transition evidence can crowd out simple transfers. Node-side repeated work also changes the ceiling: validation cost, propagation size, UTXO access patterns, storage effects, and app-specific indexing.
Payloads are bounded too. The Kaspa docs describe a payload ceiling around 25 KB when payload data dominates a standard transaction, because the standard transaction mass ceiling and transient byte accounting still apply. App data consumes block capacity.
Toccata
What Toccata changes
Toccata is mainly a programmability upgrade. It changes what Kaspa L1 transactions can express and verify: covenant-style spending rules, covenant IDs, ZK verifier infrastructure, sequencing-commitment access, and the first base-layer foundations for based-ZK apps. Treat TPS claims as workload-specific.
The Toccata guide and current params show one throughput-relevant change: transient mass rises from 500,000 to 1,000,000 after activation, while the compute and storage reference limit remains 500,000. The guide frames this around fitting STARK-sized proofs. Ordinary payment-throughput claims need separate payment-specific assumptions. Toccata also adds v1 transaction fields such as output covenant data and input compute commitments, and it raises the standard minimum relay fee after activation.
| Piece | What it adds | TPS implication |
|---|---|---|
| KIP-17 covenants | Transaction introspection, byte operations, hashing tools, signature checks from stack, and script tools for stateful UTXO rules. | More expressive transactions can be heavier than simple payments. |
| KIP-20 covenant IDs | Stable covenant lineage through a 32-byte covenant identifier and authorizing input binding. | Supports asset rules and state machines, with extra metadata and validation work. |
| KIP-16 ZK precompile | OpZkPrecompile for proof verification paths such as Groth16 and RISC0-Succinct. | Proof transactions use L1 capacity differently from payment transfers. |
| KIP-21 sequencing commitments | Partitioned lane commitments so app proving can track app activity instead of the entire DAG. | Important for app proving costs; not an end-user TPS number. |
Covenants and assets
Programmable transactions consume capacity differently
A covenant transaction is a transaction with rules about how its coins or state can be spent next. That supports vaults, escrow, assurance contracts, controlled assets, and token-like rules. It also means the L1 transaction can carry more structure than a simple payment.
A token transfer may look like one user action in a wallet, but the L1 footprint depends on the asset rule. The transaction might need covenant state, covenant IDs, authorization rules, extra outputs, witness data, app payloads, or indexer-readable state. Counting that as one ordinary payment transaction hides the capacity cost.
Simple-payment TPS is a payment metric. Covenant-app throughput must be measured by the actual transaction shape and state pattern.
ZK proofs
ZK changes the metric
ZK proof systems can move app execution away from the base layer while keeping a compact verification path on L1. A proof or settlement transaction can update an app commitment after many off-chain actions. In that design, the L1 transaction count may be small while the app action count is large.
That does not make TPS unlimited. Effective app throughput depends on the app, proof system, batch size, proof size, proving hardware, proof-generation time, data availability, settlement cadence, exit rules, and bridge/oracle assumptions. A ZK proof proves a statement about chosen inputs. External facts still need anchors such as a light client, finality certificate, accumulated-work view, reporter set, oracle, or challenge process.
The better metric for a ZK app is usually app actions per settlement cycle, with L1 proof verification as one bottleneck. That metric can be far above L1 transaction TPS for one app, yet still bounded by proof economics and state design.
vProgs
vProgs remain roadmap architecture
Toccata gives Kaspa pieces that vProg-style systems need: covenants, proof checks, covenant IDs, and partitioned sequencing commitments. Full vProgs are still a later architecture for app programs that prove richer logic while sharing Kaspa ordering.
KIP-21 avoids making every prover follow the entire DAG for every app. The partitioned commitment design targets O(activity) proving: a prover for one app lane follows that lane's activity instead of total network activity. Current parameters also bound user-lane churn with 50 non-coinbase lanes per block and 1,000,000,000 gas per lane. At 10 BPS, that is a worst-case 500 user-lane updates per second bound. User transaction throughput needs separate transaction-shape assumptions.
The public kaspanet/vprogs repository shows the implementation direction: resource access, scheduling, batches, state diffs, transaction runtime, L1, and ZK components. Michael Sutton's Argent repo is related tooling research for composing multi-contract covenant apps into Silverscript. Those repos are not mainnet activation evidence for full vProgs.
Checklist
How to discuss Kaspa capacity
Say whether the number is for simple payments, covenant spends, token rules, proof settlements, or app actions.
List inputs, outputs, scripts, payload, covenant fields, proof bytes, and storage effects.
State BPS, block-mass limits, standardness limits, fee policy, and mainnet versus testnet context.
For ZK and vProg-style systems, state batch size, proving cost, settlement cadence, state access, and exit design.
Bottom line: use roughly 2.5k to 3.4k TPS only for current simple L1 payment transfers. For Toccata apps, covenants, ZK proofs, tokens, and vProgs, the correct first question is "TPS of what?"