Skip to main content

Overview

Orders form the foundational elements of trading on CoW Protocol. They represent an intent to exchange one token for another, establishing specific terms and conditions.

Order Structure

The Order dataclass contains essential information describing a trade:

Core Fields

Token amounts use string representation to prevent precision loss with large integers.

Order Types

CoW Protocol supports two primary order types via the OrderKind enum:

Sell Orders

Sell orders establish a fixed amount of tokens for sale:
Sell Order Mechanics:
  • sell_amount: Represents the precise quantity being sold
  • buy_amount: Establishes the minimum acceptable receiving quantity
  • Execution occurs when market conditions can provide at least the minimum buy amount for the specified sell quantity

Buy Orders

Buy orders specify a fixed amount of tokens for acquisition:
Buy Order Mechanics:
  • buy_amount: Represents the precise quantity being acquired
  • sell_amount: Establishes the maximum acceptable payment quantity
  • Execution occurs when market conditions can provide the specified buy amount within the maximum sell quantity

Order Balance Types

The OrderBalance enum determines token transfer mechanisms:
Always use OrderBalance.ERC20 for both balances. On most networks (Ethereum mainnet, Gnosis Chain, Arbitrum, Base), the Balancer Vault contract has a compromised admin key, meaning INTERNAL and EXTERNAL balance types may expose users to risk. The CoW Protocol API rejects orders using these balance types on affected networks. Only use Vault balance types after verifying the Balancer deployment is safe on your target network.

Partially Fillable Orders

Orders permit configuration for partial execution:
When enabled:
  • Orders can execute across multiple transactions
  • Beneficial for sizable orders potentially unable to fill completely in a single batch
  • Each execution reduces remaining amount
When disabled (default):
  • Complete execution within a single transaction required
  • Fill-or-kill execution model
  • Simpler logic for most scenarios

Order Lifecycle

1

Order Creation

Users establish orders expressing their trading intent, then sign via EIP-712:
2

Order Submission

The signed order transmits to the CoW Protocol orderbook API:
3

Order Matching

Competing solvers discover optimal execution through batch auction mechanisms, including:
  • Direct order matching (Coincidence of Wants)
  • DEX liquidity routing when necessary
  • Price optimization and slippage minimization
4

Order Settlement

The selected solver’s solution executes on-chain, atomically settling all matched orders within a single transaction.
5

Order Completion or Expiry

  • Filled: Order executes successfully; tokens transfer
  • Expired: The valid_to timestamp passes without execution
  • Cancelled: The user explicitly revokes the order before execution

Order UID

Each order receives a unique identifier combining the order hash, owner, and validity:
The order UID measures 56 bytes (112 hexadecimal characters) and facilitates order status queries, execution tracking, and cancellation operations.

App Data

The app_data parameter permits applications to embed metadata within orders:
App Data Applications:
  • Application identification
  • Referral monitoring
  • Order uniqueness verification (duplicate prevention)
  • Specialized integration metadata
The app data undergoes hashing to a 32-byte representation and may reference IPFS content for expanded metadata.

Fee Structure

CoW Protocol enables gasless trading with fees denominated in the sell token:
Execution expenses integrate into the quoted price. The protocol identifies user surplus and subsidizes gas expenses, delivering superior efficiency compared to conventional DEXs.

Example: Complete Order Flow

The swap_tokens function manages the complete order lifecycle, including quote retrieval, order creation, signing, and orderbook submission.
Last modified on March 12, 2026