Multi-Pool Routing: What Redundancy Really Buys
We logged 2,642 quote rounds: 89.6% of them had a single route, the second bid only appears above a per-corridor minimum, and order-stage failover is what actually saves a swap. Every number measured, none asserted.
"Aggregated" is a number you can check, not a slogan. Between 25 October 08:57 and the end of 1 November 2026, our quote engine logged 2,642 rounds of pricing. 2,366 of them (89.6%) came back with exactly one route, 275 (10.4%) with two, and a single round with three. Same engine, same week, wildly different answers. That is the whole story in one line: redundancy is a property of a corridor and an amount, not a property of a website. So instead of arguing about aggregators, this piece measures what the second route actually buys, when it appears, and where it stops helping.
A swap fails in four places, and routing only touches the first two. It can fail at the quote (nobody will price the pair), at order creation (a pool refuses the pair, the address format, or the amount range), at settlement (your deposit confirmed, the payout stalls), or simply slowly (everything works, in four hours). Routing is a quote-stage and create-stage mechanism. Once 100 USDT is sitting at a deposit address and the pool goes quiet, a second pool cannot retroactively help — the money is already committed to a single counterparty. This is why the honest way to read a multi-pool front end is: it reduces the chance you cannot start, not the chance you cannot finish. (XMR to USDT exit)
What the engine actually does, in five constants. Three provider adapters are fired in parallel; each is wrapped in an 8,000 ms timeout; results are collected with a settled-all pattern so one rejection never kills the batch; surviving quotes are sorted by what the user receives, best first; an identical quote is reused for 8 seconds, and one IP may ask 60 times per 10 minutes. The client is told two things and nothing else: how many routes participated, and by how many basis points the winner beat the runner-up. Measured across 12 corridors at 06:04 UTC on 2 November 2026, a full quote took 456 to 1,291 ms end to end. The timeout is the hidden price of redundancy: one pool hanging on its socket costs up to eight seconds of someone's page, which is why the timeout is a constant worth arguing about.
The two numbers need to be read correctly. routes tells you how many bids existed in that round; 0 is never returned, but 1 is extremely common. advantageBps is the gap to the second-best bid — not to the market price. So a 0 does not mean "bad rate", it means "no comparison happened"; and a 900 does not mean "9% cheaper than the market", it means "9% better than the other pool on this corridor at this size". Reading it as a market comparison is the single most common misinterpretation we see, and it cuts both ways: a single-route quote can be perfectly competitive while showing 0, and a double-route quote can show 900 and still be worse than what you would get elsewhere.
What 2,642 rounds actually contain. Restrict to the 275 rounds that had two bids: median advantage 143 bps, 10th percentile 33 bps, 90th percentile 893 bps. Bucketed: 59 rounds under 50 bps, 102 between 50 and 200, 88 between 200 and 1,000, and 26 at or above 1,000. The winner split is the part that surprised us: the second pool won 273 of those 275 rounds, 99.3%. Which means "aggregation" in practice is usually one price-setter plus one fallback that occasionally beats it by more than one percent — and the value of the machinery is concentrated in the tail, not the median. If you only ever look at a typical quote, you will conclude there is no difference. The difference is in the 26 rounds nobody screenshots.
The second bid has a floor, and the floor is per corridor. On USDT-TRC20 to XMR at 06:05 UTC on 2 November 2026 the ladder behaved like a staircase: 40 USDT returned one route at 0.04760146 XMR (implying 840 USD per XMR), 60 one route at 0.08004357 (750), 100 one route at 0.14492777 (690); at 130 the second bidder entered, two routes, advantage 927 bps, 0.211546 XMR (614.52 per XMR); then 200 gave 606 bps (613.97), 500 gave 270 bps (613.20), 2,000 gave 101 bps (613.04) and 10,000 gave 63 bps (612.96). Read the shape, not the numbers: crossing the threshold buys you about 9% once, and from there the advantage decays as the fixed per-order cost is amortised. That fixed cost is the same mechanism that makes small swaps expensive — it is charged on both sides of the bidding war. (XMR to USDT exit)
Coverage is ten tickers, not a catalogue. The site lists 430 assets across 62 networks and 349 distinct tickers; the two pools that were live at 06:04 UTC share pricing for ten tickers — BTC, ETH, BNB, LTC, DOGE, BCH, XMR, ZEC and the two stablecoins USDT and USDC. Everything else in the catalogue is priced by whichever pool still lists it. Even inside the ten there are holes: one pool does not accept ZEC as an input asset, so 5 ZEC to XMR returned a single route (10.26414479 XMR); SOL is not mapped by that pool at all, so 3 SOL to XMR returned one route (0.4529562); DOGE to XMR at 200 returned one route while DOGE to BTC at 500 returned two with 125 bps. Compare with corridors that do have depth: 0.05 BTC to XMR had two routes at 43 bps (6.381238 XMR), 1 XMR to USDT-TRC20 had two at 216 bps (600.933 USDT), 10 LTC had two at 158 bps and 2 BCH had two at 211 bps. (BCH to XMR guide)
The layers that actually save an order are below the quote. When an order is created, the server ignores the price the browser saw and re-runs the whole comparison; the client cannot name a pool. It then walks the sorted list from the best bid down, and if a pool rejects the create — wrong address dialect, amount outside that pool's range, upstream fault — it silently tries the next one, and only fails when the list is exhausted. When everything fails, the error surfaced is the parameter one (bad address, below minimum) rather than "provider unavailable", because that is the only message a user can act on. The last layer is a circuit breaker: a single environment variable removes a pool from the auction with no deploy and no code change. At the time of writing one of the three pools is deliberately switched off, which is precisely why several corridors show routes=1 — and the ops probe shows the remaining two answering in 252 ms and 520 ms.
Five checks that survive contact with a real order. One: read routes before you size — if it says 1, you are not being outbid, you are simply outside the reach of a second bidder. Two: ladder the amount, because the second bid has a floor (130 USDT on TRC20 today, 0.0016 BTC, 0.05 XMR); crossing it is worth about 9% once. Three: do not treat aggregation as an uptime guarantee — settlement is still single-path, so keep refundAddress in a wallet you hold and save the pay-in transaction hash the second you broadcast it. Four: probe with the floor amount, roughly 27 USDT on this corridor, before you move size. Five: remember advantageBps compares a pool to a pool, never to the market. Every figure here is a snapshot at 06:04 UTC on 2 November 2026 — quotes move in seconds and the live page is the only authoritative number. (XMR to USDT exit)