Four Stages That Set Your XMR-to-Bitcoin Swap Time

An XMR-to-Bitcoin atomic swap takes as long as its setup, funding transactions and confirmation gates require. In the peer-to-peer protocol, the Bitcoin holder locks BTC first; the XMR holder then locks Monero, and a Bitcoin spend reveals key information that lets the other party claim the XMR. A hosted swap service can add its own deposit checks or payout queue. For the service categories, see this guide to XMR bridge models and their use cases.

What are the four stages of an XMR-to-Bitcoin swap?

The wait breaks into four stages, but only three require blockchains to include and confirm transactions.

• Setup: The parties agree on amounts and time limits, exchange keys and verify proofs. This work happens off-chain, so its duration depends on the swap software and communication between participants.
• Bitcoin lock: The BTC holder broadcasts a transaction locking bitcoin under the swap’s spending conditions. The XMR holder waits for the required confirmations before locking Monero.
• Monero lock: The XMR holder sends funds to an output controlled by a shared spend key. The BTC holder checks the amount and waits for the agreed confirmation depth before sending the final adaptor signature.
• Bitcoin redemption: The XMR holder completes and broadcasts the Bitcoin spend. Its signature reveals the key share the BTC holder needs to control the Monero output. The BTC recipient may also wait for confirmations before treating the payment as settled.

The exact steps differ between implementations. In the published protocol, for example, the XMR holder can spend the Bitcoin after receiving the adaptor signature, while the BTC holder extracts the XMR key share from that published spend. “Swap complete” can therefore mean either that the Bitcoin payout is on-chain or that both parties have claimed their funds.

Why do confirmations set most of the waiting time?

A transaction broadcast is not yet a confirmed transaction. It first needs inclusion in a block, then additional blocks if the swap’s participants require more confirmation depth before proceeding. The protocol paper leaves that security threshold to the participants and says it must fit within the protocol’s time limits.

Each extra confirmation adds a wait governed by that chain’s block production. The swap advances only when its next confirmation gate is met, so a delay on either chain can hold up the sequence. A busy mempool can also delay Bitcoin transaction inclusion when the fee offered does not attract miners quickly.

In the Bitcoin script used by the published design, OP_CHECKSEQUENCEVERIFY enforces a relative timelock on refund paths. That timer is a safety boundary for a stalled swap, not a countdown that speeds up the successful exchange. If a party stops responding or a required confirmation takes too long, the protocol may enter its refund path instead.

What should you check before starting?

Ask which confirmation each stage waits for, whether the displayed estimate includes provider processing, and what conditions trigger a refund. In a peer-to-peer atomic swap, there is no universal completion time: the transaction sequence and each party’s confirmation threshold determine it. A service-mediated route may hide some of that work behind a status screen, but its own processing policy can still affect when BTC reaches your wallet.

The practical rule is to distinguish a quote or deposit receipt from settlement. Check the transaction IDs and confirmation status for the relevant chain, and do not assume a service estimate overrides the Bitcoin and Monero confirmation gates built into its swap process.