How dCLS works

From issuing a settlement token to redeeming it: the lifecycle of a single deal, multilateral netting and two settlement modes. dCLS only executes the FX conversion at a pre-agreed rate and takes no part in the underlying trade.

Settlement lifecycle

Seven steps from issuing a settlement token to redemption. The parties agree the rate outside the system — dCLS guarantees only simultaneity and finality of execution.

1
Issue the settlement token
A licensed issuing fund takes in local fiat and issues a settlement token 1:1. The fiat stays in the fund's accounts in its own jurisdiction.
2
Deposit to the settlement account
The participant moves settlement tokens to their settlement balance in dCLS — a working position for future deals.
3
FX instruction
The parties agree the rate between themselves and submit an instruction: what to exchange against what and at which rate. dCLS does not set the rate.
4
Netting in the settlement window
Instructions accumulate in the window and are compressed by multilateral netting: many offsetting obligations collapse into a few net positions.
5
Atomic PvP settlement
Both legs of the deal execute at the same time — payment versus payment. Either both clear or neither does. Herstatt risk is zero.
6
Confirmation and audit
Settlement becomes final on block confirmation. Every operation is recorded in an immutable audit trail.
7
Redeem the token
The participant presents the settlement token to the issuing fund for redemption at par and receives local fiat. The token is withdrawn from circulation.

How netting cuts transfers

Multilateral netting collapses many offsetting obligations into a few net positions. Below is an anonymised example: five gross transfers compress into three net ones.

Gross obligations (5)

Net after netting (3)

The example is indicative and illustrative. The actual compression depends on the structure and balance of offsetting flows in a given window.

Two settlement modes

The same settlement runs in two modes. The participant picks the mode that fits their trust profile.

Ledger (off-chain)

Settlement runs in the operator's secure ledger. Higher speed and throughput; settlement relies on trust in the operator and its procedures.

On-chain (Ethereum L1)

Settlement executes in a smart contract on Ethereum. Public verification, censorship resistance and an immutable audit trail instead of trust in a single party.

The modes are not mutually exclusive: off-chain provides speed for everyday flow, on-chain provides independent verifiability for material settlements.

Execution priorities

Priority determines the order in which an instruction enters the settlement window — not its cost. Urgent instructions execute ahead of deferred ones.

Urgent

The instruction is included in the nearest settlement window first.

Normal

Standard order: the instruction executes in the scheduled window.

Deferred

The instruction waits for a fuller window — which improves the conditions for netting.

Priority affects only the order of execution and does not change the fee.