A deposit with six confirmations right now can have two confirmations an hour from now.
That single fact breaks most first attempts at a deposit watcher, because confirmations get stored as a counter and incremented once per poll. They are not a counter. They are a value derived from the current chain tip, and the tip moves — occasionally backwards. Increment it and you end up crediting a balance against a block that no longer exists.
The second half of the problem is the one users actually see. Across polls, restarts and re-scans, the same first inclusion surfaces again and again. First inclusion is an event. Exactly-once notification is the product: one message per deposit, per user, however many times the watcher happens to observe it.
So I keep them as two separate problems with two separate fixes. Recompute depth against the tip on every pass instead of trusting stored state. Key the notification on the deposit itself, never on the observation that produced it — idempotency belongs at the notification boundary, not inside the poll loop.
Where does your watcher break first: reorg handling, or duplicate notifications after a restart?
https://polycratia.com/c/e55a4bac