DEX essentials

How a DEX limit order sets its exchange rate

Learn how token amounts, expiry and fulfillment rules encode a DEX limit order without guaranteeing a fill.

A DEX limit order authorizes an exchange only on specified price terms and other conditions. It can remain available until filled, cancelled or expired, depending on the protocol. It is not a promise that someone will execute it.

Two amounts can encode the price

Suppose a hypothetical sell order offers 100 A for at least 250 B. Its minimum exchange rate is 2.5 B per A. A fulfillment must meet the order's price and size rules; simply finding any buyer for A is insufficient.

0x's order specification illustrates this through maker and taker token amounts plus fields such as expiry. CoW's limit-order documentation describes a different intent-based implementation. Their details should not be assumed interchangeable.

What the order leaves undecided

The signed price can leave route selection and timing to an executor. A solver might use one pool, multiple pools or compatible counterparties. The user has specified acceptable terms rather than necessarily selecting each operation.

Whether a better available price reaches the user depends on the settlement and fee design. A fixed maker offer and an outcome-based intent can distribute improvements differently. Check the protocol's actual rules rather than assuming every product interprets “limit” identically.

What must remain true

An outstanding order may still need sufficient balance and valid transfer permission at fill time. It also needs eligible liquidity and someone able and willing to submit a compliant fulfillment. A chart showing a matching reference price does not establish all these conditions.

Partial-fill permission is another independent choice. If allowed, a portion of the order can execute while the remainder stays open. If the order requires full fulfillment, a smaller available match may not be usable.

For a clear record, preserve the exact asset identities, amount ratio, remaining size, expiry and fill policy. Those define the order much more accurately than a screenshot containing a target price alone.

Sources & verification (3)

Source-check date is recorded in the article details. URLs are provided for manual verification. Use Copy to keep this page open.

  1. Orders — 0x Protocol 4.1 documentation

    Version-specific order fields: token identity, amounts, maker/taker, expiry and RFQ.

    https://docs.0xprotocol.org/en/latest/basics/orders.html
  2. Limit orders

    Limit price, expiration and partial fill concepts.

    https://docs.cow.fi/cow-protocol/concepts/order-types/limit-orders
  3. Basic Functionality — 0x Protocol 4.1 documentation

    Fill, fill-or-kill, cancel and status checks in versioned 0x Exchange Proxy.

    https://docs.0xprotocol.org/en/latest/basics/functions.html

Continue reading

A limit price is not a stop-loss trigger Fill-or-kill vs partially fillable orders Order expiry vs cancellation: different end states