Transaction Queue - Wiki Parity Ethereum Documentation

Parity Ethereum client is listening to the network for transactions to include in blocks (if mining/validating) or to broadcast. These transactions emitted locally or externally are verified and ordered in a transaction queue. This document aims at describing the process of selecting or rejecting these transactions.


Accepting conditions

Transactions received from the network must fulfil the following criteria in order to be added to the queue:

Note that a transaction would be included in the queue if it fulfils the criteria mentioned above and:

Dropping conditions

Once a transaction has been added to the queue, it might get dropped if:

Note that the last 3 conditions require additionally that another transaction with a higher overall score (i.e. gas price), potentially from a different sender, fulfils the requirement to enter the pool while it’s full.

Dropping logic

Given the following transactions in a queue from a same non local sender account:

[TX(nonce=1)| TX(nonce=2) | Tx(nonce=3) | Tx(nonce=4)]

Where nonce=1 is in the past, nonce=2 is current, nonce=3 and nonce=4 are in the future. nonce=1 can be dropped without discussion. The transaction with nonce=5 would be the “lowest rated” transaction for this sender as it is far in the future. The system would then compare this transaction with the other transactions in the queue from the other senders. The decision to drop a transaction is taken based on the transaction queue strategy (--tx-queue-strategy), which is gas_price per default. If the transaction nonce=5 has the lowest gas price among the “lowest rated” transactions from the queue, it will be dropped.


Local transactions

Local transactions are transactions that have been created or submitted to the local node. Such transactions have a priority boost in the queue - they will get propagated first and included in the pending block first. Local transactions can be submitted via two RPC methods: eth_sendTransaction and eth_sendRawTransaction. For the former the node has to manage the private key (the sender address), for the latter the transaction is going to be marked as local no matter the sender.

Configuration flags


The table below shows when transaction is considered as local:

  Received via RPC eth_sendTransaction Received via RPC eth_sendRawTransaction Received over the network and sender is local account
no flag YES YES NO*
tx-queue-no-unfamiliar-locals YES NO** NO*
tx-queue-no-early-exit YES YES YES
both YES NO** YES
 * YES if the pool is not full
** YES if the sender is local account


The RPC API will only show the external transactions that are in the queue. They will never return rejected transactions.