A support ticket said a deposit never arrived. The transaction was confirmed on-chain, the amount was right, and the balance for that user had not moved.
The address belonged to someone else too.
I generated custodial deposit addresses per user from a derivation index kept in the service's own database. Read the current index, add one, save the new address. No unique constraint on the index, no lock around the read. Two signups landing in the same moment got the same index, so they got the same address. A lookup by address then returned two accounts, and the crediting code quietly took one of them.
That is maybe three lines of ordinary application code. On-chain it is the worst kind of bug: the money is final and the attribution is ambiguous forever, and you rebuild the truth by hand from block data and signup timestamps.
What I changed was not the race itself: races come back. I made the database refuse the mistake instead. Unique constraint on the derivation index, unique constraint on the address. The credit path now posts nothing and raises if one address resolves to more than one account, rather than picking a winner.
Anything money can be sent to needs its uniqueness guaranteed by the storage layer, not by the function that created it.
So I'd ask where you enforce one-to-one between an account and the thing money arrives at: in code, or in the schema...