If you set up an event listener with Geth (I assume also with Parity) you get notifications when a particular event shows up in the event logs.

Sometimes a reorg will happen, and the block where that event happened will be orphaned and disappear from the main history. The same transaction may cause an event to be raised in a different block.

Is the following correct?

  • An event will always be fired when a block generating that event gets into what the node considers the main chain
  • If there's a big reorg events several blocks deep will be sent out almost simultaneously
  • An event will still be sent out again even if its content (aside from block hash etc) is the same, so for example if you listen for a contract that raises an event when it's paid, you may get the same event twice even though you'll ultimately only end up getting paid once

Are there any traps for the unwary or interesting implementation-specific wrinkles?

1 Answer 1


I believe you are correct, although I don't think I've ever tested it. Event filters in web3.js are a little strange--if you set fromBlock to earlier than 'latest', it will trigger on historical events.

Looking at the actual JSON-RPC spec, it seems that eth_getFilterChanges will actually say if an event was removed via a reorg. While I don't think the current web3.js exploits this to a large degree, a client that uses the RPC directly (shudder) could know better.

  • This is something I hadn't considered, but if you're filtering for 'latest', I wonder if you still get an event for a block that isn't at the tip when the reorg happens. Taken literally it sounds like you wouldn't; There should be no point at which your node considers the block with your event in it the latest. But by filtering for 'latest' people are generally expecting to get everything that happens on the main chain while they're filtering. I wonder which of these two intuitions Geth has chosen to disappoint... Dec 9, 2016 at 2:40

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.