How does a swap service match you with someone moving the opposite direction

05 September 2026

The service maintains a live order book. When you request a swap, it scans that book for a counter-party who wants to send the asset you need and receive the asset you are giving up.

Matching is not magic. It is a database query filtered by asset pair, amount tolerance, and time window. The service does not hold either asset at any point. It simply introduces two people who want the same trade in opposite directions. If no match exists at the moment you arrive, your order sits in the book until someone else submits the complementary order.

The order book mechanics

Every swap service that avoids a centralised account works this way. You submit an order that states: "I have X of asset A on chain 1, and I want Y of asset B on chain 2." The service records that order in a public or semi-public book. Other users see what is available. When a second user submits the inverse order - "I have enough of asset B on chain 2, and I want asset A on chain 1" - the service pairs the two.

The matching logic is straightforward. It checks that the amounts are within the tolerance you set. If you want exactly 1 ETH and someone offers 1.02 ETH, the match is valid as long as your slippage tolerance permits the difference. It also checks that both users are still online and that neither order has expired. Once both conditions hold, the service sends each of you the other's on-chain instructions.

What happens when no match exists

If you submit an order and no counter-party is waiting, the service cannot execute immediately. Your order stays in the book. The service may show you an estimated wait time based on historical order flow, but that estimate is a guess. You can cancel your order at any point before a match occurs. Some services let you set a maximum wait; if the timer expires, the order is removed automatically.

This is where the hub page "Swapping crypto across chains" becomes relevant. That page explains the broader category of swaps that do not rely on a bridge contract or a centralised account. The matching mechanism described here is one concrete implementation of that category.

Why matching is harder than it sounds

Matching two people who want opposite trades sounds simple, but three complications arise in practice.

First, liquidity is thin for most cross-chain pairs. A user who wants to swap USDC on Polygon for ETH on Arbitrum may wait hours or days for someone who wants the exact reverse. The service can only match what exists. It cannot manufacture liquidity.

Second, the timing of on-chain confirmations creates a window of risk. When a match is found, both users must send their assets to each other. The service coordinates the sequence - usually one side sends first, the other confirms, then the first side confirms receipt - but if one user disappears after receiving the other's asset, the trade fails. The refund address mechanism covered in the sibling page "Why do some non-custodial swaps ask for a refund address on the destination chain" exists precisely to handle this failure mode.

Third, the order book must be resistant to front-running and manipulation. A malicious actor could watch the book and submit a matching order only to cancel after seeing the other side's transaction. Services mitigate this by requiring a small deposit or by using time-locked commitments. The details vary by implementation, but the principle is the same: both parties must have skin in the game before the match is finalised.

The honest limitation

A swap service that matches users one-to-one will always have worse availability than a bridge that pools liquidity. You cannot get a match if nobody else wants the trade you want. That is the trade-off for avoiding a centralised account or a bridge contract. The service is a marketplace, not a bank. It can only facilitate what the crowd supplies.

Back to sim swaps