Cow swap
Cow swap connects signed token orders with competing solvers.
Cow swap lets you exchange tokens by authorizing trading conditions that competing solvers try to satisfy through CoW Protocol. Solvers are execution services that find liquidity and submit settlements. A signed order can wait for execution, expire or fill under its permitted conditions. Market orders, limit orders and scheduled TWAP orders provide different controls over timing. Cross-chain swaps also require destination delivery before the exchange is complete.
The short version: A signed order authorizes execution within its terms; completion requires a settlement record and the corresponding token delivery.
Liquidity and token compatibility
Available liquidity determines whether a solver can exchange your selected amount within the price you accept. Solvers can match opposing orders directly, use external liquidity or combine both. Direct matching avoids liquidity-pool interactions for the matched portion. An order doesn’t need an exact opposing trade because solvers can source the remainder elsewhere. That flexibility broadens execution options without guaranteeing a fill.
Token behavior also affects execution. The selected sell token must support the required transfer, and the spending account needs sufficient balance and authorization. A recognizable ticker doesn’t establish that those conditions hold. The token contract and selected network identify the asset that the order actually exchanges. Transfer restrictions, insufficient allowance or a changed wallet balance can prevent an otherwise attractive order from executing.
Market, limit and scheduled orders
The order type determines which trading condition takes priority. A market order seeks execution against a reviewed quote. A limit order holds a price boundary while waiting for suitable liquidity. TWAP, meaning time-weighted average price, spreads an order across scheduled parts.
| Order choice | Execution control | Timing condition |
|---|---|---|
| Market swap | Reviewed quote with a minimum acceptable output | Execution must occur within the order’s validity |
| Limit order | Specified price or better; partial fills can be enabled | May remain open until filled, canceled or expired |
| TWAP order | Scheduled parts with price protection | Part duration follows total duration divided by the number of parts |
A limit price becoming visible in the market doesn’t automatically trigger settlement. Execution must also accommodate network costs and available liquidity.
TWAP requires a compatible Safe wallet configuration. Its schedule determines when parts become available, while price protection constrains their execution. Splitting a trade can reduce its immediate market impact, but market movement during the schedule can still worsen the eventual average price. A completed early part doesn’t establish completion of the remaining schedule.
How do solvers turn orders into settlements?
Solvers construct competing settlement proposals from signed orders, and CoW Protocol selects a combination of winning bids through fair combinatorial batch auctions. A bid can cover an individual order or a group. This allows the protocol to consider shared liquidity opportunities without requiring one solver to execute every order in an auction.
The settlement contract checks the authorization and trading constraints before completing a trade. The settlement contract requires execution prices to meet or improve upon the prices specified in the signed order. It also checks expiration and whether the order has already filled. These checks constrain what a solver can execute; they don’t promise that a suitable settlement will become available.
Quotes and minimum output
The expected output is the quote’s estimate, while the minimum output expresses the accepted lower bound for a sell order. Slippage tolerance permits a defined amount of adverse movement between quoting and execution. A wider tolerance accepts a worse possible exchange rate; it doesn’t create liquidity or guarantee faster execution. The bound concerns token quantities, so it doesn’t guarantee their later value in another currency. Review the quoted amounts and slippage together before authorizing the order.
What does the wallet signature authorize?
The order signature authorizes a trade with specified tokens, amounts, recipient and validity conditions. Spending approval supplies a separate permission that lets the protocol transfer the sell token.
For ordinary ERC-20 allowance-based orders, GPv2VaultRelayer is the spending contract. The settlement contract uses this relayer to collect tokens under the signed order’s constraints. Solvers don’t receive an unrestricted allowance to move assets themselves. That separation explains why both the approval’s spender and the order’s contents matter. A legitimate protocol design cannot correct an approval that names an unrelated spending contract.
The recipient deserves a separate check because a valid signature can authorize delivery to another address. Submitted order parameters cannot simply be edited in place. Corrections require cancellation and a replacement order, with cancellation subject to execution timing. Keep changes in the unsigned review stage when backing out must remain certain.
Native-token orders and upfront transactions
Selling a chain’s native token uses a different entry path because native tokens don’t provide ordinary ERC-20 allowances. The interface supports wrapping before trading or using Eth-flow, which wraps funds and places an order through an on-chain transaction. Eth-flow therefore incurs an upfront gas cost, even if the subsequent order doesn’t fill. Its confirmed placement transaction establishes that an order exists, not that the output token has arrived. The documented interface limits Eth-flow to market swaps and excludes smart contract wallets from that path. Eth-flow orders require on-chain cancellation, which costs gas and can lose a race against settlement.
Cross-chain delivery after the source swap
CoW Swap’s documented cross-chain flow exchanges a source-network token for a different destination-network token through a swap followed by bridging. This flow excludes bridging the same token between networks. Available destinations depend on the source selection and bridge support. A destination token’s identity includes its network.
The quote distinguishes the swap minimum, bridge cost and destination minimum. It also provides an estimated bridging time. That estimate depends on the provider and route. Before signing the order, review and sign the post-hook that authorizes the Account Proxy, a helper contract, to deposit the swap output with the bridge provider. Source settlement starts the bridge stage; destination delivery completes the requested transfer. Neither a source transaction nor an intermediate balance alone proves that the recipient received the final asset.
Once the swap executes and the Account Proxy submits the bridge deposit, the transfer cannot be canceled. It must complete or follow the provider’s refund policy. Some unsuccessful transfers return funds to the Account Proxy, where recovery to the wallet may be necessary. A swap that expires or cancels before execution doesn’t begin bridging.
MEV protection during execution
Delegated execution reduces a trader’s direct exposure to public-mempool attacks because solvers submit the settlement transaction. Maximal extractable value, or MEV, includes profits obtained through transaction ordering, such as sandwich attacks. Direct order matching avoids pool interactions for matched liquidity, while uniform directed clearing prices remove ordering advantages among equivalent directed trades within the auction. These mechanisms address execution-related exploitation. They don’t prevent ordinary market movement or make an unfavorable signed price favorable.
When can a pending order still execute?
A pending order can execute while its authorization remains valid and a settlement satisfies its conditions. A cancellation request doesn’t instantly remove that possibility.
Off-chain cancellation asks the order service to stop considering the order. On-chain cancellation invalidates it through a transaction and costs gas. Both can lose a race against settlement. A displayed cancellation request therefore isn’t equivalent to a confirmed cancellation. Expiration also prevents future execution, but it doesn’t reverse trades that already filled. Before replacing an order, establish its final state so the replacement doesn’t overlap with an execution already underway.
Filled orders and received balances
Completion rests on the executed order and its corresponding output. CoW Explorer combines order-book information with settlement data, so an order identifier and a transaction hash serve different purposes. The identifier tracks the order; a settlement hash identifies an on-chain execution.
The order record shows its status, sender, recipient and executed quantities. For partially filled orders, individual fills explain how much actually traded. Match those quantities to the relevant recipient’s token transfers and balance on the selected network. A wallet’s overall balance can also reflect unrelated transfers, so the balance alone doesn’t attribute an amount to this exchange.
An open order isn’t spendable output. Continue with an action that needs the bought token only after the recipient actually holds the required amount.
What readers ask about Cow swap
Does closing the browser stop a submitted order?
Closing the browser doesn’t cancel an order that the protocol has already accepted. The signed authorization exists outside the browser session, and solvers can continue considering it while it remains valid. Returning to the interface lets you inspect its status; a deliberate cancellation is a separate action.
Why can a limit order leave some sell tokens untraded?
A partially fillable limit order can execute in portions and leave a remainder. The remaining amount still needs suitable liquidity and execution economics. Network costs can make a small remainder impractical to settle, even after earlier portions filled. The executed amount establishes what traded; the original order amount doesn’t.
What does a TWAP order’s signing state mean?
A TWAP order in signing state may still need additional Safe signatures before activation. Collecting the required signatures and executing the activation transaction are prerequisites for the schedule to become active. An initial submission confirmation doesn’t establish that those prerequisites are complete.
Where are native tokens held while an Eth-flow order waits?
Eth-flow places the native tokens into its contract before the trading order executes. This explains why the native balance can decrease before bought tokens arrive. If the order fails, the deposited amount can be refunded, but the gas spent on the placement transaction isn’t refundable.
Are trades hidden from public view by MEV protection?
MEV protection doesn’t make settled trades confidential. Order records can expose the signing address, recipient, executed amounts and settlement transaction. Avoiding direct exposure to certain transaction-ordering attacks is different from concealing wallet activity. The public execution record remains useful for confirming what the exchange delivered.
How should fees be reconciled with the displayed sell amount?
The explorer’s executed sell amount includes the order fee, so adding that fee again would double-count it. Separate order fees from any additional on-chain actions, such as an approval transaction. Partially filled orders can show accumulated fees as their fills progress.
Is a gasless approval available for every wallet and token?
Gasless approval requires a compatible token and supported wallet flow. The documented swap interface supports it for eligible swap and limit orders, while excluding smart contract wallets from that approval feature. A gasless order signature doesn’t establish that the preceding token approval is also gasless.
· updated