Unique IDs for Blockchain Events and Transfers
Design event identifiers that distinguish several movements in one transaction, preserve network context and support reorganisation-aware processing.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
A transaction hash identifies a transaction, not every event inside it. A durable activity model needs event-level identity before it can deduplicate, reconcile or reverse derived records safely.
Choose the evidence granularity
For EVM logs, preserve network, transaction hash, log index and block identity. The accepted-chain logical key and a particular observed block version can be separate concepts. Expanded batch movements need an additional child position. Do not use a timestamp or a token symbol as a substitute for a durable event identity.
Worked example: two transfers in one transaction
Transaction T emits transfers at log indexes three and seven. A store keyed only by T overwrites or merges them. An event-aware key preserves both. If one event expands into several token IDs, each child also receives a stable position while retaining the parent log reference.
Test identity through corrections
Include repeated delivery, a transaction appearing under a different accepted block and a decoder that later expands more detail. Keep observed evidence versions separately from derived current records. A correction should update or invalidate the affected interpretation, not create a second indistinguishable transfer merely because processing ran again.
A practical acceptance test
Use two logs in one transaction and two expanded children in one batch log. Assert four distinct movement identities where the interpretation requires them, while retaining parent relationships. Replay all deliveries and verify no extra activity. A changed block observation should create a reviewable evidence version rather than a collision hidden by transaction-hash-only storage.
Questions about the topic
Frequently asked questions
Is transaction hash enough for a transfer key?
No. A transaction can contain several relevant movements.
Should timestamps be unique IDs?
No. Multiple events can share a timestamp, and time does not identify their execution position.
Standards & technical documentation