Order lifecycle

The order ticket prepares your market, direction, type, size and options. At submission, the request includes clientOrderId and an Idempotency-Key, which identify that instruction across retries. Edel returns orderId for subsequent order details and cancellation.

A timeout leaves the outcome unknown: the order may already have reached the venue. Keep the original request and use Check status. Creating another order before resolving the first can create additional exposure.

An order passes through local intent, command feedback and authoritative execution state. A timeout is an unknown outcome; it must not create a second logical order. Fill and settlement remain separate facts.

Request and venue identities. The command carries clientOrderId and Idempotency-Key. The venue assigns orderId in its response for subsequent reads and cancellation commands.

Cancellation needs authoritative confirmation. A cancellation acknowledgement is feedback. The account stream confirms the updated order state. A partially filled order can cancel only its remaining quantity.

Resolve uncertain outcomes. Status checks after an unknown result or a reconnect are separate from live order, fill and position updates. Check the original instruction before retrying. The terminal retains its identity so recovery does not create a second logical order.

A definitive rejection explains why the instruction could not proceed. An accepted response confirms that Edel has processed the instruction; check the returned order state and account updates to learn whether it is resting, filled or cancelled. A limit order may rest, partially fill and later cancel its remainder. A market order uses immediate-or-cancel behavior and does not leave an unfilled remainder resting.

Use the account’s order and fill evidence to follow execution, and position updates to confirm resulting exposure. Cancellation competes with fills already in flight: an order marked canceled can still have filled quantity and paid fees. Closing is itself a reduce-only order and can remain incomplete.

Eligible orders execute and commit off-chain. Later settlement nets obligations and submits them to Canton. Canton-confirmed evidence establishes settlement finality. A fill timestamp, an HTTP response or a newly refreshed history row does not substitute for that ledger evidence.

This is the reason trading does not wait for a blockchain round trip on each order. It does not remove pre-trade controls, off-chain durability or custody authorization. Read Architecture and Settlement.