Why a CoW Swap Order Expires Without Filling

A CoW Swap order expires unfilled when no solver settles it before its signed deadline, called validTo. The order is a message specifying which tokens to trade, in what amounts and at what minimum acceptable price. It is first signed by the trader and submitted to an off-chain order book; the trader’s tokens move only if a solver settles the trade on-chain.

Solvers gather orders into batches and look for trades they can settle against other orders or available liquidity. Each solver proposes a settlement, and the protocol checks that it meets the signed orders’ conditions. The CoW Protocol documentation describes this flow and the limit-price rules. For a fuller account of the order book and auction, see cowswap. If no valid settlement lands before the deadline, the order is no longer executable.

What does the expiry time control?

The validTo field sets the last time an order can be settled. It is part of the signed order data, so the expiry is a condition solvers must respect, not a reminder that the interface sends later. The order identifier also encodes this timestamp, as shown in CoW Protocol’s contract definition.

That deadline gives the trader control over how long a price instruction remains live. A short-lived swap order can go stale quickly if the market shifts. A limit order may remain open longer, but it still ends at its chosen expiry if nobody fills it. Think of it as a signed instruction with a use-by time: after that time, even a matching price cannot make the old instruction valid again.

Why might a solver leave an order unfilled?

A limit price can be reached on a chart without making the order executable. CoW Protocol says its limit orders must cover network costs as well as satisfy the trader’s limit. In practice, the price may need to move further than the displayed market price before a solver can settle the trade economically.

Other conditions can also prevent a fill before the deadline:

• The market moves away from the signed limit, so the order no longer offers terms a solver can execute.
• Available liquidity is too shallow for the order size at an acceptable price.
• Network costs make a small trade or its remaining amount uneconomic to settle.
• A partially fillable order gets some execution, but the leftover amount is too small to cover settlement costs.

Solvers compete to find settlements, but their competition cannot guarantee that any solver will find one. The limit protects the price condition; the expiry limits how long the order waits. Together they trade certainty of execution for control over price and timing.

What should you check when an order expires?

Start with the order’s status and fill history. “Expired” means its deadline passed without a complete fill; it does not by itself mean the wallet transaction failed or that the order was cancelled. Check whether any amount filled, then compare the limit and the interface’s estimated execution price with current market conditions.

If the trade still makes sense, create a new order with a fresh deadline and terms that reflect current prices and costs. Changing the price can make a fill more likely, but it also changes what you are willing to accept. Extending the deadline gives solvers more time; it does not fix an unrealistic limit or thin liquidity.

An unfilled order has not completed an on-chain trade, so the sell tokens were not transferred in settlement. The practical takeaway is straightforward: expiry marks the end of the signed opportunity, while price, liquidity and settlement costs explain why that opportunity may have gone unused.