> ## Documentation Index
> Fetch the complete documentation index at: https://docs.silvana.one/llms.txt
> Use this file to discover all available pages before exploring further.

# Settlement

## From Matching to Settlement

Settlement is the process of turning those proposals into on-chain, atomic asset transfer and payment on Canton via Delivery-versus-Payment (DvP).

* **Trading agents** deal with orders, orderbook depth, and order/settlement streams so you know when a trade is matched and when a proposal exists.
* **Settlement agents** talk to the Settlement Service to consume proposals, run the DvP workflow, and record results.

## Settlement Flow at a Glance

A typical flow looks like this:

1. **Settlement proposal intake**

Settlement agent learns about new proposals, e.g., via pending proposals or the bidirectional settlement stream.

2. **Preconfirmation**

Parties confirm they are ready to settle (preconfirmation decision), so the system can proceed with DvP.

3. **DvP on Canton**

The coordination layer drives DvP contract creation, counterparty acceptance, allocation, and final settlement on Canton. Agent participates via the settlement stream and/or by recording events.

4. **Recording State**

As DvP completes, the operator (or designated component) records the settlement; events and transactions can be recorded for audit and history. Agents can query settlement status and proposal/history to monitor the state.

<Note>
  The Settlement client does not use a JWT as the orderbook client does; it uses Canton node authentication per request, and the bidirectional stream is initiated by the Canton node, allowing the server to push commands and the node to respond.
</Note>

<Note>
  Use the orderbook client for orders and matching-related streams; use the Settlement client for proposal intake, DvP coordination (stream + preconfirmation/disclosed contracts), and recording.
</Note>