Who Holds Your Coins in a Custodial Swap? We Measured
We timed four swaps on-chain: payouts arrived 37-174s after deposit, yet the coins sat in the provider's address 8m45s-15m38s before swept. What that risk means.
The address is theirs, not yours. Every custodial swap starts with a small asymmetry. The order API takes seven fields - pair, amount, payout address, refund address - and returns a deposit address generated by the liquidity provider, together with the provider's own order ID. Nothing in that exchange gives you a key. Our order table stores the deposit address and that ID; it stores no key material and cannot sign for the address. The moment your wallet broadcasts, the coins are in an account controlled by someone else, and what you hold is a claim on the provider's payout. (recovering misdirected funds)
What you hold after you hit send is an IOU. There is no escrow contract and no multisig holding your coins. The provider receives the deposit, credits the order, and pays from its own inventory on the destination chain. That is why quotes are instant and a swap finishes in minutes: you are not waiting for your specific coins to be moved, you are waiting for a balance transfer. The claim is priced, dated and tied to an order ID - and it is only as good as the provider's solvency and willingness to pay.
Four timelines, measured from our own orders. Order A, BTC to USDT-TRC20: created 23:11:57 UTC on 4 October, deposit confirmed 23:23:10 (11m13s later), payout arrived 23:23:57 - 47 seconds after the deposit - and the deposit address was swept at 23:34:40, 11m30s after the deposit and 10m43s after the payout. Order B, BTC to TRX: created 20:40:57 on 13 October, deposit 20:50:38, payout 20:51:15 (37s), sweep 21:06:16 (15m38s after deposit, 15m01s after payout). Order C, 198 USDT-TRON to USDT-BSC: deposit 26s after creation, paid 45s after deposit, swept 8m45s after deposit. Order D, 833 USDT-TRON to XMR: deposit 27s, paid 2m54s. In all four, the payout preceded the sweep. (XMR to USDT exit)
Your coins do not pay you; the float does. In both Bitcoin cases the deposit address was later swept in a ten-input batch into a single output: 1,728,296 sat with a 2,859-sat fee, and 2,397,558 sat with a 3,812-sat fee. Those ten inputs were other deposits being consolidated. The payout to us had already left the provider's hot wallet 10-15 minutes earlier. That is ordinary market making: the provider fronts the destination asset and reimburses itself when the source coins are swept. Your deposit's only job is to settle the provider's books after the fact. (how Monero fees work)
How these numbers were produced, and what they do not prove. For each paid order we took the deposit address from the order row, found the first incoming transaction on that chain and the first payment to the payout address, then the first transaction spending the deposit address as the sweep. Block timestamps are second-resolution; our status change is poll-driven, so the database's paid time can lag the real payout by one polling interval - the payout times above come from the chain, not the database. Four orders is a sample, not a guarantee: the point is the shape of the flow, not a promise about your order.
How long the claim lasts in practice. Across 21 paid orders, the median time from creation to paid was 5.3 minutes; 19 of 21 finished within 21 minutes; one took 1,543 minutes, or 25.7 hours. Refunds show the tail: one 0.308 ETH-to-BNB order was refunded 1,506 minutes after creation (25h06m), while a 0.0019 BTC-to-XMR order was refunded in 0.7 minutes. That is a distribution, not a promise. Our table also holds 149 expired and 5 failed rows, but most of those are our own unpaid test orders, so read the timing, not the failure rate.
What can break the claim. Four things, roughly in order of frequency: the provider's inventory runs out or its payout wallet is throttled; a compliance system freezes the provider's account or the destination address, which stablecoin issuers can blacklist; the source chain reorganises after the deposit was credited; or the deposit lands after the provider's own validity window. The last one is structural. ChangeNOW's own validity was measured at 599.4-599.9 seconds across 13 orders, while our page has a 30-minute backstop - so a late payment can turn a normal swap into a refund case even though the page still shows time left. (XMR to USDT exit)
Seven ways to shrink the exposure. (1) Size the ticket to what you can leave in someone else's hands for five minutes. Small tickets cost more - at 14:08 UTC 100 USDT bought 0.14725016 XMR (implied 679 USD per XMR) while 1,000 bought 1.654191 (604.72), an 11% premium - but they cap the loss. (2) Send in the first minutes, not at minute 29. (3) Read the deposit address on your own screen and compare it with the order page before paying; do not trust the clipboard. (4) Keep the order link, the only channel to the status. (5) Give a refund address you control on the source chain; a refund cannot cross networks. (6) Split large amounts into several orders and several payout addresses. (7) Verify the payout transaction on a block explorer before you move the funds again. (recovering misdirected funds)
Why the model exists, and where its boundary is. Atomic swaps remove the counterparty, but they are slow, thin and limited to single pairs. An aggregator that can pay instantly from float is the only way to serve twenty chains at retail size. The trade is explicit: a few minutes of unsecured credit in exchange for speed and liquidity. "No KYC" removes identity checks, not counterparty risk - the provider still decides whether and when to pay. The honest summary: send only what you can lose for five minutes, verify the payout, and treat the order link as the receipt. At writing time (2026-11-09 14:08 UTC) the catalogue listed 450 assets on 65 networks, and 100 USDT-TRON quoted 0.14725016 XMR. Quotes move; the page governs. (XMR to USDT exit)