DEX essentials

Order expiry vs cancellation: different end states

Distinguish an order becoming invalid with time from active cancellation, and understand why prior partial fills remain real.

Expiry ends an order's validity after its encoded time limit. Cancellation actively invalidates an order through the protocol's supported mechanism. Both can prevent future fills, but they occur for different reasons and can leave different records.

Different transitions to an inactive order

0x's order-state reference lists filled, cancelled and expired as distinct statuses. Its order specification also makes expiry part of the signed order. This provides a concrete example of why these terms should not be used interchangeably.

Consider a hypothetical order expiring at 18:00. At 17:00 it may still be eligible. A successful cancellation at 17:10 can invalidate it before the scheduled expiry. If no cancellation occurs, the time rule can invalidate it later without the user sending that cancellation action.

Neither reverses an earlier fill

If 30% of a partially fillable order already settled, later cancellation or expiry does not undo those transfers. It concerns the unfilled remainder. The complete history can therefore include a partial fill followed by cancellation.

A submitted cancellation request also needs the guarantees of its own mechanism. An onchain cancellation that has not yet taken effect is different from a completed invalidation. Some services additionally offer offchain cancellation behavior; its scope should be read from their documentation.

Use status and history together

A final status answers whether further fills remain possible under the relevant rules. The fill history answers what already happened. Reading only one can misrepresent the result.

For reporting, separate original size, cumulative settled size, remaining size and reason for closure. This makes “expired after a partial fill” unambiguous and avoids treating “cancelled” as a claim that no tokens ever traded.

This page explains order states rather than a cancellation procedure. The specific product's cancellation mechanism determines which action changes validity and when that change becomes effective.

Sources & verification (2)

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

  1. 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
  2. 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

Continue reading

Why reaching a limit price may not fill a DEX order Exact input vs exact output: choosing the right constraint Why swaps and signed orders have deadlines