3

I am testing out blocknative's mempool explorer (https://explorer.blocknative.com) and noticed a lot of pending transactions are actually already confirmed by the time it picks them up, which I can see by comparing timestamps on etherscan and mempools' pendingTimeStamp parameter. Considering the fact that blocknative's mempool should only have a delay of couple miliseconds I was wondering if these transactions are somehow hidden from the txpool?

Improve this question

2 Answers 2

Reset to default
2

Sean from Blocknative here. Thanks for posting the question!

Etherscan appears to report a block Timestamp using the block header's timestamp field. This is also reported by Blocknative for confirmed transactions in the blockTimeStamp field. This time is set by the minor when the block is constructed (before actual mining). Note that the miner has some control over this value as it is not cryptographically verified, but there are some constraints as described in https://ethereum.stackexchange.com/a/428.

Blocknative reports its detection times in timeStamp field for all transaction status changes and also keeps the pendingTimeStamp field for timing comparison with any subsequent transaction status. Detection is determined by a global network of customized node clients with curated peering in order to minimize detection latency.

If you provide specific transactions our team can look into the specific case. You can easily join our Discord Community and chat with us there. https://discord.gg/KZaBVME

To learn about our mempool data infrastructure, please visit https://www.blocknative.com/advantage

Improve this answer
1
  • Thank you, I was confused by the etherscan's timestamp header. Hopefully this answer helps other developers.
    – WhiteHat
    May 25, 2021 at 11:43
4

It's just a slow node...

When a node receives a transaction, it sends it to other connected nodes, who then send it to other connected nodes (repeat), until all the nodes have the transaction in their mempool. This process takes some time (but not much).

It is possible that a transaction that is sent just before a block is mined could be picked up by the miner before it has time to reach your node (or Mempool explorer's node). In that case, you would see it as confirmed without having seen it in the mempool beforehand.

A node can reduce the odds of that happening by increasing the number of peers it is connected to, at the cost of bandwith.

Or a dark pool!

However, it is possible for a miner to setup a dark pool. If you have a prior agreement with a miner that operates a dark pool, you could do the following:

  1. Send your transaction to that miner node, and only to that miner.
  2. The miner will keep your transaction in its mempool, but by having overriden the default code (geth, parity), he will NOT broadcast it to anyone.
  3. When finally it is the miner's turn to mine a block, he will include your transaction in the block.

This will in fact hide your transaction from anyone but the miner until it is finally confirmed. The downside is that you do not know when it will be the miner's turn to mine a block and it could take a long time before your transaction is confirmed.

In conclusion

Either you saw one of those rare dark transactions, or Mempool explorer is not connected to enough nodes so that it misses transactions before they are confirmed sometimes.

Improve this answer

Your Answer

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

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