Cold to Cold: Swapping From a Hardware Wallet
No exchange account, no wallet connection, no KYC file. What actually decides whether the round trip works: the asset matrix at each end, the address you paste, and six habits that keep the device from being the weak link.
Most swaps have an account in the middle somewhere: you deposit on an exchange, a KYC file carries your name, and the withdrawal waits in a risk queue. The cold-to-cold route deletes that middle. Coins leave an address whose keys sit on a hardware device and land on another address whose keys sit on the same device, with one instant swap in between that never asks who you are. The swap is the easy part. What decides whether the round trip actually works is the asset matrix at each end, the address you paste, and two or three habits that keep the device from becoming the weak link.
Start with the uncomfortable constraint: not every asset completes the round trip. A hardware wallet signs for a fixed list of chains, and Monero is the gap in that list. Checked on 20 October 2026: Ledger's own Monero page does not describe native support at all, it tells users to "connect your Ledger hardware wallet to a compatible third-party wallet to secure and manage your Monero (XMR)" and points at Monero GUI. Trezor's coin directory lists Monero under the Safe 7, Safe 5, Safe 3 and Model T, but marks Suite support as false and names Monero GUI, Cake Wallet and Feather as the wallets that drive it. Read plainly: the keys can stay on the device, the interface has to be a Monero wallet. Bitcoin, Litecoin, Ethereum, TRON-based USDT and Zcash transparent addresses carry no such caveat - those the vendor apps handle directly. So a genuinely clean round trip works for BTC, LTC, ETH/USDT and t-address ZEC, and for XMR only with the software-wallet step written into the plan from the start. (Monero wallet guide)
Three routes that actually run. Route A, the one most people should use: BTC leaves the hardware wallet, XMR lands in a software wallet whose seed you hold (Cake or Feather), and the Monero side is spent from there. Nothing in the middle is custodial; the weak point is that the XMR leg is hot. Route B: USDT-TRC20 leaves a Ledger TRON account and XMR lands in a software wallet - same shape, cheaper to send, but the TRON account needs a little TRX for bandwidth and energy or the transfer never broadcasts. Route C runs the other way: XMR in from a software wallet, BTC or USDT out to the hardware wallet's receive address, so the long-term holding ends up cold even though the input was hot. All three share one property: the swap provider never needs your device, your seed, or a wallet connection - an order takes an address and an amount. (XMR to USDT exit)
The procedure, in order. 1. Pull the quote first and note the payout amount - the rate locks at order creation, so the figure on screen is the figure owed. 2. Generate a fresh receive address in the destination wallet and verify it on the device screen, checking both ends of the string, not just the first and last four characters. 3. Set the refund address to another address you control, on the same network as the deposit; an exchange deposit address there hands the venue your entire order history. 4. If the amount is large enough to hurt, send a small test first - per-pair minimums are set by network cost and the quote form shows them. 5. Send from the hardware wallet, approve the destination as displayed on the device, and copy the transaction id. 6. Match the payin hash on the order page against that id, then watch the payout hash appear on the other chain before you consider the job done. (recovering misdirected funds)
What the chain actually charges, measured today. At 06:00 UTC on 20 October 2026 the Bitcoin mempool held 40,399 transactions and 24.1 MvB, and all four recommended tiers - fastest, half-hour, hour, economy - sat at 1 sat/vB. A native SegWit spend with one input and two outputs runs about 141 vB, so the deposit leg costs roughly 141 satoshis, or 0.00000141 BTC. On a 0.05 BTC order that is 0.0028% of the amount sent. On the Monero side a public node returned a base fee of 0.00002 XMR per kB (20,000 atomic units), making a typical 1.4 kB transfer about 0.000028 XMR - a couple of cents at the rates quoted below. The honest conclusion: the extra signing step on a hardware wallet is not where the money goes. The spread is. (how Monero fees work)
Six ways this route fails, all avoidable. A passphrase-protected hidden wallet shows different addresses than the default one - confirm which wallet is open before generating the receive address, or the payout lands in the other. Clipboard malware swaps addresses between copy and paste; the device screen is the only source of truth, which is the entire reason to own one. Change from a deposit returns to a change address inside your own wallet, not to the swap service, so a balance that looks short right after sending is usually just unconfirmed change. TRC20 transfers need TRX for bandwidth and energy; an account holding only USDT cannot move it. Pasting an exchange deposit address as the payout address turns a private swap into a labelled one, and if that asset needs a memo, the funds may never credit. And the swap buttons built into vendor apps often route through a custodial partner - if the point was cold-to-cold, read who sits on the other side of that button. (XMR to USDT exit)
The numbers, as measured. At 06:00 UTC on 20 October 2026 the quote endpoint returned 0.05 BTC to 6.65653563 XMR, i.e. 133.1307 XMR per BTC; 500 USDT-TRC20 to 0.79683556 XMR; and 1 XMR to 587.075849 USDT-TRC20. The two directions do not imply the same price: 500 USDT buying 0.797 XMR works out to 627.48 USDT per XMR, while selling 1 XMR returns 587.08. That gap is not a fee line anyone can negotiate away, and it is why a quote only means something for the direction you are actually trading. The catalog at the same moment listed 539 assets across 71 networks, 7 of which need a memo or tag. Rates move; the page is the authority. (XMR to USDT exit)
A checklist worth keeping. Both legs must be addresses whose keys you hold; the payout address must be fresh and confirmed on the device; the refund address must be self-custodied and on the deposit network; the amount should be non-round and above the pair minimum; the payin hash should match what the device signed; and the payout hash should be visible before you call it finished. Do those six and the only thing the chain learns is that some address sent some amount into an instant swap - not who was holding the device. (recovering misdirected funds)