I have written a simple web.js program to monitor the pending transactions on the BSC chain and output the tx hash on the console. I want to monitor a specific token, but right now I am outputting every pending transaction.

Then, I go to the bscscan webpage and look at all the transactions in the token of interest. There, I can see in real-time the transactions (there are not too many transactions in that token). I see how new transactions are appearing there, already confirmed. My understanding is that at some point, that transactions have been pending, so I must have seen it in my console, but they do not appear. I have tried with many different WebSocket providers, but I see the same behavior with all of them.

My code:

const Web3 = require('web3')

const web3 = new Web3(new Web3.providers.WebsocketProvider('HERE I HAVE TRIED WITH DIFFERENT WSS PROVIDERS'));

const subscription = web3.eth.subscribe('pendingTransactions', (err, res) => {
    if (err) console.error(err)

subscription.on('data', (txHash) => {
    setTimeout(async () => {

        catch (err) {
    }, 1000)

Any idea why I can not see all the pending transactions?

  • There is no guarantee that you should ever see pending transaction and this is an assumption you have made yourself. See this answer on the life cycle of a Ethereum transaction: stackoverflow.com/a/65842575/315168 Oct 30, 2021 at 18:05
  • Indeed, it was an assumption I have made. I expect that if a miner will mint a new block, he will need to be able to see all the pending transactions to select the ones he wants and mint the block. Is this incorrect? Shouldn’t be complete visibility on the pending transactions a must?
    – Ignacio
    Oct 31, 2021 at 16:21
  • Peer-to-peer network does not have a single state, so what transactions you see may vary greatly. Nov 2, 2021 at 11:03
  • @MikkoOhtamaa, so each node will have a different state at a specific time. I understand that a pending transaction will then arrive sooner or later to a node. However, since the pending transaction has been broadcasted before the minted block, the pending transaction should eventually arrive at the node (even if it had already been included in a block). Is this reasoning incorrect?
    – Ignacio
    Nov 2, 2021 at 13:59
  • It does not need to arrive ever. Every node their different snapshot of mempool that could be conflicting. Nov 3, 2021 at 23:42

2 Answers 2


I am using a code similar to yours, from my side I am seeing all the transactions, just with a delay, I think because of the timeout. Try waiting more time for the txHash to log or add console.log(txHash) before the setTimeout to 'see' all transactions. My code found the transaction I was waiting for, tried a lot of times and looks like working.

  • The setTimeout() is only delaying the execution of the code by one second, all the transactions triggered by the even are outputted in the console.
    – Ignacio
    Nov 1, 2021 at 13:42

As others pointed out, there are many reasons why you may not a be able to see all transactions.

However, a probable reason would be that the transaction that you see on your pending subscription is a replacement transaction (transaction with same nonce but higher gas price than another transaction), while the one that gets mined is a replaced transaction from your point of view.

Example: Let's say that a sender sent transaction A with nonce 1 and gas price of 5 Gwei, then sent transaction B with nonce 1 and gas price of 6 Gwei. You received transaction B first (because of latency in the network), then transaction A. Only transaction B would appear in your feed because A is invalid from your node's point of view. However, the validator may have received A first, and may not have received B at the time the block was sealed, so that transaction A was included in the block. You saw B, but A was mined.

  • I see, so only valid transactions trigger the pendinTransactions event in web3. Is that right?
    – Ignacio
    Nov 4, 2021 at 13:03
  • Pretty sure yes. An invalid transaction does not become "pending".
    – Undead8
    Nov 4, 2021 at 19:04
  • Don't forget to accept an answer or award the bounty, otherwise it is lost.
    – Undead8
    Nov 5, 2021 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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