A crypto deposit is not an event. It is an opinion that gets stronger over time.
Most custodial wallet code treats it like an event anyway: watch the chain, see the transaction, credit the balance. That works until the block it landed in stops existing.
What I learned building custodial BTC and ETH wallets is that the interesting design decision is not the confirmation threshold. It is what the user can do with money that is only probably theirs.
So I model a deposit as a state, not a notification. Detected, pending, credited, reversed. Each state has its own rules about what it unlocks: visible in the interface early, spendable late, withdrawable off-platform latest of all. A reorg then becomes a normal transition instead of a support ticket and a manual database edit at midnight.
The part teams skip is the reversal path. Everyone writes the credit logic. Almost nobody writes the code that takes it back and leaves an auditable trail, because it feels like an edge case until the day it is not.
If you run custodial balances: do you let users trade on unconfirmed deposits, and if so, who eats the loss when the chain disagrees?