The blockchain is known for its immutability and rigidness, however the process by which transactions get to be recorded on the blockchain are anything but, and the whole process is often overlooked.

Can my transactions be viewed/affected by others before they are confirmed? Can I get an edge by having access to the mempool data?

In this tech-dive, we will take a closer look at the Ethereum mempool to see if there is any way for developers in the Ethereum ecosystem to leverage this resource to get an edge and better understand the Ethereum blockchain.

When a user sends a transaction on Ethereum, the transaction is sent from either a wallet or a Dapp to a node. Many of us developers (who do not run nodes) use services like Infura or Alchemy who run their own nodes. If you run your own node, you can send transactions directly to the mempool.

A node is a volunteer validator on the network and not to be confused with a miner, (miners seek to remove transactions from the mempool, as will be discussed later). The transaction will be 'vetted' by the node to check that it is legitimate and could 'qualify' to be included in the blockchain.

All being well, the node will store the transaction in its continually updating memory pool (mempool) ready to be immortalized on the blockchain. The mempool is the gateway and waiting-room to the blockchain, something all transactions must pass through to be included in a block on the blockchain.

The term - "The Mempool" - is a convenient social-construct, as it isn't a singular, coherent pool in the classic sense. Each part of the mempool is held at each individual node, which may or may not be in agreement/alignment with the other nodes on the network.

If you are using MetaMask, you may have seen something like this:

You may have also used the 'Speed Up' functionality that MetaMask provides. This speeds up the transaction by adding more gas towards it. It is also possible to cancel the transaction. How is this possible? It is a common misconception that transactions are set-in-stone from the second you press send. They aren't.

Pending transactions are transactions that are currently in the mempool and will remain there until they are included in a block or, if a transaction is stuck for too long, it will be dropped by the nodes and effectively be cancelled. So long as the transaction is within the mempool, it is possible to speed it up or cancel it.

Current pending transactions are available to view on Etherscan At time of writing, there are ~200k transactions in the mempool.

After a node has processed the transaction and entered it into the mempool as a pending transaction, it will then broadcast the transaction to other peer nodes. Each peer will add the transaction into their mempools and broadcast the transaction on again to get maximum distribution. Each node will hold a different mempool that could vary significantly from its peers. The mempool is anything but homogeneous. Nodes run on numerous different types of software. A full list (and map) of Ethereum nodes and the software they are running can be found HERE.

The transaction will remain in a pending state for X amount of seconds/minutes hours, visible to all that it is incoming. The transaction will wait for a miner to pick it up. Miners are a special type of node that seek to add the transactions onto the blockchain. The time a transaction spends in the mempool will depend on the fees attached as this is primarily how miners choose which transactions to pick up, higher fees = quicker transaction.

Eventually, a miner will successfully solve the proof-of-work task and add a new block with the transaction in it, onto the blockchain. It is only at this point that the transaction can no longer be sped up or cancelled. The solved block is broadcast throughout the network, detailing all of the transactions included in it. Each node in the network then removes from their mempools, any transactions were included in the new block.

Although it is technically possible to bypass the mempool and send a transaction direct to a miner to include in a block, there isn't a standardised way of doing this. It is not obvious that this method would be beneficial as the sender would have to wait for that particular miner to be successful in mining a block with the transaction rather than forwarding it on to the mempool for any miner to pick up, giving it a much greater chance of being included in an upcoming block.

Being aware of current transactions in the mempool, we can estimate a theoretical optimum gas price as we can view the current range of transaction gas fees. Services like Eth Gas Station take advantage of this.

We can see the pending transactions of other users and other bots, and if necessary, leverage this information to avoid a gas war or get ahead of other transactions. It's also possible analyse pending transactions for DEXs like Uniswap.

We can also monitor Oracles in the mempool. They may be sending information to the blockchain that could effect a peg or some other protocol that relies on the Oracle's information. This gives us a potential opportunity to act upon that information before it hits the blockchain.

Access to the Mempool can give us a view all of the potential transactions to be included in the next block, which can be valuable information. There are several ways to get access to it.

Quick Node offer a guide using their web socket service HERE

Blocknative offer many options to access mempool data, including this in-browser stream listening to DEXs HERE

Interested in running your own node:

If you're running a full Geth node, details on how to query the Mempool can be found HERE. If you're running an OpenEthereum node, details on how to query the mempool can be found HERE.

Hopefully this was a useful primer for those that read this far. Utilising the mempool fully is a deep, technical topic which could be interesting to go into further in a future post.

In the meantime, feel free to reach out to me on Twitter: Warren Dubery