Execution architecture

Edel Markets uses a hybrid architecture: matching, risk and durable order commitment happen off-chain; eligible netted obligations settle on Canton afterward. The system does not send each order to the blockchain and wait for its confirmation before responding. Keeping Canton settlement out of this path supports low-latency execution and high order throughput.

The hybrid design keeps three questions separate: what did the engine execute, what can a client currently observe, and what has Canton confirmed? This distinction explains both speed and the need for precise pending, stale and final states.

A deterministic off-chain engine handles execution. Replicated journal evidence commits the outcome. Canton settles netted obligations asynchronously, keeping chain finality off the order acknowledgement path.

Execution and settlement have independent boundaries. The order acknowledgement waits for the off-chain commitment boundary, not a Canton transaction round trip. Risk checks and engine readiness still determine which commands can execute.

Views follow financial evidence. The journal records committed execution. Query stores and realtime delivery publish views derived from that record. A healthy connection or an HTTP acknowledgement alone does not establish a fill, fresh account state or ledger finality.

A frontend built for market data. The React/Rsbuild terminal uses a dedicated worker, validated reducers and shared external stores. Exact amount conversion and virtualized tables help present financial state accurately while keeping the terminal responsive.

Explore the frontend architecture and the execution engine.

The terminal, market-making integrations and owner-approved agents connect through our product APIs. REST loads initial state and submits commands; WebSockets carry ongoing market and account updates. Optional MCP tools expose permitted REST operations to compatible assistants.

Ledger integration stays behind those APIs. Clients do not need to handle Canton contract IDs or submit ledger transactions to trade. The terminal focuses on responsive market data, precise order entry, current risk previews and clear status during recovery.

Orders reach deterministic matching and an off-chain durability boundary before downstream net settlement. A trading acknowledgement and a Canton-confirmed settlement are different facts.

Trading does not wait for chain finality. Canton settlement is downstream of committed off-chain execution. This removes chain confirmation from the order acknowledgement path; it does not remove risk or durability checks.

Request identity. The public place-order request carries clientOrderId and Idempotency-Key. The response supplies the venue orderId for later order-specific reads and cancellation.

Follow the result after acceptance. A command response reports the instruction’s outcome. Clients use authoritative account streams for fills and position changes; Canton evidence proves settlement.

See the place-order API reference for the request format and settlement for the later ledger lifecycle.

The execution core records an ordered history of committed outcomes. After an interruption, it rebuilds state from that verified journal. Read models can then be reconstructed from the same history, keeping client views aligned with execution.

Already-funded trading operates off-chain, separately from Canton-dependent funding. During a Canton outage, funding can pause while trading remains subject to its own risk and readiness controls. Availability still depends on the nature of the incident and the venue’s current status.