Three Checks for Monero Deposits After a Reorg

After a Monero reorg, check that the deposit is on the chain your node now follows, that your wallet still detects its output, and that the output is unlocked before treating it as settled. A reorg happens when the network adopts a competing valid chain with more accumulated work. Blocks on the displaced branch no longer count, so a deposit’s old confirmation count can become stale. Think of it like a receipt stamped by a branch the network stopped using: the stamp alone does not prove the payment is still recorded.

Keep the checks in order. First verify the block, then refresh the wallet’s view of the deposit, then check its current status. Bridge routing is a separate question: how ZeroFi bridge routes work is explained in detail there; a bridge route does not establish whether a Monero output survived a reorg.

Is the deposit block still on the canonical chain?

Check the block against a synchronized Monero daemon, not a saved confirmation count. Record the block height and hash shown for the deposit, then query the daemon’s current chain at that height. Monero’s daemon RPC can report whether a block is on the active chain; its status also reports whether the node is synchronized. If the old block is orphaned or the daemon is still catching up, wait for synchronization and check again.

Confirm that the transaction appears in the active chain and note its current confirmation count. If it was removed, it may be included in a later block, but its prior confirmations do not carry over. A wallet or service should count from the new inclusion. Public transaction data has limits: Monero hides amounts and recipients from outside observers, so a block explorer alone cannot prove that a particular deposit output belongs to you.

Does the receiving wallet still detect the output?

Refresh or rescan the wallet from before the affected block height. A Monero wallet uses its private view key to recognize outputs addressed to it, even though an outside observer cannot identify the recipient from the chain. After the scan catches up, find the incoming transfer by transaction ID and check its reported block height and confirmations.

• Block: Is the reported height on the active chain?
• Transaction: Does the wallet still show the incoming transfer after synchronization?
• Output: Does the wallet list it as received and currently unlocked?

If the transfer disappears, do not assume the deposit is lost or settled. Check whether the transaction returns to the pool and is mined again, or ask the sender or service handling the deposit to verify its status. Because the amount is private on-chain, the receiving wallet’s scan is central to confirming ownership.

Is the output unlocked, and are confirmations enough?

Check both the confirmation count and the wallet’s unlocked status. Monero applies a default spendable age of 10 blocks to normal outputs, and a transaction can also specify a later unlock time. An output can therefore be present in a confirmed transaction but not yet spendable. Conversely, being unlocked does not prove that the block cannot be displaced by a later reorg.

For a personal wallet, wait until the synchronized wallet shows the output as present and unlocked, then use a confirmation buffer appropriate to the value and the service involved. Exchanges and payment processors may require their own depth before crediting a deposit; there is no single confirmation threshold that fits every operator. The practical rule is simple: a deposit is supported by the current chain, the wallet’s scan, and its present output status—not by a confirmation number saved before the reorg.