Swap Failed? Refund, Stuck Order or Short Payout
An instant swap can only end three ways, and the payin hash tells you which one you are in. Seven states, three endings, six things to save, and the measured cost of being small.
An order page shows two things worth reading: how much will actually land, and a status word. The status is the part worth learning. An instant swap can only end in three ways that cost you something: the money comes back (refunded), it stops moving (stuck), or it arrives smaller than quoted (short payout). Each ending has its own cause, its own evidence and its own correct response, and each one is signalled by details visible before you send anything. What follows is the failure manual: the seven states an order actually passes through, the three endings, and the six records to keep on the way.
Seven states, one order. Every order walks waiting_deposit to confirming to settling to paid, and can end early as expired, refunded or failed. The four terminal states never go backwards and polling stops on them - our API documentation says so explicitly, and it matters, because a status that can regress is a status you cannot act on. The clock starts at order creation, not at your broadcast: the deposit address is valid for 30 minutes, and an order with nothing received in that window is cancelled rather than left pending forever. The site keeps looking for late deposits for six hours after a cancellation, so a payment that lands afterwards can still be matched to the order instead of disappearing into a support thread. Two consequences follow. Send inside the window, with margin rather than at the last minute. And if you are late, say it with a hash, not a story.
Ending one: refunded - it comes back, minus a fee. A refund is triggered when a deposit arrives but the swap cannot complete: a payout network that does not match, a pair the route cannot fill at that size, or a compliance review at the pool. This is not a reversal. Funds return to the refund address you set, on the deposit network, in the original asset - nothing converts on the way home - and the return is its own on-chain transaction with its own fee, which you effectively pay. That is why size matters. Our order page states plainly that amounts far below the stated amount cannot be processed or refunded at all, because a $3 deposit on a network whose transfer costs more than $3 leaves nothing to send. Measured in block 87,296,480 on 21 October 2026, a USDT-TRC20 transfer cost between 0 and 0.345 TRX; the same transfer on Ethereum routinely costs several times that, which is exactly where small refunds die. (recovering misdirected funds)
Ending two: stuck - the state stops advancing. Three shapes, three meanings, and the payin hash tells you which. No payin hash twenty minutes in: the money has not reached the deposit address - not sent, sent on another network, or sent without a memo the order required, in which case the transfer confirms and the order never sees it. A payin hash with the status on confirming for several blocks: the transaction exists and is waiting for depth, usually because the fee was set below what the mempool was paying. A payin hash with the status on settling and no payout hash yet: the deposit is confirmed and the venue is executing - the slow case that resolves itself, and the one where sending a second deposit is the only move that makes things genuinely worse. On the payout side Monero needs 10 confirmations at a 120-second block target, so about twenty minutes of pure waiting that no support ticket can shorten. (how Monero fees work)
Why thirty minutes is not always enough, measured this morning. At 06:05 UTC on 22 October 2026 the Bitcoin mempool held 53,119 transactions and 25.33 MvB; the recommended fee was 2 sat/vB for the fastest tier and 1 sat/vB for the other three; the next projected block had a median fee of 1.0 sat/vB. So a 1 sat/vB deposit was sitting exactly on the median - included, but queued. A 141 vB SegWit spend costs 141 satoshis at that rate, which is not the problem. The problem is the clock against block spacing: the last five intervals were 104, 114, 339, 594 and 690 seconds. Three blocks can be five minutes or thirty-five. When the 30 minutes run out with your deposit still unconfirmed, the order has already expired - the money is not gone, but you are on the late-deposit path, which needs the hash and patience rather than a second send. (how Monero fees work)
Ending three: short payout - but there is no partial state. Nothing in the state machine says partial, and nothing on the order page should be read that way. What looks like a partial fill is one of three accounting differences. First, you sent less than quoted: below the pair floor the quote is refused outright - the floor for buying XMR with USDT-TRC20 was 20.46898 USDT on 22 October 2026, against a ceiling of 180,947.334447 - and just above the floor the per-order overhead eats the rate. Same minute, same direction: 100 USDT implied 737.54 USDT per XMR, 500 implied 669.63, 1,000 implied 662.16, 5,000 implied 656.33. The 100 USDT order carries roughly 10.49 USD of value that the 5,000-size rate would not charge. Second, you sent more than quoted, and the excess needs its own return transfer - a second on-chain movement, not a missing payout. Third, you counted the payout before it confirmed: the payout hash lives on the destination chain, and a credit that has not reached depth reads as absent or pending, not as short. (XMR to USDT exit)
Six records to keep, three things not to do. Save the order id and its creation time, because the 30 minutes is counted from there; the payin hash exactly as your wallet shows it; the payout hash the moment it appears; the inbound history of the refund address, because a refund arrives there and nowhere else; the block height and timestamp of each hash; and the pool's own order reference if the order page exposes one. Do not send a second deposit into a stuck order - it does not speed anything up and it does complicate the refund. Do not plan to change the refund address later; it is fixed at creation, which is exactly why it deserves a minute of attention up front. And do not report a payment without a hash: on an instant swap the hash is the entire claim, and a thread without one is a conversation about feelings. (recovering misdirected funds)
The numbers this was written against. At 06:04 UTC on 22 October 2026: 100 USDT-TRC20 quoted 0.13558513 XMR, 1 XMR quoted 625.366793 USDT-TRC20, and 0.05 BTC quoted 6.32374474 XMR, or 126.47489 XMR per BTC - about 79,093 USDT per BTC at the sell-side rate. Bounds on that corridor were 20.46898 to 180,947.334447 USDT. The catalog listed 538 assets across 72 networks, 61 stablecoins and 7 assets needing a memo. Monero stood at height 3,789,466 with 77 transactions in its pool. Rates move; the page is the authority. What does not move is the order of risk: the network line, then the memo field, then the amount, then the clock - and only then the rate, which is the number everyone checks first and the one that decides the least when an order goes wrong. (XMR to USDT exit)