Settlement and custody

Edel records ordered off-chain execution in a durable journal. Canton confirms settlement and ledger movements. Account owners authorize the custody actions that require their consent. Together, these records establish what executed, what was approved and what settled.

Query views and WebSocket updates make that state available to clients. They are derived from the execution and ledger records: a refreshed balance or a connected socket is not an additional authorization or settlement confirmation.

The settlement worker takes committed execution records and their balanced account effects, groups them into ordered net batches, and stores each submission in a durable outbox. Canton validates and confirms the settlement.

Net settlement. A batch contains transfers and expected account changes for a settlement window. Many trading effects can therefore settle together, instead of requiring a blockchain transaction for every order.

Ordered batches. The batching policy preserves complete command effects and limits the size of each batch. The window is not a fixed delay or a guarantee of settlement at a particular time.

Recoverable submissions. Retries keep the same batch identity and payload. Sequence and predecessor checks preserve the order of settlement, while confirmed Canton records establish finality.

Off-chain processing can produce many order and fill outcomes before settlement publishes a netted batch. A single order can generate zero, one or several fills, while one settlement batch can represent many eligible effects. Orders per second, fills per second and Canton settlement transactions per second are therefore different measures.

Batching is bounded by policy and preserves ordered evidence. A fill-timeline window does not imply that every trade settles on a fixed wall-clock schedule. Settlement has no fixed completion-time guarantee.

A deposit becomes trading collateral after its confirmed effect is ingested into ordered account state. Withdrawal completion can require reservation, owner consent, ledger consumption and later payout acceptance. An accepted command or receipt-backed account debit does not automatically mean the owner has claimed the payout.

Follow Deposits and Withdrawals for the user workflow. For implementation details, see the settlement contract model. Client integrations use product APIs; the backend handles ledger operations.

Execution, custody approval, ledger finality and presentation each have a different role. The journal establishes the committed off-chain outcome. Canton confirms the ledger-side effect. An owner approval authorizes the specific custody action; it does not claim that the action has already completed. Read models and WebSocket delivery make those facts observable without becoming a new source of financial authority.

This separation also explains recovery. Replaying committed execution rebuilds engine state, while funding credit or payout completion requires its corresponding confirmed ledger evidence. A deposit submitted from the browser is not yet usable collateral, and a withdrawal accepted by the venue is not yet a completed owner payout.