The Transaction Pool: A Queue and a Hash Set, Which Is the Right Answer When There Is Nothing to Prioritise

What a pool is for

A transaction arrives before there is a block to put it in. Something has to hold it.

And on most chains that something carries the policy: which transaction goes first, what happens when the pool is full, whether a sender can replace one already waiting. The pool is where a chain's economics show up as code.

What ours is

A queue and a hash set, in about two hundred lines.

first in, first out, with no reordering of any kind deduplicated by transaction hash, so the same transaction cannot be queued twice capacity ten thousand, and a full pool rejects rather than evicting drained from the front, and a drained transaction is forgotten so it can be resubmitted

The signature is checked at the door. A transaction whose signature does not verify is refused by the submission handler and never enters the pool.

Why first-in-first-out is the right answer here, not the lazy one

On a chain with a fee market, ordering by fee is the whole point of a pool. Senders bid, the pool sorts, the block takes the top.

This chain has no fee market. Every operation type has one flat price, so two waiting transactions of the same kind are indistinguishable and two of different kinds are not competing.

A priority queue with nothing to prioritise is worse than a queue: it would add ordering machinery, an attack surface for gaming it, and no benefit. The pool matches the fee design, and both were chosen rather than defaulted into.

It does not know about nonces, and that has a visible consequence

A pool on many chains holds a transaction whose counter is not yet due, waiting for the one before it.

This one does not look at counters at all. So submitting two transactions from one account in the wrong order does not queue the second behind the first: it goes into the next block and fails the counter check there.

That failure is free, because the counter check happens before the fee is taken. But the transaction is gone and must be sent again, and a caller that assumed the pool would wait will be surprised.

Full means refused, and in-memory means forgotten

When the pool is full the new transaction is rejected, rather than something being evicted to make room. With nothing to rank, that is the honest policy: evicting would mean choosing a victim on no basis at all.

And the pool is memory only. A restart of the node empties it, and anything submitted but not yet included is lost rather than replayed.

And submitting wakes the chain, which is the part that makes this workable

This chain proposes on events rather than on a clock, and when nothing is happening it emits one block every ten minutes.

So the submission handler explicitly wakes the consensus loop, and the comment says exactly why: proposing is event-driven and there is no free-running cycle to pick the transaction up.

A lost wake is bounded. If every loop is mid-iteration the notification is dropped, and each loop re-checks the pool on its next pass, which is a short fixed interval rather than the ten-minute heartbeat.

And here is what this still does not settle

An earlier page asked whether a client waiting about ten seconds for a receipt is waiting long enough on an idle chain.

Half of that is now answered: the transaction's own block is proposed immediately, because the submission wakes the proposer.

The other half is not. Finality needs two further rounds, and whether one wake produces them promptly or leaves the block waiting for the next heartbeats has not been tested end to end, because testing it means writing to the chain rather than reading it. It is filed, and it is still open.

What you can check yourself

submit the same transaction twice

The second is refused as a duplicate, which is the dedup set doing its job.