Between a wallet pressing send and a miner including the transaction, it has to live somewhere. That somewhere is the mempool, and Kaspa’s works differently from the one Bitcoin taught everyone to expect.
Every node keeps its own
The mempool is not part of consensus. It is one node’s private opinion about what should be mined next, and no two nodes are obliged 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 only becomes interesting when demand exceeds what ten blocks a 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. That eligible group is what miners actually draw from.
How miners choose
Here is the part that is genuinely Kaspa’s own.
The obvious way to fill a block is greedily: sort by fee rate, take from the top until the block is full. Bitcoin does roughly this and it works fine, because a block is found every ten minutes and essentially one miner is building at a time.
At ten blocks a second, that approach breaks. Blocks are being 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, all those copies past the first are capacity spent on nothing. The DAG would be busy and the network would be slow.
So Kaspa does not sort. It samples, at random, weighted by fee rate cubed.
- Higher fee rates still win, decisively - cubing the weight means a transaction paying twice the rate is eight times as likely to be drawn.
- But two miners building at the same moment draw different transactions, because each draw is independent. Parallel blocks fill with different cargo instead of the same cargo.
- The result is that parallel block production adds throughput rather than duplicating it. Sampling is what converts ten blocks a second into ten blocks a second of distinct work.
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 and the question does not arise - which is the ordinary state of the network. The weighting is what happens the moment a queue forms, which is exactly when the choice starts to matter.
It is a small algorithmic choice with the whole throughput story hanging off it. Randomness here is not a compromise; it is the mechanism.
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 nothing is exactly the resource an attacker would like a node to spend.
Replacing a transaction
A transaction already in the mempool can be displaced by a conflicting one, but the terms 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. Meet that and the original is evicted; miss it and the replacement is rejected and the original stays. Nodes expose this as a distinct submission call, so replacement is always something a wallet asked for rather than something that happened by accident.
This is not a cancel button. The original transaction is only gone from the mempools that accepted the replacement, and the replacement is a real payment that will be mined. Displacing a transaction means paying more to move the same coins somewhere - possibly back to yourself - not undoing the spend.
How a transaction leaves
Four exits, and only one of them is the good one:
- 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 touch the ledger. A transaction that never leaves the mempool never happened, which is the reason the mempool can be a matter of local policy in the first place.
Watching it
The mempool is visible through a node’s own interface: it will list everything it currently holds, and everything it holds for a given address. Those calls are getMempoolEntries, getMempoolEntriesByAddresses, and getMempoolEntry.
Answers there describe that one node. For a network-level view of whether capacity is being spent on distinct work or on duplicates, the measure is effective TPS.
See Also: Fees & Mass, Throughput