How Kaspa Fees Work — From UTXO Count to Covenant Budget Caps

Kaspa's fee model is simpler than most proof-of-work chains: instead of charging by transaction weight or virtual bytes, the default wallet fee is a flat amount per UTXO consumed. That simplicity has consequences — some welcome (predictable costs for sweeps), some less obvious (why on-chain covenant contracts need a feeBudget parameter, and what happens to a transaction after you broadcast it).

This article walks through the full lifecycle: how fees are calculated, what the mempool does with pending transactions, how miners decide what to include, and how covenant scripts guard against fee-based griefing.

The Fee Formula: Per-UTXO, Not Per-Byte

On Bitcoin, transaction fees depend on the *weight* of the serialized transaction — more inputs, more outputs, and more complex scripts all add weight, and you pay per virtual byte. The result is that a transaction spending 50 small UTXOs costs significantly more than one spending a single large UTXO, even if the value transferred is identical.

Kaspa takes a different approach. The documented default wallet fee is 0.0001 KAS (100,000 sompi) per UTXO utilized in the transaction. If your transaction consumes 3 UTXOs as inputs, the default fee is 0.0003 KAS. The number of outputs does not directly increase the fee — only inputs do.

This per-UTXO model has a practical upside for self-custody tools: a sweep that consolidates 20 dusty UTXOs into one address costs proportionally, but you do not need to estimate a complex weight formula. The cost scales linearly and predictably.

An important caveat: the 100,000 sompi figure is a wallet default, not a consensus-enforced minimum. The wallet software decides how much fee to attach. A transaction with zero fee is technically valid at the consensus level — a miner *could* include it in a block, and every other node would accept that block.

Wallets, Nodes, and the Anti-Spam Floor

If anyone can set an arbitrarily low fee, what prevents spam?

The answer is a node-level minimum relay fee. Each Kaspa node filters transactions below a configurable threshold from its mempool and does not relay them to peers. This is anti-spam policy, not consensus: the threshold can be changed via command-line flag without any risk of chain split. As the Kaspa wiki notes, a coordinated network-wide update can lower or raise it as needed — "it'll be enough if most users will upgrade in order to work."

The distinction matters:

• Below the relay minimum: your transaction is filtered by nodes, does not propagate, and never reaches a miner.
• Above the relay minimum but below what miners prefer: the transaction enters mempools, but miners filling a block will select higher-paying transactions first. Your transaction may sit in the mempool until there is spare capacity.
• Included in a block at any fee: once a miner puts the transaction in a valid block, every node accepts it regardless of the fee amount.

There have been academic discussions about implementing miner-driven minimum fees (where miners signal the minimum they will accept), but no such system is live on Kaspa mainnet today.

The Mempool: Two Lifetimes for Pending Transactions

Not all transactions enter the mempool the same way, and the rules for expiration differ depending on the source:

To manually drop a locally-submitted transaction from the mempool, you must restart the node.

At Kaspa's current block rate of 10 blocks per second, 60 blocks pass in roughly 6 seconds. This means peer-relayed transactions have a very short window to be mined before they are dropped from remote mempools. Transactions submitted through your own node persist indefinitely — which is why service operators run their own node infrastructure and submit transactions via gRPC directly, rather than relying on peer relay. We covered why we run our own Kaspa node in a previous article; the mempool behavior described here is one of the concrete reasons.

How Miners Select Transactions

When a miner builds a block, the process is straightforward: if the mempool has more transactions than fit in a block, the miner selects the top-paying transactions first. The minimum relay fee only determines whether a transaction enters the mempool — it does not guarantee timely inclusion.

Because Kaspa processes 10 blocks per second, the effective block space is large. At current transaction volumes, fee pressure is low: most transactions confirm within seconds regardless of fee amount. The fee today primarily functions as an anti-spam measure, not a competitive bidding market.

The Kaspa community has discussed fee market designs for scenarios where demand exceeds throughput. These remain theoretical — the current system is a flat per-UTXO default with a node-level relay minimum.

Covenant Fee Guards: Why feeBudget Exists

This is where Kaspa's covenant layer (introduced on mainnet with the Toccata fork) intersects with fee mechanics in a non-obvious way.

Some covenant spending paths are keyless — they require no signature and can be broadcast by *anyone*. Examples from the two main Kaspa Forge contracts:

• complete in a vault: after the withdrawal delay expires, anyone can broadcast the transaction that releases funds to the destination.
• autoRelease in escrow: after the dispute window closes without a dispute, anyone can release funds to the seller.
• inheritAuto in a vault: after the inheritance delay expires with no check-in, funds go to the heir.
• timeoutToBuyer / timeoutToSeller in escrow: if the arbiter deadline passes, the timeout fires without any signature.

These keyless paths are a feature — they ensure the contract resolves even if one party disappears. But they introduce a griefing vector: since *anyone* can broadcast the transaction, an attacker (or a buggy watcher) could set an inflated network fee, causing the miner to extract most of the UTXO's value as fee while the legitimate recipient gets almost nothing.

The solution is the feeBudget parameter, baked into the covenant script:

int constant MAX_FEE_BUDGET = 10_000_000   // 0.1 KAS

require(feeBudget > 0 && feeBudget <= MAX_FEE_BUDGET)
// ... in each keyless path:
require(tx.fee <= feeBudget)

This caps the maximum network fee any keyless path can spend. In the vault covenant (vault.sil), 6 of 7 paths enforce this check. The one exception is migrate, which requires both the hot key and the alarm key — since both owner signatures are needed, the owner controls the fee directly and no cap is necessary.

In the escrow covenant (escrow.sil), all 10 spending paths enforce the fee budget. The cap of 0.1 KAS (10,000,000 sompi) is generous enough for any normal network fee but small enough to prevent meaningful value extraction through fee manipulation.

This connects to the single-input invariant: every covenant path requires tx.inputs.length == 1, meaning each transaction spends exactly one vault or escrow UTXO. The feeBudget therefore applies to that single UTXO — there is no way to aggregate multiple covenant UTXOs and redirect the surplus as fee.

How Kaspa Forge Handles Fees in Production

Kaspa Forge's architecture treats network fees as a first-class concern at every layer:

Fee estimation. The backend exposes a GET fee-estimate endpoint that proxies current network fee data from the node. The browser client uses this to set appropriate fees when building transactions in the vault creation wizard or escrow deals.

feeBudget binding. When a user creates a vault or escrow deal, the off-chain bindings (the code between the browser UI and the WASM core) gate the feeBudget to a safe range — currently between 1,000,000 and 10,000,000 sompi (0.01 to 0.1 KAS). This prevents both the user and the interface from setting a dangerously high budget.

Watcher-broadcast keyless paths. The Kaspa Safe watcher service monitors vault UTXOs and can broadcast keyless paths like complete, inheritAuto, and autoRelease on behalf of the owner. Because the covenant enforces feeBudget, even a compromised or buggy watcher cannot drain the vault through excessive fees. The watcher is a convenience layer — the contract is the trust boundary.

Service fees vs. network fees. In Kaspa Escrow, the resolve fee (0.5%, minimum 1.2 KAS) and dispute fee (2%, minimum 5 KAS) are separate from network fees. They are enforced as dedicated output entries in the covenant transaction — the script requires a specific output paying the service's fee address. The feeBudget governs only the network fee (what the miner collects), not the service fee.