Counting a transfer once: dedupe keys on EVM and Solana
GetAgentCap team · published 10/7/2026
Any system that polls a chain will eventually see the same transfer twice, because windows overlap, jobs retry and nodes get re-queried. Whether your total is right depends on having a key that identifies one transfer exactly.
Why duplicates happen
A polling job that reads "the last N blocks" will re-read blocks it has already seen, by design, so that a late-arriving block isn't missed. A retried job reads the same range again. Two workers on overlapping ranges read the same events.
None of this is a bug. It is the cost of not losing data, and the fix belongs at write time: make recording the same transfer twice a no-op.
On EVM chains
A transaction hash alone is not enough, because one transaction can emit several Transfer events, for example a batch or a router call. The pair of transaction hash and log index identifies a single event within a block.
Keep the chain identifier in the key as well, since the same hash format exists on every EVM chain.
On Solana
A Solana transaction is identified by its signature, and one transaction can contain several instructions, including inner instructions produced by other programs.
A transfer is therefore best keyed by the signature plus the position of the instruction that moved the tokens, so two transfers in one transaction don't collapse into one.
Make the database enforce it
Put a unique constraint on the key and insert with conflict handling, rather than checking for existence first. The check-then-insert pattern has a race window when two workers run at once, and a unique constraint closes it.
Then a re-scan can run as often as you like. The count only changes when there is a genuinely new transfer, which is the property you want from a ledger.