// Derived fields. These fields are filled in by the node
// but not secured by consensus.
// index of the log in the block
Index uint `json:"logIndex" gencodec:"required"`

So next time I am looking at eth_getLogs the particular transfer could appear with different index?

I am looking for a way to uniquely identify a particular incoming transfer, many transfers can appear in the same transaction and I need a way to store them and make sure there is no duplicates when worker goes through backlog again.

Simple guess is to use unique composite index for fields: (txid, to, logIndex), but that comment in log.go is confusing me.

Parity returns is as transactionLogIndex, so may I assume it will always be the same in further responses and even if chain reorganises and tx will be included in another block?

1 Answer 1


If you are referring to ERC20 Transfer events. Then under normal circumstances (txid, logIndex) should work as composite index since log entries are in the same order they were generated.

You have to be aware that log entries generation is in total control of the smart contract. It is pretty easy to write a contract that will generate logs in different order if they are mined in different blocks.

Perhaps using (blockHash, txid, logIndex) will work better to support chain reorgs. But you will have to discard events that belong to orphaned blocks.

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.