How Kaspa Pool Payouts Actually Work (And Why Some Pools Fail Them)

A Kaspa pool payout is not just "send everyone their KAS." The pool accrues each miner's share of found blocks, waits until a miner clears the minimum payout, batches many miners into a single Kaspa transaction, then broadcasts it and waits for confirmation. The hard part is the batching: Kaspa enforces a transaction "mass" that a naive pool can blow past, and when it does the network rejects the transaction and the payout silently fails. A correct pool computes mass before it signs anything. This article walks the full lifecycle and shows exactly where pools break.

What happens between a found block and KAS in your wallet?

Every payout system runs the same four stages, whether or not the operator admits it:

• Accrual. When the pool finds a block, the reward is split across miners in proportion to the work they submitted. Your balance is an off-chain ledger entry that grows block by block — nothing is on-chain yet.
• Threshold. Sending KAS costs a fee and consumes block space, so pools don't pay micro-amounts every block. They wait until your balance clears a minimum payout. Kat Pool's minimum is 10 KAS, lower than the 50–100 KAS thresholds common elsewhere.
• Batching. Once a cycle runs, every eligible miner becomes one output in a shared transaction, funded by the pool treasury's unspent outputs (UTXOs) as inputs. Batching is what makes payouts cheap — and it is also where things go wrong.
• Broadcast and confirmation. The signed transaction is submitted to a Kaspa node, accepted into the mempool, included in a block, and then confirmed. Only after confirmation is the on-chain balance real.

What is transaction mass on Kaspa?

Bitcoin limits transactions by byte size. Kaspa instead uses mass, measured in grams, to bound how much of a scarce node resource a transaction consumes. Since the Crescendo hardfork (mainnet 2025-05-05, which also activated the sampled-window difficulty adjustment), a Kaspa transaction has three independent masses:

• Compute mass — the computational cost of verifying the transaction (signature operations and script work).
• Storage mass (KIP-9) — the cost of the persistent state the transaction leaves behind. Its formula, max(0, C · (|O|/H(O) − |I|/A(I))), uses the harmonic mean of the output values, which makes it extremely sensitive to small outputs.
• Transient storage mass (KIP-13) — a direct bound on serialized size, defined simply as serialized_size(tx) × 4.

These are tracked separately, not summed. A block sums each mass across all its transactions independently, and each total must stay under the block mass limit of 500,000 grams. In practice the binding constraint for a payout is even tighter: the mempool refuses to relay any transaction whose mass exceeds the standard-transaction limit of 100,000 grams, so a payout transaction must respect that bound to be broadcast at all.

Why does naive batching cause real payout failures?

The KIP-9 storage-mass formula exists specifically to punish "dust fanout" — taking a few inputs and splitting them into many small outputs, which is exactly the shape of a pool payout. The behavior is sharp:

• Outputs above 100 KAS each: storage mass is effectively zero; output count is unconstrained.
• Outputs above 10 KAS each: roughly 100 outputs reach the 100,000-gram mark.
• Outputs above 1 KAS each: only about 10 outputs before you hit the limit.
• Any output below ~0.019 KAS is rejected outright — an absolute dust floor, regardless of how the rest of the transaction looks.
• Combining UTXOs or 1:1 transfers (outputs ≤ inputs) are essentially free, mass-wise. The rule of thumb: keep outputs at no more than about 10× the number of inputs.

So a pool that simply stuffs, say, 35 miners into one transaction and hopes will work fine until the treasury's UTXO distribution shifts — then the same code produces a transaction the network rejects with storage mass exceeds maximum. The miners were never paid, but nothing in the pool's happy path noticed. That is the difference between a payout that is late and a payout that silently never happened.

How does a mass-aware planner prevent silent failures?

The fix is to treat mass as a hard constraint computed before signing, not a surprise discovered at broadcast. Kat Pool's payout planner does exactly this: for every candidate batch it computes all three masses using the same consensus rules a Kaspa node runs, and rejects any plan where a component would exceed the limit. Concretely:

• The planner selects inputs and groups recipients so that each transaction fits all three masses independently. If a batch would not fit, it is split.
• If an individual recipient's payout would create a sub-floor output (below ~0.019 KAS), that recipient is held until the next cycle rather than poisoning the whole transaction.
• Planning and execution are separate layers. The planner works against a UTXO snapshot, but before each transaction is signed the executor re-fetches the live treasury UTXO set, re-checks mass, and aborts the cycle on any mismatch rather than guessing.
• A background job consolidates the treasury when it drifts toward many small UTXOs, keeping the input side mass-efficient so future batches stay large and cheap.

Because the planner can't produce an unminable transaction, a payout is either broadcast valid or deferred with a reason — never sent into the void.

Why does open source make payouts more reliable?

Mass-aware planning is only trustworthy if you can verify it. Kat Pool is fully open source, so the storage-mass crate, the planner, and the executor are all inspectable — down to the property tests that check the pool's mass computation against the reference implementation in rusty-kaspa for random input and output sets. A closed pool can claim its payouts are reliable; an open one lets you read the code that makes them so. You can learn more about the project on the about page.

The takeaway

Pool payouts on Kaspa live or die on transaction mass. Accrual and thresholds are the easy part; the engineering is in building batches the network will actually accept. A pool that computes compute, storage, and transient mass before signing — and holds dust outputs instead of breaking a whole batch — pays reliably. One that batches blindly fails silently. If you're deciding where to point your hashrate, weigh this alongside the other factors in how to choose a Kaspa mining pool, read the full Kaspa mining guide, and see what changes when you switch from a closed pool in the Kat Pool vs HumPool comparison.