Atomic Settlement with Canton: Building Post-Trade Infrastructure on a Distributed Ledger

The problem with T+2 settlement

Traditional securities settlement operates on a T+2 cycle: a trade executed today will not settle — meaning ownership legally transfers and cash definitively moves — until two business days later. This delay is not a quirk; it is an architectural consequence of the fragmented, message-based infrastructure that intermediates between buyers and sellers. During those two days, both counterparties carry open exposure: the seller may default before delivering securities; the buyer may default before delivering cash. Central counterparties (CCPs) interpose themselves to guarantee settlement, collecting margin to cover potential losses. This works, but at significant cost: margin requirements lock up capital that would otherwise be productive, and netting across the CCP requires aggregating positions from hundreds of participants with reconciliation cycles that themselves take hours.

The deeper problem is that the trade record exists in multiple places simultaneously — in the OMS of the buyer's broker, the seller's broker, the CCP, the central securities depository, and the custodians — and none of them is definitively authoritative. Reconciliation is a multi-party coordination problem run over batch messaging, and it fails in edge cases: missed SWIFT messages, time-zone cut-off mismatches, corporate action timing disagreements. Failed trades are common enough that ESMA mandates reporting of them under CSDR.

What Canton is and why it differs from public blockchains

Canton is a distributed ledger platform developed by Digital Asset, designed for regulated financial institutions. It is not a public blockchain. There is no proof-of-work, no public mempool, and no anonymous validator set. Canton is a network of operator-run nodes where each participant controls its own node, and the protocol enforces correctness through cryptographic commitments rather than through a shared global replicated log visible to all.

The key structural difference is Canton's synchronisation mechanism. Rather than all participants maintaining an identical copy of a global ledger, Canton nodes synchronise only the contracts relevant to them. A contract between Party A and Party B is stored on A's node and B's node, and on any synchronisation domain they share. Party C learns nothing about it. This sub-transaction privacy is the property that makes Canton suitable for regulated markets where information barriers between participants are legally required.

DAML contract model — representing ownership and obligations

Smart contracts on Canton are written in DAML (Digital Asset Modelling Language), a functional, strongly-typed language purpose-built for representing legal obligations. A DAML contract is a data structure with named fields and a set of choices — actions that stakeholders can exercise. Exercising a choice atomically archives the existing contract and creates zero or more new contracts. There is no mutable state: the ledger is an append-only log of contract create and archive events.

-- DAML: simplified equity ownership
template Equity
  with
    issuer   : Party
    owner    : Party
    isin     : Text
    quantity : Decimal
  where
    signatory issuer, owner

    choice Transfer : ContractId Equity
      with newOwner : Party
      controller owner
      do
        create this with owner = newOwner

-- DAML: DVP settlement instruction
template DvpInstruction
  with
    buyer     : Party
    seller    : Party
    equityCid : ContractId Equity
    cashCid   : ContractId Cash
  where
    signatory buyer, seller

    choice Settle : (ContractId Equity, ContractId Cash)
      controller buyer, seller
      do
        -- Atomic: both legs or neither
        newEquity <- exercise equityCid Transfer with newOwner = buyer
        newCash   <- exercise cashCid   Transfer with newOwner = seller
        return (newEquity, newCash)

The signatory declaration is the key correctness guarantee: a contract can only be created or archived with the authorisation of all signatories. Neither buyer nor seller can unilaterally transfer the other's asset. The DAML runtime enforces this at the ledger level, not through application-layer logic.

Atomic DVP: delivery vs. payment at the ledger level

Delivery versus Payment (DVP) is the settlement principle that the transfer of securities and the transfer of cash must be simultaneous and conditional on each other. In traditional infrastructure, DVP is enforced by the CCP and the central securities depository acting as coordinating intermediaries. In Canton, DVP is a property of the transaction itself.

When the Settle choice on a DvpInstruction is exercised, the Canton runtime evaluates the entire transaction as a single atomic unit. Both the equity transfer and the cash transfer are committed together or not at all. There is no intermediate state where the securities have moved but the cash has not — the sequence of events in the DAML model does not correspond to a sequence of separate ledger commits. Canton's transaction model guarantees atomicity across contract boundaries within a single synchronisation domain.

This eliminates principal risk — the risk that one leg of a trade settles while the other fails — without requiring a CCP to guarantee the transaction. Settlement finality is achieved the moment the transaction is committed on the Canton domain, which in our implementation happened within 2–3 seconds of trade confirmation.

Canton's privacy model: need-to-know by construction

Canton's privacy model is a first-class protocol property, not an access control list bolted on top of a transparent ledger. Each Canton node stores only the contracts for which its hosted parties are stakeholders (signatories or observers). The Canton synchronisation domain coordinates transactions by passing cryptographic commitments and blinded views, not by broadcasting full transaction content.

In practice this means: Broker A can see its clients' positions because it is an observer on those contracts. Broker B cannot see Broker A's clients' positions. The CCP, if present as a Canton participant, sees only the net settlement instructions it is a signatory of, not the underlying client trades. This satisfies information barrier requirements under MiFID II and equivalent regulations without requiring trust in a centralised access control system.

Integration with upstream OMS via event streams

The OMS produces trade confirmations as structured FIX execution reports. An integration service translates these into DAML contract creation commands sent to the Canton ledger via the gRPC Ledger API. The flow is:

• OMS emits FIX ExecutionReport (ExecType=F, OrdStatus=2) on trade fill
• Integration service maps the report to a DAML TradeInstruction create command
• Canton domain commits the contract; both buyer and seller nodes receive their views
• Allocation service matches buyer and seller TradeInstruction contracts and exercises Settle
• Settlement events are streamed back to the OMS and CSD via the Canton transaction event stream

The Ledger API event stream is the authoritative source of settlement status. Downstream systems (the CSD, custodians, internal books and records) subscribe to the stream and update their state from it. This replaces the existing SWIFT MT54x message flow with a real-time push model.

What this enables vs. the traditional CCP model

• Near-instant settlement: T+2 becomes T+seconds for instruments settled on Canton, dramatically reducing counterparty exposure windows.
• Margin reduction: with atomic DVP and sub-second finality, the margin required to cover settlement risk collapses. Early pilots showed 60–80% initial margin reduction for intraday positions.
• Reconciliation elimination: the single shared contract state replaces the multi-party reconciliation cycle. Disagreements about settlement status become a Canton node consistency problem — governed by cryptographic protocol — rather than a human operations problem.
• Programmable settlement: DAML choices can encode complex settlement conditions — contingent transfers, repo agreements, corporate action adjustments — as first-class contract logic rather than side letters processed by operations teams.

The CCP model is not eliminated — CCPs provide important netting and default fund functions that Canton alone does not replace. But atomic ledger-level DVP fundamentally changes the risk calculus: the CCP's primary function shifts from guaranteeing that two legs settle to managing default of a participant's obligations, which is a narrower and more tractable problem.