← All posts

Only USDC crosses, and it takes fifteen minutes

Most plans span more than one chain without mentioning it. Two constraints shape every one, and both surprise people.

Architecture3 min readDeFiLoops

“My wallet holds $1,000 USDC on Base, $1,000 on Ethereum and $1,000 on Arbitrum. Lend each one to a lending pool.”

“Take $100 USDC on Base and buy XAUT from Ethereum.”

Both are real requests. Neither mentions a bridge. The first does not need one; the second cannot avoid one. Telling those apart is most of what happens between your sentence and a transaction, and two constraints decide the shape of the answer.

Constraint one: only USDC crosses

The crossing in the catalogue is Circle’s CCTP, and CCTP carries USDC. Not WETH, not cbBTC, not tokenized gold.

That single fact rewrites plans. Take the gold request: you have dollars on Base, you want an asset that lives on Ethereum. There are two shapes available in principle —

Before

Swap USDC to XAUT on Base, then move the XAUT to Ethereum.

Cannot be expressed. There is no crossing for XAUT, so this plan is refused when it is written.

After

Move the USDC to Ethereum, then swap there.

The only shape that exists, so it is the one you get — whether or not you thought about it.

Constraint two: fifteen minutes, and it cannot be hurried

A crossing is not a transaction that takes a while. Value leaves one chain, time passes, and value arrives on another. About fifteen minutes, set by Circle, not by us.

Everything downstream follows from that.

What the wait does to a plan
Steps on the far side cannot start early
The plan is built around the gap rather than hoping
A runtime amount cannot cross it
A step after a bridge cannot spend “whatever the swap returned” — the two are in different transactions on different chains
The run has to survive it
Fifteen minutes is long enough for us to ship an update mid-run, so progress lives in a database, not in a process’s memory
Bridges go last where possible
Everything that can be done on one side is done before the wait, not after

What the ordering actually does

Given those two constraints, a multi-chain plan is not “the steps you listed, in the order you listed them”.

Take the three-wallet request at the top. Nothing about lending on Base depends on lending on Arbitrum, so those do not queue — they run at the same time. No crossing is needed at all, because the money is already where it needs to be. The right plan for that sentence has no bridge in it, and a system that assumed “multi-chain means bridging” would have added three unnecessary crossings and charged you for them.

Now take a plan that does need to cross:

  1. Fold what can be folded

    Steps that can share a transaction are merged. “Approve, then supply” as one transaction means the approval cannot outlive a supply that failed.

  2. Cluster by chain

    Everything doable on Base is grouped, so the plan crosses as few times as it can.

  3. Put the crossings late

    A crossing is the slowest and most expensive step. Anything that can happen before the wait, does.

  4. Break where value cannot be carried

    Where a runtime amount cannot survive to the next step, a new transaction starts. The board shows that as a dotted line before you approve it.

What it costs

Flat, which matters more than the percentage.

$0.50
per crossing
Flat, regardless of size.
0.1%
crossing fee
Of the amount sent.
~15 min
per crossing
Set by Circle. Cannot be hurried.

Because the fee is flat, it dominates a small plan and disappears in a large one. Three crossings on a $1,000 plan is $1.50 of bridge fee — about 0.15%, which is a month of yield on a lending position. The same three crossings on $100,000 are 0.0015%, and by then slippage on the swaps matters far more than the bridges do.

Ask before you plan

Because the constraints are specific, “can I do this?” is usually really “can I do this on that chain?” — and those have different answers often enough to matter.

Asking which assets, chains and operations exist costs nothing and takes one question. It is a much better use of thirty seconds than discovering the answer from a validation error after you have written the plan.