Fixed-Rate Swaps in Congestion: The 30-Minute Window

A fixed rate is a promise about a price, not about a clock. At 10:00 UTC on 25 October 2026 the Bitcoin mempool held 39,397 transactions and 21.98 MvB, and the newest block, 973,056, was 99.9% full: weight 3,997,414 against a 4,000,000 limit, 6,986 transactions inside 999,353 vB. That is the environment a fixed-rate swap has to survive, because such an order does two things at once — it freezes the number on the screen, and it starts a stopwatch. Congestion only attacks the second. This piece measures how much slack that stopwatch really has, using today's mempool, 320 Monero blocks and a ten-minute sample of our own quotes. (how Monero privacy works)

What a fixed rate actually locks. A fixed-rate swap locks the conversion ratio between the asset you send and the asset you receive at the instant the order is created. It does not lock your position in a mempool queue, the fee your wallet picks, or the block cadence of either chain. Everything the ratio depends on is frozen; everything the delivery depends on is not. That asymmetry is why a provider has to hedge the lock, and why a fixed quote normally carries a slightly wider spread than a floating one even before anything goes wrong — the hedge is priced in, and the price is the interval between your click and settlement. (how Monero privacy works)

The 30 minutes start when the address appears, not when you press send. In our order store the expiry is a constant: 30 × 60 × 1000 milliseconds from creation. When it elapses, the order is marked expired locally only if the pool also still reports it as waiting for a deposit — never while a payment is visible. A six-hour lookback then re-checks locally expired orders, so a late deposit the pool accepted can still settle, and a 24-hour force-expire covers orders the pool no longer recognises at all. The practical consequence is uncomfortable: the minutes you spend finding the wallet, unlocking it, or waiting for an exchange withdrawal to clear are already being subtracted from the window.

Where the minutes go if you deposit XMR. We took 310 rolling ten-block windows from the last 320 Monero blocks (height 3,791,733 at 10:05 UTC). Mean 17.2 minutes, median 16.2, tenth percentile 9.6, ninetieth 25.8, worst 39.5. Of those windows, 12.9% ran past 25 minutes and 3.5% ran past 30. Ten confirmations is the standard credit threshold for XMR, so on a typical order the confirmation wait alone eats half the window, and on roughly one order in twenty-nine it eats all of it before your transaction is even reliably in a pool. (Monero confirmation waits)

Why "two minutes per block" is the wrong number to plan with. Across the same 320 blocks the 318 measured intervals average 114.5 seconds, close to the 120-second target, but the median is 65 seconds, 30.8% of intervals are shorter than 30 seconds, and 7.9% are 300 seconds or longer, with the worst at 1,226 seconds. Monero retargets difficulty block by block, so the chain oscillates: a burst of near-instant blocks, then a long gap. Zcash has the same shape today — 39 intervals around height 3,529,990 average 84.5 seconds, median 55, worst 387. The average is a fine planning number for a month and a bad one for a thirty-minute decision. (Zcash vs Monero 2026)

What congestion looks like on the deposit leg. Back to Bitcoin at 10:00 UTC: 83.1% of the mempool — 18.25 MvB — sat at or below roughly 0.1 sat/vB, while everything above 1 sat/vB amounted to 0.31 MvB, about a third of one block. The recommended fee was 1 sat/vB at every urgency level. A deposit paying 0.1 sat/vB joins that 18.25 MvB queue; at about 999,000 vB per block that is eighteen blocks, which at today's 305-second median interval is roughly 92 minutes and at the 364-second mean roughly 110. Both are three to four times the window. A deposit at 1 sat/vB is in the next block. Same order, same lock, and a hundredfold difference in outcome, decided entirely by a number your wallet chose before you opened the site. (how Monero fees work)

What the lock actually buys, measured. We sampled our quote endpoint every thirty seconds for 10.6 minutes, from 10:02:07 to 10:12:46 UTC, twenty-one samples per pair. 100 USDT-TRC20 to XMR went from 0.14532615 to 0.14504115, minus 0.20%, with a full range of 0.37%. 0.05 BTC to XMR went from 6.574904 to 6.56514, minus 0.15%, range 0.32%. 1 XMR to USDT went from 597.819 to 598.988, plus 0.20%, range 0.31%. On a quiet Sunday, the drift you are insuring against is under four-tenths of a percent — the same order of magnitude as the extra spread a fixed quote often carries. A lock is not free insurance; it is a hedge bought at a price, and that price is only visible when you compare it with a floating quote on the same pair in the same minute. (how Monero privacy works)

Three ways the lock turns against you in congestion. The first is expiry: the refund arrives in the original asset on the original network, after you have already paid both network fees at the worst possible moment. A 141 vB Bitcoin deposit costs 141 sat at 1 sat/vB, about eleven cents with BTC at 80,418.68 dollars, and 2,820 sat at 20 sat/vB, about 2.27 dollars — the rescue attempt costs twenty times the original fee. The second is racing the clock: paying twenty times the fee to protect a 0.4% lock on a hundred-dollar order is not a trade, it is a 2.3% loss dressed as urgency. The third is re-sending. Two deposits to the same one-time address is the most common way a stuck order becomes a manual case; the second one may land after that address's order is closed, and returning it becomes a support ticket rather than an automatic refund. (how Monero fees work)

A six-point check before you commit to a fixed quote. First, price the amount, not the pair: today 100 USDT-TRC20 quoted 0.14502616 XMR, or 689.5 USDT per XMR, while 5,000 quoted 8.166292, or 612.3 — a 12.6% gap that came from routing, one route versus two, not from the lock. Second, look up the deposit chain's confirmation threshold and subtract it from thirty minutes. Third, check block fullness: if the last block is at 99% of its weight limit and the floor sits at 0.1 sat/vB, a cheap deposit cannot make the window. Fourth, set the fee for the queue you measured, not the one your wallet remembers. Fifth, send from a wallet you control, never from an exchange withdrawal queue whose timing you cannot see. Sixth, if the arithmetic is bad, wait. (how Monero privacy works)

The mistakes that repeat. Counting the window from broadcast instead of from order creation. Treating local expiry as a total loss when a six-hour lookback may still settle it. Assuming "recommended 1 sat/vB" means your wallet will actually pay it. Splitting an order into small pieces without noticing that fixed costs dominate at the low end — today 100 USDT per unit cost 689.5 USDT per XMR against 612.3 at 5,000. And sending a second deposit because the first one "did not show up", which turns a refundable timeout into a manual reconciliation. (XMR to USDT exit)

The short version. A fixed rate is a lock on the numerator. Congestion is a variable in the denominator, and the denominator is measured in minutes you do not control. If you know your chain's confirmation threshold, watch the mempool floor for sixty seconds, and pay for the queue you are actually joining, a fixed-rate order does exactly what it advertises. If you do not, the lock will hold the price perfectly while the clock runs out — and the price you locked will be the one you never got. (how Monero privacy works)