Every transaction pays the network to carry it. Kaspa collects the fee implicitly and prices it by mass rather than by size. This page explains both.
The fee is implicit
There is no fee field in a Kaspa transaction. The fee is the total input value minus the total output value:
fee = sum(inputs) - sum(outputs) Input value that does not appear in an output goes to the miner. A transaction that spends 10 KAS and creates 9.9997 KAS in outputs has paid 0.0003 KAS, without stating it in any field.
10 − 0.2 − 9.7997 = 0.0003 KAS. The fee exists only as the difference between the two columns.
This design is inherited from Bitcoin. The fee needs no field because it cannot be misstated: it is computed by summing both sides.
Mass, not bytes
Bitcoin prices a transaction by its size. Kaspa prices a transaction by the network resources it consumes, measured in a unit called a gram.
A transaction is measured on three resource dimensions:
| Dimension | What it measures | Per-block limit |
|---|---|---|
| Compute | Work the node must do to validate - serialized size, output scripts, and the cost of the script execution each input requires. | 500,000 grams |
| Transient | Bandwidth and short-lived memory. Serialized size × 4. | 1,000,000 grams |
| Storage | Growth of the UTXO set - state every node must hold indefinitely. | 500,000 grams |
Size still contributes, since it feeds two of the three dimensions. But size alone cannot identify a transaction that splits one coin into a thousand small ones, which is the kind of transaction that costs the network most.
The heaviest dimension sets the fee
A transaction’s fee is set by its heaviest dimension. The other two dimensions add nothing.
The mempool normalizes the three against their block limits so they can be compared on one scale, then prices the largest. A transaction that is heavy on storage but trivial on compute pays for the storage; padding it with script work up to that same level costs nothing extra. Only the relay floor is narrower - it applies to compute and transient mass alone, because storage growth is already capped by the block limit.
In practice, reducing the byte size of a transaction does not reduce its fee when its cost is dominated by the outputs it creates.
Storage mass protects the UTXO set
The UTXO set is the one thing pruning never discards, so it is the one resource that spam could grow permanently. KIP-9 prices that growth directly.
Storage mass compares the coins a transaction creates against the coins it consumes, using a large constant of one trillion:
storage mass = max(0, C × (|outputs| / H(outputs) − |inputs| / A(inputs))) The choice of averages drives the behavior. The output side uses a harmonic mean, which is dominated by the smallest value present, so one tiny output raises the whole term. The input side uses an arithmetic mean. The consequences:
- Splitting is expensive. Turning one coin into many small ones - especially dust - carries heavy storage mass, and the smaller the pieces the higher the cost.
- Merging is free. Consolidating many coins into one produces no storage mass, because the formula floors at zero. Consolidating a wallet’s coins costs nothing beyond the compute mass.
- A normal payment is barely affected. One or two inputs and two outputs of ordinary size land near zero on this dimension.
Kaspa has no dust limit. Bitcoin forbids tiny outputs by policy; Kaspa permits them and prices them by their cost to the network. The effect is visible in the UTXO count: the set grows with usage rather than with spam.
What a payment costs
The expected fee is a rate times a mass:
fee = fee rate × mass Fee rate is in sompi per gram, and the minimum a node will relay is 100 sompi per gram - raised from 1 at Toccata.
An ordinary one-input, two-output payment runs a few thousand grams. At the floor that is a fee in the low hundreds of thousands of sompi - a few thousandths of a single KAS. Live averages and medians are charted at average transaction fee and median transaction fee.
Nodes publish suggested rates in three buckets, each an estimate of what it takes to be included within a given window:
| Bucket | Targets inclusion within |
|---|---|
| Priority | under a second |
| Normal | under a minute |
| Low | under an hour |
These rates are derived from what is waiting in the mempool, not from a fixed schedule. When nothing is queued, all three converge toward the floor. Paying above the floor only affects inclusion time when there is a queue.
See Also: The Mempool, Throughput