The Mempool | Kaspalytics

Between submission and inclusion in a block, a transaction waits in the mempool. Kaspa’s mempool differs from Bitcoin’s in how miners select from it.

Every node keeps its own

The mempool is not part of consensus. It is one node’s local view of what should be mined next, and nodes are not required to agree.

A node holds a transaction only if it validated against the current UTXO set, cleared the relay fee floor, and looks standard. Default capacity is large - up to a million transactions, or a gigabyte, whichever comes first - so on a healthy network the pool is nearly empty and everything submitted is mined within a second or so. The mempool’s behavior only matters when demand exceeds what ten blocks per second can carry.

Transactions inside it split into two groups: those whose inputs are all already settled on the network, and those spending outputs of other transactions still waiting. Only the first group is eligible for the next block, and miners draw from it.

How miners choose

One way to fill a block is greedy selection: sort by fee rate and take from the top until the block is full. Bitcoin does roughly this, and it works because a block is found every ten minutes and effectively one miner is building at a time.

At ten blocks per second, that approach breaks. Blocks are assembled in parallel across the whole network, constantly. If every miner sorted the same mempool the same way, every parallel block would contain the same transactions - and since a transaction can only be accepted once, every copy past the first is wasted capacity.

Kaspa instead samples at random, weighted by fee rate cubed.

Higher fee rates still win - cubing the weight means a transaction paying twice the rate is eight times as likely to be drawn.
Two miners building at the same moment draw different transactions, because each draw is independent. Parallel blocks fill with different transactions.
Parallel block production therefore adds throughput rather than duplicating it.

Sampling only applies when there is something to choose between. If less than a block’s worth is waiting, the miner takes all of it - the ordinary state of the network. The weighting applies once a queue forms.

Orphans

A node can be handed a transaction whose inputs name coins it has never heard of - usually because the parent transaction is a fraction of a second behind it in the gossip.

Rather than reject it outright, the node parks it in a small orphan pool: a few hundred transactions, held about a minute. If the parent arrives, the orphan is promoted into the mempool proper. If not, it is dropped. The pool is deliberately small, because holding transactions that reference unknown coins is a resource an attacker could otherwise exhaust.

Replacing a transaction

A transaction already in the mempool can be displaced by a conflicting one, but the requirements are strict.

The replacement must spend at least one of the same coins, and it must pay a strictly higher fee rate than what it is displacing. If both conditions are met, the original is evicted; otherwise the replacement is rejected and the original stays. Nodes expose this as a distinct submission call, so replacement is always something a wallet requested rather than something that happened by accident.

Replacement does not cancel a payment. The original transaction is only gone from the mempools that accepted the replacement, and the replacement is itself a payment that will be mined. Replacing a transaction means paying more to move the same coins - possibly back to the sender - not undoing the spend.

How a transaction leaves

A transaction leaves the mempool in one of four ways:

Mined and accepted. The normal case. The node clears it once it sees the transaction in a block that made it into the ordering.
Replaced. A conflicting transaction paid a higher fee rate.
Expired. Anything still waiting after 24 hours is dropped. Its coins were never spent, so the wallet can simply build a new transaction.
Evicted. Under sustained pressure the pool sheds its lowest-value transactions to stay within its limits.

None of these affect the ledger. A transaction that is never mined has no effect, which is why the mempool can be a matter of local policy.

Inspecting the mempool

A node exposes its mempool through RPC: getMempoolEntries lists everything it currently holds, getMempoolEntriesByAddresses filters by address, and getMempoolEntry returns one transaction.

These calls describe one node. For a network-level view of how much capacity goes to distinct transactions rather than duplicates, see effective TPS.