Cross-chain swaps should be one quote, not three

Say you hold a token on Arbitrum and want a different token on Base. On paper that is one trade. In practice it often turns into three: swap into something a bridge can carry, bridge it, then swap again on the other side.

Each of those steps can be done well on its own. The trouble is in the seams between them, and the person doing the trade is the one left to stitch them together.

This is the first post from Cleave Protocol, and it starts with that problem: why a cross-chain swap should be one quote and one flow.

What goes wrong when you stitch it together

You juggle several apps. One app for the first swap, another for the bridge, and a third, or the first one again, for the swap on arrival. Each has its own token list and wallet prompts, and you carry the context between them.

You guess what arrives. The first swap quotes you an amount of the bridge token. The bridge quotes a time and an amount based on that. An estimate for the final swap can change while the bridge is in flight, so the amount of the token you actually want may differ from what you expected at the start.

You may have leftovers to manage. If you do not swap the full amount that arrives, a balance of the bridge token stays on the destination chain, and cleaning it up is one more job.

Fees are spread over three screens. A swap fee here, a bridge fee there, network gas on two chains, maybe a messaging or relay cost. Each screen shows its own slice. Adding them up to see the true cost of the trip is your job, and it is easy to get wrong.

None of this is anyone's fault. It is what happens when one trade is spread across tools that each do only part of it.

One quote for the whole trip

Cleave is a DEX aggregator on Ethereum, Arbitrum, Base, BNB Chain, Polygon and Optimism. When you pick a token on one network and a token on another, Cleave quotes the whole trip in one step: the swap on the way out, the bridge and the swap on arrival.

One quote covers all three parts, and the trip starts with one transaction on the source chain. A token may need an approval first, as with any swap. The tokens on each side do not need to match, because Cleave can swap on either side of the bridge. Depending on the route, the bridge carries USDC, USDT, WETH or WBTC in the middle. Some pairs cannot cross in one go; for those, Cleave offers two steps through USDC on the destination.

Before you sign, you see two things that the stitched approach leaves you guessing:

• The time: how long the route is expected to take, marked "may take longer" when it can run slower.
• The amount that arrives: the expected amount of the token you asked for, on the chain you asked for.

After you send, the transfer shows its stage and roughly how many minutes are left, from sending on the source network through bridging to arrival.

Underneath, Cleave is an aggregator: it searches many pools and can split a swap across several pools and paths when that pays more. The parts of that swap execute together in one transaction.

Routes you can choose from

When more than one route can carry a trade, Cleave lists them so you can compare. Each route card shows its time, the amount you receive, how it is delivered, and price impact when the quote reports it. Open the details on a card and you see each wallet step in order.

Cleave ranks routes by how certain the outcome is, then by speed, then by the amount delivered. You can still pick any of them.

The bridges themselves are third parties, and each route shows its own time before you send. Delivery is stated on the card too: on some routes the tokens arrive with nothing more to do, and on others you finish on the destination yourself.

Fees, in one place

Cleave's fees are included in the amount you receive. Bridge, relay and network costs are shown before you sign.

The seams, handled

A single flow also deals with the awkward cases that the stitched approach leaves to you:

• Unrouted input: if part of your input cannot be routed well, most of it returns to the wallet that paid in the same transaction. Some may come back as a different token.
• Partial bridging: if a route can carry less than you typed, the review screen says how much will bridge, and the rest returns to you on the source network.
• If the swap on arrival can't run: the recipient gets the bridged token instead, and the quote tells you which token that is before you send. On some routes the token is held for the recipient, and Release in Activity sends it on. Activity can also offer Now swap, which opens the swap to the token you wanted.
• If no bridge fills the transfer before it expires, it is refunded to the sender on the source network, as the bridged token. Timing varies, and some refunds need one more step on the source network, which Activity shows.
• Native coins: on routes that support it, you can pay with a network's native coin directly and receive the native coin on arrival. Where a route needs the wrapped token instead, the app says so before you send.

The same engine for agents

People are not the only ones moving tokens between chains. AI agents use the same quote engine through an MCP server and a REST API, and there are packages for the Vercel AI SDK and LangChain. An agent gets the quote as a plan: the calls to sign in order, the expected time for a cross-chain route, and a time after which it should plan again. Routes that need a separate claim step on the destination are left out of agent quotes. The agent docs cover the setup.

Where we go from here

A cross-chain swap is one intention: I have this, I want that, over there. It deserves one quote, a clear time and a clear amount before anything is signed. Coming posts look closer at the pieces: splitting trades, choosing routes, price impact and agents.

Thanks for reading. Cleave is at cleave.fi, and the cross-chain docs explain route selection, delivery and what happens when a transfer needs another step.