> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Mempool
> How transactions are admitted, held, ordered, and disseminated before consensus commits them to a block.
The mempool is what stands between a signed transaction and a committed block. It decides what is worth holding, in what order a sender's transactions become eligible, which peers hear about a transaction, and what gets dropped when demand exceeds capacity.
For a trading network this is load-bearing rather than incidental. Order and cancel traffic is bursty, sender-concentrated, and latency-sensitive in an asymmetric way: a cancel that arrives late is worse than an order that arrives late. The structures below exist because a single FIFO queue handles none of that well.
## The path in
Signed transaction
Validationsignature · format · account state · can the sender pay for it
Dropped, with a reason returnednot silently — the submitter is told why
Transaction store
Peer broadcast
Batch formation, then consensus
Validation is cheap and local, so the expensive resources downstream are spent only on transactions that could actually execute.
rejected
accepted
A transaction is validated before it is ever stored. Validation is cheap and local — signature, format, account state, and whether the sender can pay for what they are asking — and it exists so that the expensive resources downstream are spent only on transactions that could actually execute. A rejection here returns a reason to the submitter rather than silently disappearing.
## How transactions are held
Accepted transactions are not kept as one flat queue. The store maintains several views over the same set, each answering a different question.
One set of accepted transactionsfive views over it, not five queues
Per-account orderingFor this sender, which transaction is next?
Priority indexAcross all senders, what should consensus be offered first?
Expiry indexWhat has passed its deadline?
Timeline indexWhat has this peer not heard about yet?
Parking lotWhat is well-formed but not yet eligible?
The parking lot is where an integration bug becomes visible: a transaction that is valid but not yet next for its sender is parked, not rejected — it becomes eligible the moment the gap in front of it closes.
| View | Question it answers |
| ------------------------ | -------------------------------------------------------------- |
| **Per-account ordering** | For this sender, which transaction is next? |
| **Priority index** | Across all senders, what should be offered to consensus first? |
| **Expiry index** | What has passed its deadline and should be removed? |
| **Timeline index** | What has this peer not heard about yet? |
| **Parking lot** | What is well-formed but not yet eligible? |
The **parking lot** deserves the most attention because it is where a class of integration bug becomes visible. A transaction can be perfectly valid and still not be next in line for its sender — most often because an earlier transaction from the same account has not arrived or has not been committed. Such a transaction is parked rather than rejected: it stays available, and becomes eligible the moment the gap in front of it closes. A client that submits out of order therefore experiences a delay rather than a failure, but a client that never fills the gap leaves work parked until it expires.
The **timeline index** is what makes peer dissemination incremental. Each peer is tracked by how far along the timeline it has been served, so a broadcast sends what that peer is missing rather than re-sending the pool. The timeline is bucketed rather than single-file, which keeps one heavy sender from monopolizing every broadcast slot.
## Dissemination and fairness
Nodes do not each learn about transactions independently. A node that accepts a transaction broadcasts it to peers, and peers are not treated identically — upstream peers are prioritized so a transaction moves toward the validators that can act on it rather than diffusing evenly across the network.
Fairness is tracked over recent history rather than enforced per message. The mempool keeps a rolling record of which senders and which kinds of traffic have recently consumed capacity, and uses it to shape what gets served next. This is the mechanism that keeps one account's order-and-cancel storm from crowding out the rest of the network, without needing a hard per-account rate limit that would penalize legitimate market making.
## Handoff to consensus
Consensus does not take transactions from the mempool one at a time. Transactions are gathered into **batches**, batches are disseminated to validators in the background, and each batch is acknowledged until its originator can prove that enough of the network holds it. Only then can a block proposal reference it.
The consequence is that a block proposal carries batch digests rather than transaction bodies, so consensus message size stays flat as throughput rises — and a committed block is always replayable, because the data behind it was proven available before it was referenced. See [IntentionBFT](/protocol/architecture/intention-bft) for how that proof is formed and used.
This is also why mempool admission is not the same as inclusion. A transaction that is accepted, stored, and broadcast has entered the queue; it has not been ordered. Nothing about a transaction's fate is settled until consensus commits the block that contains it.
## What this means for a client
* **A rejection at submission is informative.** It happened before the transaction was stored, and the reason describes something the client can fix.
* **Silence is not rejection.** A transaction may be parked behind a gap of the client's own making. Track what has been submitted and what has committed rather than assuming a missing acknowledgement means a drop.
* **Order within an account matters; order across accounts does not.** Two transactions from one sender have a defined sequence. Two transactions from different senders are ordered by consensus, not by who submitted first.
* **Cancels are not privileged in the mempool.** Cancellation priority is a property of [kernel execution](/protocol/architecture/kernel), where cancels run before aggressive placements in the same block — not of queueing.