How do peer-to-peer order books settle cross-chain trades

05 September 2026

They settle by splitting one trade into two independent swaps, each on its own chain, and using the order book only as a matching layer. No single transaction ever moves value across chains; instead, the peer-to-peer book finds two parties who want opposite things, then each side executes a normal on-chain swap in their own asset.

The mechanism relies on a simple observation. Every cross-chain swap is really two trades. Party A wants to sell token X on chain 1 for token Y on chain 2. Party B wants the reverse. If both agree on a rate, A can send X to B on chain 1, and B can send Y to A on chain 2. The order book does not hold either asset. It only records intent and matches the two sides.

Where the order book fits

The book is a database of open orders. Each order states an asset, an amount, a desired counterparty asset, and a rate. Orders are grouped by trading pair, but the pair is not a single token pair on one chain. It is a cross-chain pair, such as "ETH on chain A for BTC on chain B." The book matches a bid on one side with an ask on the other.

Matching is not settlement. When two orders match, the book does not execute anything. It simply introduces the two parties to each other. Settlement happens afterward, directly between the two wallets, using standard on-chain transfers or smart contracts on each chain. The book's job ends at the introduction.

The settlement step by step

Once matched, both parties must perform their half of the trade. There is no built-in atomicity across chains. That is the core difficulty. On a single chain, a smart contract can hold both assets and release them together. Across chains, no single contract controls both ledgers. So the parties use one of two patterns.

The first pattern is sequential. Party A sends X to B on chain 1. B waits for confirmation, then sends Y to A on chain 2. This works, but it requires trust. B can see A's payment and still refuse to send Y. To reduce that risk, parties often use a time-locked escrow on each chain. A deposits X in a contract on chain 1, with a condition: B can claim X only by revealing a secret. B then deposits Y in a similar contract on chain 2, using the same secret. Once A claims Y, B can claim X. The secret links the two contracts. This is the hash-time-locked contract pattern.

The second pattern uses liquidity providers. A matched order may not find an exactly opposite order. Instead, the book matches A with a provider who holds Y on chain 2 and wants X on chain 1. The provider takes A's X, then sends Y from their own reserves. The provider's inventory rebalances over time as they take many trades. This is faster, but the provider bears inventory risk. The order book simply routes A to the provider who quotes the best rate.

What can go wrong

The sequential pattern has a failure mode. If B never reveals the secret, the time-lock expires and both deposits are refunded. No one loses value, but the trade fails. The provider pattern has a different risk. The provider might not send Y after receiving X. Reputation and collateral help, but neither is foolproof. Any cross-chain settlement without a bridge contract inherits these risks. The order book cannot eliminate them. It can only make them explicit in the order terms.

Where this fits

The hub page on swapping crypto across chains covers the broader trade-offs between bridges, centralised accounts, and this peer-to-peer route. This order-book method is one way to avoid both a bridge contract and a custodial account. It is not the only way, and it is not always the cheapest. But it is the one that keeps settlement on the chains themselves. If you want to see how a single swap plays out in practice, the sibling page on what a swap looks like when no bridge contract holds your coins walks through the exact sequence.

Back to sim swaps