A broker removes duplicate deliveries of a message you already decided to send, and on a chain the decision to send is the part that repeats [2]. Everything else is bookkeeping about which identity you hand it.
Three identities are on the table. A broker message id is attempt-scoped, so two polls that see the same transfer mint two ids, and dedup then covers retries of a single publish and nothing else [9]. A block-scoped identity, block hash plus index or a poll cursor, is location-scoped: it survives ordinary repetition and changes at the exact moment the transfer is mined into a different block, which the post sums up as location-based keys failing exactly when the chain gets interesting [10]. The third names the payment, and the post's uncomfortable observation is that if you can compute it you have already solved deduplication, at which point the broker feature is doing nothing for you [5].
Then the units. Broker deduplication happens inside a window expressed in minutes, while finality is expressed in depth, and depth per asset [12]. chain-watch's ConfirmationPolicy takes `default=6` with `per_asset` overrides of 12 for ETH and USDT, so `depth_for("BTC")` returns 6 and `depth_for("USDT")` returns 12 [13]. Six blocks is an hour on one chain and a couple of minutes on another, and a resync replays a year of history in the time it takes to read it [14]. Take the slow chain: an hour across six confirmations averages ten minutes a block, so the same depth-12 setting there would be roughly two hours of window [1]. A minute-based setting has to cover the worst case, and the worst case is a replay from height zero.
Adoption has ceremony. The watcher's state is the guarantee, so it has to be persisted and rehydrated, which the post does by loading a JSON snapshot through `WatcherState.from_dict` and passing it into the constructor [18]. A watcher that boots with empty state re-reports everything it can still see. Unbounded growth is an odd thing to write into your own README, and writing it there is the right call.
The argument arrives from the maintainer of the library it recommends [7], so check the mechanism rather than the recommendation: read your poll loop and see whether the range it reads can include a block it has read before. The part that may not transfer is the key shape, because a `(tx_id, output_index)` pair presumes your source hands you a stable output index for the payment you care about. The policy example configures ETH and USDT next to BTC [13], so the intent reaches account-based assets, and whether that index holds there is a question for your node's API, not for your queue.
