This post aims to summarize our current thinking around how CoW Protocol can function in a cross-chain swap world.
Currently, CoW Protocol runs completely separate batch auctions, one on each chain. While this is great for aggregating fragmented liquidity on a single chain (e.g. ring trades across different stable coin currencies or by finding coincidences of wants), it doesn’t allow for any efficiency gains or access to the solver competition for cross-chain swap. In fact, the swap & bridge feature that is currently being worked on is limited to performing a swap on one chain and then using an external bridge provider to perform the bridging.
We are already working towards implementing “combinatorial auctions” which will allow multiple winning settlements to be selected per auction. A natural next step would be to aggregate all chain-specific orders and orderbooks into a single, unified multi-chain auction Since in this phase each order itself is still “single-chain”, efficiency gains are limited. However, there might be a solver willing to take an A → B trade on Mainnet and another B → A on Base if they are sure to win both trades and thus can limit their exposure to inventory risk.
From this point we can start allowing users to specify their cross-chain order intents with different source and target chains. Initially, cross-chain orders can only be bid on in isolation, that is a solver cannot bid on a bundle of cross-chain orders yet.
Solvers would either have to be sufficiently bonded – ie. today’s bond + some factor >1 of the trade’s sell amount (the Kinetex model) – or would only receive the sell tokens once the trade has been confirmed on the target chain (the Across model).
Solvers would be free to choose whatever bridging solution they like. Further research needs to be done on how “time preference” (fast vs. slow bridging) needs to be part of the user’s order intent.
Eventually the holy grail will be to allow for cross-chain batching. Already at the previous stage, a winning solution will consist of multiple settlement transactions (e.g. one for each chain) exposing the risk of a “partial settlement failure”.
We believe it is important to guarantee trade atomicity to users in that they either receive the desired buy token on the target chain or are left un-executed with the original sell amount on the source chain. This requirement already rules out certain solutions. For example, i a solution that consists of the following two sub-settlements:
- [Mainnet] Trade USDC for Shiba Inu on Uni v2
- [Base] Trade Shiba Inu for WETH on Aerodrome
Is problematic because, if the first transaction succeeds but the second fails (e.g. because liquidity vanishes), we would have to revert the first transaction. However, this may no longer be possible at this point (if liquidity vanished there as well) and we’d be left with some inconsistent intermediate state.
However, if we try to identify whether each sub-settlement transaction is “fallible” (ie there is a chance the transaction reverts) and/or “reversible” (meaning a transaction that reverses the effect of this transaction is itself not “fallible”), we can define the following rules about the order of transactions on different chains to ensure atomicity of the cross-chain settlement:
- There can be at most one fallable and not reversible transaction per solution (yes, no).
- A fallable transaction (yes, _) can have only reversible transactions (_, yes) before it.
Examples for fallible transactions include:
- Putting funds under resource lock (the owner may have spent them in the meantime)
- Trading against permissionless liquidity (price may change or liquidity may disappear)
Whereas examples for infallible transactions are:
- Moving funds out of resource lock to a user
- Matching a liquidity with (resource locked) inventory
Examples for reversible transactions are:
- Putting funds under resource lock (the funds can be refunded without risk of failure)
- Matching liquidity with inventory (assuming original proceeds were resource locked)
Whereas examples for irreversible transactions are:
- Trading against permissionless liquidity (the inverse trade may no longer be possible at the same price)
- Sending funds out to a user (who could then immediately spend them)
With this classification in mind, a solution can then be executed step by step, ensuring that even if one step fails the initial state of the trade can be recovered.
Let’s look at an example with the following two orders:
- Trader A: Sell USDT on Mainnet for ETH on Base
- Trader B: Sell Uni on Base for USDC on Mainnet
Let’s further assume the solver has sufficient stablecoin inventory (USDC, USDT) on mainnet.
Example of a valid settlement for the following two trades:
| Step | Chain | Description | fallible | reversible |
|---|---|---|---|---|
| 1 | Mainnet | Put Trader A’s USDT under resource lock | yes | yes |
| 2 | Mainnet | Put the solver’s USDC under resource lock | yes | yes |
| 3 | Base | Swap Trader B’s Uni for ETH on Uniswap | yes | no |
| 4 | Base | Send ETH to Trader A | no | no |
| 5 | Mainnet | Send USDC to Trader B, USDT to solver | no | no |
Example of an invalid settlement
| Step | Chain | Description | fallible | reversible |
|---|---|---|---|---|
| 1 | Mainnet | Put Trader A’s USDT under resource lock | yes | yes |
| 2 | Base | Swap Trader B’s Uni for ETH on Uniswap | yes | no |
| 3 | Mainnet | Swap Trader A’s USDT for USDC on Curve | yes | no |
| 4 | Base | Send ETH to Trader A, USDC to solver | no | no |
| 5 | Mainnet | Send Trader B USDC | no | no |
In the second example, if step 3 fails, we can potentially not unwind all prior steps (in particular liquidity for step 2 may no longer be available), which would break the atomicity of the settlement.
Classification and co-signing of sub-transactions – i.e. releasing a signature for the next step only after the previous step is considered sufficiently final – could either be done by a central auctioneer or by a decentralised set of bonded validators (using threshold encryption).
Other protocols seem to tackle the issue of multi transaction “atomicity” by merely requiring all trades to happen through solver inventory (which is “infallible”).
However, we believe that one of the biggest challenges for cross-chain swaps today and in the future is going to be limited solver inventory. Offering inventory for the top 50 tokens on the top 10 chains for sufficient trade sizes is a task only very few TradFi players, and even fewer DeFi players, would be able to solve. Therefore we think that allowing access to permissionless liquidity (e.g. using a Uniswap pool inside a settlement) plays a big role in bootstrapping an efficient matching competition.
An example scenario (similar to the example above) that would be possible in our model without any inventory is:
- Trader A: Sell USDC on Mainnet for ETH on Base
- Trader B: Sell Uni on Base for USDC on Mainnet
A valid solution would:
- Resource-lock Trader A’s USDC on Mainnet
- Sell Trader B’s UNI for ETH using an AMM on Base and send it to Trader A
- Send resource-locked USDC to Trader B
Our model still allows at least one permissionless liquidity pool to be used per settlement, which can dramatically improve the access to long tail tokens (via AMMs) while keeping solver liquidity needs reasonable. Moreover, as can be seen in the example, traders willing to swap “in the other direction” can be matched together in a single settlement further decreasing the need for solver owned liquidity.
Like most other cross-chain protocols, we believe that it will be important to additionally get passive liquidity from users to help “lubrify” the cross-chain routes. This is where coincidences of wants (CoWs) via long standing limit orders can excel. With the rise of account abstraction, one can imagine a good subset of users that is willing to express an intent such as “I trust Ethereum, Arbitrum and Base, and I don’t care on which chain I hold my USDC”. This can be translated as “Swap USDC 1:1 between all those chains” (with the expectation of a small surplus). A service that CoW Protocol’s batch auction and fair uniform price finding is in a unique position to perform.