When are transactions dropped from the blockchain?

Suppose I broadcast a transaction to the blockchain, then it is a pending transaction waiting to be mined.

But when are pending transactions dropped from the blockchain, e.g., if the gas price is too low? Can someone think of other reasons for miners not willing to include the transaction?

If transactions are not discarded at some point, then an enormous amount of pending transactions could result.


It's important to note that in the context of this question, transactions aren't "dropped from the blockchain". The blockchain represents transactions that were validated by nodes (locally) and registered as blocks in the blockchain (remotely). Each full node in the Ethereum network possesses its own copy of the blockchain in local memory, which means that when a transaction makes it to one of these nodes for validation, this process can be and is done offline. A transaction can remain pending in a node or never make it to the blockchain for a number of reasons, which can be grouped into four categories.

The first of which, maybe most obviously, is machine failure. While this is a constant in software engineering, it is still worth mentioning. The node simply could be corrupted by a software or hardware failure. There are enough nodes validating transactions that the failure of one is not enough to halt the creation of blocks, but widespread machine failure could prevent pending transactions from registering.

The second reason, also rather obvious, is that the transaction itself is invalid and cannot be validated, or cannot yet be validated. If a transaction is invalid because it's inherently invalid then it will never make it to the blockchain. But a transaction which "should" be valid may find itself in the mempool of a full node because of a nonce gap. Perhaps multiple transactions were made in rapid succession and the network didn't neatly serialize them or the client generating the transaction is poorly coded and assigned an invalid nonce, resulting in a transaction that made it to a node with a nonce that was higher (or even lower) than the node was expecting. In this case, this transaction will reside in the mempool until another transaction from the same address with the missing nonce makes it to the blockchain, and then the node will attempt to validate this "out-of-order" transaction. However, if the transaction with the missing nonce never makes it to the blockchain then this "out-of-order" transaction will reside in the mempool indefinitely until it's purged by the node for no other reason than lack of local memory (disk space). If the node had an infinite amount of memory then it would likely hang onto this transaction forever, but that is certainly not the case.

The third reason is competition. If the network is hot enough that there are more transactions willing to pay more gas than yours, enough to keep your transaction in a mempool long enough to get it purged (again, for no other reason than lack of disk space on the node itself), then your transaction may never become a block on the chain.

And the fourth reason is the exception to the rule. The credo of Ethereum is to break stuff and it's absolutely possible that future changes in the protocol could spell doom for pending transactions. Ethereum developers are warned at the door to be ready for anything and events in the past, namely the infamous hard fork, reinforce the wisdom of this advice.

But I suppose the bottom-line answer to the question of when transactions are purged from the mempool is whenever the node runs out of allocated disk space. The more important question to ask is why the transaction is lingering in the mempool.


All transactions are kept in the Mempool a term borrowed from Bitcoin. You can see all the current pending transactions here: Pending Transactions

There's a limit to the size of the Mempool and once it reaches its limit it will start removing transactions. This article When there are too many pending transactions explains it pretty well.

In Geth 1.6.5, the basic config for the mempool is in a Go structure called TxPoolConfig. One of the interesting fields in that structure is GlobalSlots ("Maximum number of executable transaction slots for all accounts"). In the default config (DefaultTxPoolConfig), GlobalSlots is set to 4,096. Once that limit is reached, Geth starts freeing up space by evicting some of the transactions in its mempool according to a fairly complex set of rules.

  • 2
    If a transaction is evicted from the mempool in one node it doesn't mean it will disappear from the network. Another node can keep it around and resubmit it again when it reconnects.
    – Ismael
    Nov 22 '17 at 2:42
  • 1
    Are pending transactions removed from the Mempool in a FIFO (first-in-first-out) manner, i.e., a queue? +1 for your answer.
    – Shuzheng
    Nov 22 '17 at 9:46
  • 1
    @Shuzheng Well transactions that arrive in the mempool first have a higher chance of getting mined and added to a block, but there's a lot of factors to consider the most obvious one is the gas price you're willing to pay. The same way the transactions that are in the bottom of the mempool are more likely to be removed but like Ismael said the removed transaction can be resubmitted. These are the rules of the Bitcoin mempool which should be quite similar How do transactions leave the mempool
    – I.B
    Nov 22 '17 at 14:06
  • From what I can gather this implies that there is no real guaranteed way to determine if a transaction will get dropped from the mempool or even what the odds are that one will get dropped from the mempool, as nodes can technically behave however they desire; so it is unwise to try and rely on any assumption that certain criteria can be met to ensure you persist in the mempool? Sep 4 '20 at 4:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.