How Order Deadlines Shape Solver Participation

Order deadlines shape solver participation by deciding which trades are eligible, how long an order can return to an auction, and how much time a solver has to submit a valid solution. A user signs an order with conditions such as a limit price and expiry. The protocol groups eligible orders into an auction, and solvers look for ways to fill them using other orders or available liquidity. The winning solution must meet the protocol’s rules and settle before its deadline.

How does an order’s expiry affect solver eligibility?

An order’s expiry determines how long it remains eligible for inclusion in auctions. Before each auction, the protocol checks whether the order is still valid; once it expires, a solver cannot include it in a new solution. An unfilled order can therefore give solvers more than one chance to find a suitable route, as long as it remains valid. The cowswap guide explains order types in more detail, including how their conditions affect execution.

This changes the pool of trades a solver can consider. A longer-lived order may meet another order in a later batch, creating a direct token swap that avoids some outside liquidity. Or it may become fillable when market prices move within the user’s limit. Expiry does not promise execution; it sets the last point at which the protocol can consider the order.

Order type matters here. A fill-or-kill order must be filled as specified in a valid execution or it remains unfilled, subject to its conditions. A partially fillable order can be filled in pieces across auctions. That flexibility can make it easier for a solver to combine the order with the available liquidity in one batch, while the user retains the unfilled amount for a later opportunity.

Why does a solver’s deadline change which solutions it submits?

A solver has a separate, block-based deadline to return a solution for an auction and have the settlement executed. It receives a batch of eligible orders, checks possible order combinations and liquidity routes, calculates prices, and submits bids. The protocol compares valid bids under its auction rules, then the selected solution must settle by the deadline.

Think of the deadline as the closing time for a live trading desk: a route that looks attractive still has to be priced and submitted before the window closes. A solver must weigh possible user surplus against execution costs, including gas, while checking that prices meet each order’s limit. More combinations can reveal a better batch trade, but they also take time to evaluate. A solver may submit a strong, simpler solution rather than risk missing the window while exploring a more complex one.

So the solver’s deadline shapes participation through practical constraints:

• Search time: more candidate orders and liquidity routes require more evaluation before submission.
• Execution certainty: a solution must remain feasible until the settlement transaction runs.
• Batch composition: the solver may prefer a smaller set of orders if it can price and settle them reliably within the window.

What happens when an order is near expiry?

A near-expiry order has fewer future auctions in which it can be matched, but its deadline does not give it priority in the current auction. Solvers still assess whether including it can produce a valid, competitive solution. If the order’s price is outside the available market, or a route cannot be assembled in time, expiry alone will not make it executable.

The distinction between the two clocks matters. The order expiry controls future eligibility; the auction deadline controls the time available to submit and execute a solution. A solver can act only when both conditions line up: the order is still valid, and the solution can meet the auction’s execution rules before its deadline.

For users, a longer expiry can preserve the chance of execution across more auctions, while a shorter one limits how long the order remains available. For solvers, each valid batch is a time-limited search across orders and liquidity. The practical takeaway is to treat expiry as the lifespan of the opportunity and the auction deadline as the solver’s execution window.