Cowswap Cowswap solvers can combine matching orders with external liquidity
· last updatedCowswap solvers find liquidity in compatible user orders, decentralized exchange pools, aggregator routes and private market-maker quotes. They compete through CoW Protocol to assemble executable settlements. Matching can cover an entire trade or part of it; any remaining amount needs another available source that satisfies the order’s signed conditions.
Matching Orders and Routing the Remainder
A solver can combine opposing orders with outside liquidity in one settlement, allowing execution even when some orders lack a matching counterparty. A partial peer match can supply some of the required tokens while an external route supplies the remainder, fully executing the user order even though the peer match covers only part.
External liquidity also provides an execution path when no compatible peer match exists. Its available price must fit the order’s signed conditions, including the permitted fill amount. An attractive market price won’t help if the proposed transfers can’t execute. A solver can try another available source if it respects the same order conditions. If no feasible solution respects the order, the auction doesn’t produce that fill.
Where Do Solvers Find External Liquidity?
Solvers obtain external liquidity from decentralized exchange pools, aggregator routes and private market makers, provided those sources offer tokens on terms that the proposed settlement can execute.
Public Pools and Aggregator Routes
The reference driver can prepare Uniswap v2, Uniswap v3 and Balancer v2-family liquidity for solver engines. An engine can also manage its own liquidity integrations. Decentralized exchange (DEX) aggregators supply routes across pools, while automated market makers (AMMs) quote swaps from their available liquidity. The specific pool and requested amount determine the executable quote, so a protocol’s presence alone doesn’t establish sufficient liquidity.
Private Market Maker Offers
Private market makers can provide offers through request-for-quote (RFQ) integrations, which supply terms for specified trades. Maker liquidity can also enter a settlement as a just-in-time (JIT) order that the solver includes in its solution. The maker’s authorization and available funds must support execution.
Direct Matches, Rings and Shared Pool Trades
Order relationships determine how much liquidity a batch can supply internally and how many external interactions remain necessary.
Opposing Orders
A Coincidence of Wants (CoW) occurs when compatible orders exchange the assets that their owners already hold, covering the full required amount or only part. The peer-matched portion avoids the liquidity-provider fee that an AMM swap would incur. Other execution costs can still apply to the settlement.
Intermediate Matches and Rings
Matching can occur along intermediate parts of longer routes, even when the orders have different final buy tokens. Rings connect three or more orders across their desired assets. The solver must balance those token flows and respect each participating order’s terms. Related tokens alone don’t establish an executable match.
Shared Pool Interactions
Same-direction orders can share an external pool trade, reducing repeated contract interactions while still using pool liquidity. It saves execution work even when no opposing user order exists. A batched transaction therefore doesn’t, by itself, demonstrate that the orders exchanged tokens peer-to-peer.
Private Inventory and Settlement Buffers
Liquidity can come from a solver’s own inventory or balances already held by the settlement contract, with distinct authorization, accounting and usage requirements for each source.
Solver Inventory
A solver can act as a counterparty using its own liquidity, including inventory that supports a private offer. Centralized exchanges can also contribute to liquidity sourcing on the solver’s side. The trader’s Cowswap fill still relies on the settlement’s on-chain token movements, so a centralized-market quote alone doesn’t deliver the buy tokens. Compatible routes can also use flash loans with the required borrowing and repayment mechanics.
Restricted Buffer Internalization
Internalization replaces a legitimate, publicly available AMM interaction with settlement-contract balances, saving execution work. Trade internalization requires the token that accumulates in the settlement contract to carry the auction’s trusted designation. Solvers remain accountable for balance changes. Buffer rules also permit offsets for liquidity-source slippage. The accounting separates network fees, protocol fees and partner fees from remaining imbalances, so a balance increase doesn’t automatically represent solver earnings.
Solver Engines and Drivers
A solver engine chooses orders and builds routes, while its driver prepares auction data and turns proposed solutions into executable transactions. The protocol’s autopilot coordinates the auctions. A driver can supply pool data and discard orders with missing balances before route selection. After the engine returns a solution, the reference driver encodes the settlement and simulates it. Liquidity discovery and execution preparation contribute different information: the available trading paths and whether their proposed token transfers can work together.
Why Can a Route With More Liquidity Lose?
A route with more liquidity can lose because execution costs and the auction score determine competitiveness; extra venues expand possible routes without ensuring better executable terms.
Pool fees, price impact and gas consumption affect the amount that a route can deliver. Splitting a trade across pools can reduce price impact while adding contract calls, so a solver weighs the output gained from another source against the cost of using it. Shared interactions can lower those costs across compatible orders.
Routing and bidding also involve different calculations. The protocol scores user surplus and protocol fees in a common value unit. Surplus measures improvement over the order’s limit terms; it isn’t simply the difference from an earlier quote. Solver rewards needn’t cover all execution costs, giving the solver an incentive to estimate and account for those costs accurately.
Price Limits and Fair Auction Selection
The signed limit price constrains which liquidity routes a solver can propose. The settlement contract enforces each order’s signed limit price. Auction rules add Uniform Directional Clearing Prices: orders in the same solution that trade the same pair in the same direction receive a consistent clearing price. Hooks can justify deviations to account for extra gas costs. The rule doesn’t impose one price across separate solutions.
The fair combinatorial auction compares bids for individual directed token pairs before considering combined bids. A combined bid must meet the reference score for each directed pair that it includes. The protocol selects a compatible set of winning bids, allowing multiple solvers to execute different winning solutions from the same auction.
Liquidity Changes During the Auction
Auction requests and winning settlements have deadlines that constrain computation and execution. The network and auction configuration determine the applicable windows. Pool reserves, gas prices and private quote availability can change during them, so the reference driver checks whether a winning settlement still works as it attempts submission. A route that simulated successfully earlier can become invalid before blockchain inclusion.
Computing a route, winning the auction and settling the trade are distinct states. Only successful execution establishes the token exchange.
A Partial Match With a Changing Pool Quote
In this hypothetical case, a sell order requires a full fill and has enough sell tokens, valid authorization and spending permission. Its minimum buy amount, opposing-order contribution and pool quote are assumed inputs. Opposing orders cover part of the trade, while the pool quote supplies a route for the remainder.
The solver compares the tokens available from matching and the pool route with the buy amount required by the order. It checks that the proposed settlement delivers that amount after applicable fees. The signed price boundary stays fixed for this order; the pool quote can change. After a bid wins, the solver must preserve its promised execution amounts even if the pool quote worsens.
A successfully simulated route that satisfies the order and auction rules can enter the competition as a candidate. A winning candidate that then executes successfully produces a full fill. The settlement record confirms the sold and received amounts, even though external liquidity supplied only the unmatched portion.
If a later pool quote pushes the proposed output below the signed minimum, that version of the route can’t execute the order. The solver can seek another feasible source while time remains. If no feasible replacement works before bidding, the solver discards this candidate. Another valid winning solution may still fill the order. If the solver has already won and can’t settle by the deadline, the order remains unfilled in that auction and the solver may incur a penalty. A smaller fill can’t satisfy the order’s full-fill terms.
Settlement Records and Liquidity Attribution
CoW Explorer shows an order’s filled amounts alongside its settlement by combining order-book information with on-chain execution data. An order identifier locates the trading instruction. The settlement transaction records execution. Its contract calls can identify external pools or other liquidity interactions. Solver competition data supplies the winning proposals and their scores.
A settlement can contain multiple orders whose token flows share external liquidity, so its calls need interpretation alongside the traded amounts. Any centralized trading outside that settlement won’t appear as a separate on-chain pool interaction.
Pool-call counts don’t reveal how much of an order matched peer-to-peer. Private maker orders and permitted internalization can also supply tokens without a pool swap. The settlement’s orders, executed amounts and token movements distinguish these liquidity paths.
What readers ask about Cowswap solvers
Does the Solver That Supplies My Quote Necessarily Settle My Order?
For an order that enters the batch auction, the quoting solver isn’t guaranteed to settle it. Price estimation and settlement competition serve separate purposes. The auction evaluates executable solutions using its eligible orders and liquidity state. Another solver can win the relevant settlement bid, even when the original quote helped establish the order’s trading terms.
Why Must a Solver Be Bonded If It Uses Public Liquidity?
Solver bonding addresses the authority to submit settlements and interact with settlement-contract funds. Public access to an AMM doesn’t confer that authority. Production participation requires registration, authorization and backing from a bonding pool, which can be an existing pool or one the solver establishes. The bond supports accountability for misconduct. The openness of the liquidity source and admission to the solver competition are separate requirements.
Can a Solver Use Liquidity Missing From Its Auction Input?
A solver may use additional liquidity beyond the sources supplied in its auction input. The supplied pool data helps engines construct solutions, but it doesn’t define an exclusive venue list. Additional integrations must still produce executable interactions and satisfy the order conditions and competition rules. Each solver’s integrations determine which extra sources it can access.
Will a Smaller Order Always Give Solvers a Cheaper Route?
A smaller order can reduce pool price impact without ensuring cheaper execution overall. Contract calls still consume gas, and fixed execution work can represent a larger share of a smaller trade. Available opposing orders can also change the route. The relevant comparison is the executable output after the costs that apply to that order.
Which JIT Orders Contribute Surplus to the solver’s Auction Score?
JIT orders from the protocol’s designated surplus-capturing owners contribute their surplus to the auction score. Ordinary maker JIT orders don’t receive that treatment. The auction identifies eligible owners, and the associated liquidity contract must accept the proposed trade. Private inventory alone doesn’t establish eligibility for surplus scoring.
Can Solvers Use Flash Loans to Supply Settlement Liquidity?
Compatible solver routes can use flash loans when the borrowing, settlement and repayment execute within the same transaction. The loan needs a supported lender integration and the appropriate loan-router path. The solver must account for when borrowed funds become available and ensure repayment. Loan overhead adds execution costs without removing the order’s signed price constraint.
In Which Token Are Solver Performance and Quote Rewards Paid?
CoW Protocol pays performance and quote rewards in COW. Their accounting starts with values in the network’s native token before conversion. Performance rewards concern auction outcomes, while quote rewards follow separate rules for qualifying price estimates. The reward denomination is separate from the tokens exchanged in a user’s order.
Must Every Solver Implement peer-to-peer Matching?
A solver can produce valid solutions using external liquidity without finding a peer match. The reference baseline engine solves individual orders through supplied on-chain liquidity and doesn’t create Coincidences of Wants. Its narrower algorithm doesn’t restrict what other engines can do. A proposed solution must satisfy the applicable execution and auction rules.