Overview
Orders are the fundamental building blocks of trading on CoW Protocol. An order represents an intent to trade one token for another, specifying the terms and conditions of the desired trade.Order Structure
TheOrder dataclass contains all the information needed to describe a trade intent:
Core Fields
sell_token
The ERC20 token address you want to sell. Must be a checksummed Ethereum address.
buy_token
The ERC20 token address you want to receive. Must be a checksummed Ethereum address.
sell_amount
For sell orders: exact amount to sell. For buy orders: maximum amount willing to sell.
buy_amount
For buy orders: exact amount to buy. For sell orders: minimum amount willing to receive.
receiver
Address that will receive the bought tokens. If different from the order signer, tokens are sent here instead.
valid_to
Unix timestamp when the order expires. After this time, the order cannot be executed.
All token amounts in orders are represented as strings to handle large integers without precision loss.
Order Types
CoW Protocol supports two main order types through theOrderKind enum:
Sell Orders
A sell order specifies the exact amount of tokens you want to sell:Sell Order Behavior
Sell Order Behavior
- sell_amount: The exact amount of tokens that will be sold
- buy_amount: The minimum amount of tokens you’re willing to receive
- The order fills if the market can provide at least the
buy_amountfor yoursell_amount
Buy Orders
A buy order specifies the exact amount of tokens you want to receive:Buy Order Behavior
Buy Order Behavior
- buy_amount: The exact amount of tokens you want to receive
- sell_amount: The maximum amount of tokens you’re willing to pay
- The order fills if the market can provide the
buy_amountfor at most yoursell_amount
Order Balance Types
TheOrderBalance enum specifies how tokens are transferred:
Most users should use
OrderBalance.ERC20 for both sell and buy token balances. The Balancer Vault options are for advanced integrations.Partially Fillable Orders
Orders can be configured to allow partial fills:Partially Fillable Behavior
Partially Fillable Behavior
When True:
- The order can be filled in multiple transactions
- Useful for large orders that may not fill completely in one batch
- Each fill reduces the remaining amount
- The order must be filled completely in a single transaction
- This is the fill-or-kill behavior
- Simpler to reason about for most use cases
Order Lifecycle
Order Matching
Solvers compete to find the best execution for orders in a batch auction. They:
- Match orders with each other (Coincidence of Wants)
- Route through DEX liquidity if needed
- Optimize for best prices and minimal slippage
Order Settlement
The winning solver’s solution is executed on-chain, settling all matched orders atomically in a single transaction.
Order UID
Each order has a unique identifier (UID) that combines the order hash, owner, and validity:The order UID is 56 bytes (112 hex characters) and can be used to query order status, track execution, and cancel orders.
App Data
Theapp_data field allows applications to attach metadata to orders:
App Data Use Cases
App Data Use Cases
- Application identification
- Referral tracking
- Order uniqueness (prevent duplicate orders)
- Custom metadata for specialized integrations
Fee Structure
CoW Protocol offers gasless trading where fees are paid in the sell token:The actual execution cost is incorporated into the quoted price. The protocol finds surplus for users and covers gas costs, making trading more efficient than traditional DEXs.
Example: Complete Order Flow
The
swap_tokens function handles the entire order lifecycle: getting a quote, creating the order, signing it, and submitting it to the orderbook.