Four checks to make when an XMR swap stalls

When an XMR swap stalls, first find which step has stopped: the source payment, the swap service, or the receiving wallet. Those stages can look identical in a status screen, but they call for different fixes. A delayed confirmation is different from an order that never matched or a wallet that has not scanned the incoming transaction.

The route matters too. A custodial swap service records an order and handles the exchange; a peer-to-peer or atomic route follows its own protocol and recovery steps. If you are still comparing routes, how an XMR bridge route works explains the options. For a live swap, use the service’s order record as the map, then check the matching transaction or wallet.

Was the source payment broadcast and confirmed?

Check the sending wallet first: does it show a transaction ID, and does the transaction have confirmations on its own network? If there is no transaction ID, the payment may not have left the wallet. Check its connection, balance and fee settings before submitting anything again.

If there is a transaction ID, compare its confirmation count with the threshold shown by the swap service. The source network and the swap service both affect how long this stage takes. A transaction can be visible but still short of the service’s required confirmations. That is a wait, not proof that the swap failed. Don’t send a second payment unless the order instructions explicitly call for it; a duplicate can create a second order rather than speed up the first.

For Monero specifically, a public block explorer cannot reveal the recipient and amount as it might for a transparent chain. The service’s order page and support record matter more for matching a Monero deposit. If you sent XMR from your own wallet, its history can show the transaction and confirmation state, while a transaction proof can help establish what was paid without making the transfer details public.

Has the receiving wallet finished syncing?

A receiving wallet can miss a payment in its display while it catches up with the network. Check whether the wallet is connected to a node and has synced to the current chain height. Then refresh or reopen its transaction history. A wallet’s local scan is separate from the transaction’s confirmation: the funds can be on-chain while the wallet has not yet detected them.

For a Monero receipt, look for the incoming transfer in the wallet rather than expecting a public explorer to identify it. The Monero wallet can verify the transaction with its private view information; public observers do not see the destination and amount in the same way they do on transparent chains. If the receiving address was newly created or imported, check that the wallet is scanning from a point early enough to include the transfer. A wallet restore height set too late can make older activity appear absent until the wallet is rescanned.

What does the order record say happened?

Use the exact order ID and read the service’s status message before changing anything. “Awaiting deposit,” “confirming,” “exchanging” and “sending” describe different points in the process. The next useful evidence depends on the status: a source transaction ID for a deposit, a service update for an exchange in progress, or a destination transaction ID for a payout.

Check the order’s deposit address, network, asset and any required memo or payment reference against the instructions you followed. An address on the wrong network, an omitted reference, or an amount outside the service’s stated limits can prevent automatic matching. The remedy varies by service. A support request should include the order ID, transaction ID, asset and network, but never a seed phrase or private key. Those credentials give control of the wallet; a legitimate status investigation does not require them.

If the order says complete, the service may have already sent the output. Ask for the payout transaction ID and verify it in the destination wallet or on the relevant network. If no payout ID exists, “complete” may refer to an internal order step rather than a confirmed receipt. Ask support which event their status records as completion.

Which route and recovery rules apply?

Check the route’s own timeout, refund and recovery instructions before retrying or cancelling. A swap through a service with an order desk depends on that operator’s support and payment matching. A peer-to-peer or atomic swap depends on the protocol’s stages and recovery process. One route may offer a clearer human escalation path; another may reduce reliance on an intermediary but require the user to follow protocol steps precisely.

Use this short checklist to decide what to gather next:

• No source transaction ID: check the sending wallet and do not assume payment was sent.
• Source transaction has few confirmations: compare the count with the service’s requirement and wait for the next status update.
• Deposit confirmed, no output: contact the service with the order ID and request the payout state or transaction ID.
• Output sent, wallet shows nothing: check the destination network, wallet sync and transaction history.

The useful signals are the source confirmation count, a change in the order’s recorded stage, and a payout transaction that the destination wallet can detect. Those separate a slow handoff from a mismatched payment or an unsynced wallet—and show whether waiting, wallet repair or service support is the next step.