Order lifecycle

Keep the state of an order separate from the movement and settlement of its funds.

REQUESTAcceptedProcessing acknowledged
MATCHINGOpen → fillsTrack filled & remaining
LEDGERAccount effectExact assets & fees
SETTLEMENTFinalizedSeparate finality evidence

Proposed order progression. Rejection, expiry and cancellation branch from eligible states; final precedence remains unresolved.

The draft order lifecycle distinguishes RECEIVED, OPEN, PARTIALLY_FILLED, FILLED, CANCEL_PENDING, CANCELLED, EXPIRED and REJECTED. These proposed states describe different stages from settlement:

durable API acceptance of an idempotent request;
order admission to matching;
immutable fills, including fees and exact quantities;
account ledger effects;
settlement inclusion and finalization;
external token or payment delivery, where applicable.

Placed, filled and cancelled events should support the REST projection and replay, but native events alone do not establish a ready REST history service. Terminal states must be immutable and replay-safe. Order status and settlement status cannot be a single field: available, reserved and pending-settlement balances must not be double counted, while provisional, finalized and paid facts remain independent. Provisional core output is not proof of final settlement.