Eth_subscribe logs latency

I am using eth_subscribe to subscribe to specific transactions, specifying an address filter. However, I receive logs of transactions 3 to 10 seconds later than the transaction timestamp, which I assume is the timestamp when the transaction was mined. Is there any way I can reduce this latency, in order to receive the transaction logs as soon (<1s) as the transaction was mined?

Thank you!

1 Like

Hi @KaiB, and welcome to the Infura community!
The timestamp field is actually when a miner started to mine the block, not when it actually made it to the network. Mining a block usually takes up to 15 seconds, so the logs taking a few additional seconds makes sense. Hope this helps!

1 Like

Thanks @Leiya_Kenney for the quick response!

To clarify, the timestamp field I am talking about is the one appearing on etherscan.io (not sure if there are more). When looking at blocks on etherscan.io, the timestamp’s info box actually clearly says that this is the date and time at which the block was mined. This is confirmed when looking at next and previous blocks, e.g.

...
block 1000:
timestamp: 10:03:42 PM +UTC
mined by: 0x1000 in 12 sec

block 1001:
timestamp: 10:03:50 PM +UTC
mined by: 0x1001 in 8 sec

block 1002:
timestamp: 10:04:20 PM +UTC
mined by: 0x1002 in 30 sec
...

All transactions in block 1002 will have that same timestamp, 10:04:20 PM +UTC.

My issue is that I will receive the logs of a transaction included in block 1002 not before 10:04:23 PM +UTC, that is to say at least 3 seconds after the block is mined.

1 Like

Got it! We have a blog post about reducing latency - depending on the methods used as well as the nodes used, you’ll end up with differing levels of latency. Check it out here! Hopefully, this helps give you some additional context :slight_smile:

1 Like