Proposal: Reference Implementation of Settlement Pattern and Reference DEX Implementation for Canton

Question: do you need any changes to the token standard (CIP-56) for your work to land?

I'm asking because there's an active conversation on cip-discuss) wrt an improved version of the token standard motivated in part by TradFi requirements for extra privacy.

There might also be changes that are not a blocker, but would make your work significantly easier. It would be great to hear about the these and in particular about blockers on cip-discuss or directly on the PR linked from there: https://github.com/canton-foundation/cips/pull/187

Also: you might be interested in the DvP settlement code written as part of the validation work for the proposed Canton Network Token Standard v2:

• trading app: https://github.com/hyperledger-labs/splice/pull/4436/changes#diff-8bc10eb93eac25dddb87a39204cc942cb4094b2fd49feae4159378d9302d215e
• tests: https://github.com/hyperledger-labs/splice/pull/4436/changes#diff-8d2c9fd0d863ba922527c511bb2a06a5bbf02425765898d60a5222ac0c58ded9

Hey @meiersi-da ,

We do not currently see blocker changes to CIP-56 as necessary for CCDS to land as a reference implementation.

CCDS is designed so that the orchestrator interacts only with a settlement-capable wrapper (Lockable) rather than with the token template directly, so the orchestration layer itself is token-standard-agnostic. For the Daml Finance / CIP-0056 side, what we currently demonstrate is the reference adapter pattern in-repo, not yet direct integration against an external deployed Daml Finance holding package.

What would make this significantly easier is mostly better standard support around reservation / settlement ergonomics and privacy rather than a new core concept. In particular:

• allocation / reservation flows that are straightforward for an external settlement coordinator to drive and recover
• stronger privacy around holding selection, pending settlement requests, and settlement context visibility
• package compatibility that makes direct Daml Finance integration easier from current SDK/package lines
• cleaner standardized patterns for bilaterally authorized settlement execution

So our current view is:

• no blocker changes to CIP-56 are required for CCDS to land
• v2 improvements around privacy and allocation-style settlement flows would make a standards-native path significantly easier
• our biggest current gap is direct package integration with real Daml Finance holdings, which is more a package/toolchain compatibility issue than a CIP design blocker

The Splice DvP settlement work you linked looks very relevant to us for exactly that reason, and we’ll compare it against the current CCDS approach.

Today, CCDS uses a bridge-backed architecture for token-standard-native assets: real token transfer in/out, mirrored settlement wrapper in the middle. With a token-standard-native DvP path, that middle layer could become much thinner, because CCDS could settle directly against allocations/reservations instead of wrapping the asset into a custom settlement contract.

Thanks for the quick reply @srikanth-bitdynamics . It sounds like you have a lot of code already in place. Would have a link to share so I can learn more about the concrete code?

Today, CCDS uses a bridge-backed architecture for token-standard-native assets: real token transfer in/out, mirrored settlement wrapper in the middle. With a token-standard-native DvP path, that middle layer could become much thinner, because CCDS could settle directly against allocations/reservations instead of wrapping the asset into a custom settlement contract.

That's great to hear. Did you consider creating a PoC of the actual code changes / gains that you'd get from building on V2? That would be great input for the validation phase.

@meiersi-da It is under active development, and we’ve already tested the CC mirrored path, which looks promising. The code is currently in internal repos, but I can put together something concrete to share by the end of the week if that works.

We started building early because we believed this would be a valuable piece of ecosystem infrastructure and wanted to reduce delivery risk if the proposal moves forward.

On V2, we haven’t yet built a dedicated PoC against that path, but we do plan to explore it as well. The main architectural difference would be that today the token-standard leg is bridge-backed with a mirrored settlement wrapper in the middle, whereas a token-standard-native DvP/allocation flow could make that layer much thinner.

Is there an indicative timeline for when V2 might go live?

@meiersi-da Sorry I just checked with team we do have some PoC for v2 . Once V2 Stabilizes we will retire the Older path and keep the V2 path alone.

@meiersi-da Sorry I just checked with team we do have some PoC for v2 . Once V2 Stabilizes we will retire the Older path and keep the V2 path alone.

Oh wow. That's valuable to hear.

As for timeline, these are the target dates we are working against: https://github.com/canton-foundation/canton-dev-fund/pull/97/changes#diff-4ecd73dcdca021a7e9d8622731e823bff2205e70e973b8998e1e3f0fcfb4397dR157

@meiersi-da It is under active development, and we’ve already tested the CC mirrored path, which looks promising. The code is currently in internal repos, but I can put together something concrete to share by the end of the week if that works.

There's no requirement for you to share the code. It's mostly a best effort offer from myself. I'm saying best effort, as I'll be on holidays starting mid next week; and have a few things to finish before.

@meiersi-da Understood created a repo for you and granted you access please check.

@srikanth-bitdynamics : thanks for sharing the repo, and for including the docs in https://github.com/srikanth-bitdynamics/Canton-Cross-Domain-Settlement/blob/main/docs/token-standard-v2-architecture.md

A few comments from a first review:

• all assets on CN MainNet support CIP-56, aka token standard v1. What's the reason to not use it's allocation worfkflow for such assets?
• are you aware that Canton has automatic synchronizer routing: https://docs.digitalasset.com/overview/3.4/explanations/canton/multi-synchronizer.html
  • I'd expect it to be used as sketched in these slides: 2025-04 - Simon - A preview on multi-synchronizer applications.pdf; and there should thus be no need for the trading parties to signal that their legs have been reassigned
  • You are right though to call out the need for taking care of avoiding locked holdings or routing them together with the allocation. Looking again at the workflow on Slide 8, I suspect that one interesting option is to pin the AllocationFactory to the Global Synchronizer, so that any locked holding is created there directly, and can thus be used by the settlement app

Also:

• note that the token standard v2 comes with improve test infrastructure. In particular there are both reference tokens implementing the V1 and the V2 standard:
  • https://github.com/hyperledger-labs/splice/blob/token-standard-v2-upcoming/token-standard/examples/splice-test-token-v1/daml/Splice/Testing/Tokens/TestTokenV1.daml
  • https://github.com/hyperledger-labs/splice/blob/token-standard-v2-upcoming/token-standard/examples/splice-test-token-v2/daml/Splice/Testing/Tokens/TestTokenV2.daml
• consider building on them to save the implementation of the mock asset
• you may also want to consider supporting richer trades with more legs, as done in https://github.com/hyperledger-labs/splice/blob/token-standard-v2-upcoming/token-standard/examples/splice-token-test-trading-app-v2/daml/Splice/Testing/Apps/TradingAppV2.daml

@meiersi-da Thanks for this feedback this is helpful. We do have CN-native pieces scaffolded but not completely implemented. We started with non CN assets for ease of use and testing the idea if we can implement or not.

I will share you CN Asset implementation when done but docs you shared are helpful for us in moving fast thanks for it.

Hi @srikanth-bitdynamics, I think this can be a valuable reference for the community - I've seen a few companies already create their own implementations, and it will be great to have a reference.

I recommend scaling back the proposal to what you currently have under M1 and M2, and leaving the others for a future grant request. No need to harden it yet for production, let's first get feedback on an MVP.

You can scope the grant to (M1) open sourcing what you have done already under Apache2 (M2) Improving the reference based on Simon's feedback above (M3) writing up your experience as an experienced EVM developer, so that others coming from EVM can learn in your words about the differences on Canton - I expect this will be very valuable for our community.

After that, you can put in subsequent grant proposals based on community feedback and requests.

@shaul-da Thanks, this is very helpful, and I agree with the direction.

I’ve re-scoped the proposal around those three milestones:

1. open-source the current CCDS baseline under Apache 2.0
2. Improve the example based on the feedback
3. write up the EVM-to-Canton builder guide and walkthroughs

I also cut the ask down to 1.6M CC and removed the broader hardening / later-stage release framing for now. That feels like the right shape at this point if the aim is to get feedback on a useful Product first and then build from there.

Thanks again for the guidance. It really helped sharpen the proposal.

Can you elaborate on what you mean with cross-domain? Do you mean multi-synchronizer?

I would appreciate if you could expand on what truly the problem is that you are trying to solve. Are you providing a DvP reference implementation because people don't know how to express an atomic swap? Or you providing a DvP reference implementation that works on multi-sync (and what would be the difference?). Or you solving a particular edge case where the connectivity does not overlap?

Are the validators connected to all synchronizers? Or are you trying to solve the problem where the validators are not connected to the synchronizers?

Otherwise, what you are designing here goes against the main goal of multi-sync support. On the Daml or Ledger API level, the fact that different synchronizers are involved shouldn't even be noticed.

In that sense, given the fact that you must explicitly orchestrate across different synchronizers means that something is going on.

Thank you very much for your proposal. While going through it I wasn't really sure what the problem is that you were trying to solve. Are you aware of Canton's native capability to support multiple synchronizers: https://docs.digitalasset.com/overview/3.5/explanations/canton/multi-synchronizer.html

Thank you very much for your proposal. While going through it I wasn't really sure what the problem is that you were trying to solve. Are you aware of Canton's native capability to support multiple synchronizers: https://docs.digitalasset.com/overview/3.5/explanations/canton/multi-synchronizer.html

@daravep Thanks, fair point. The proposal did not state the problem sharply enough.

The problem I’m trying to address is the application-layer coordination of a trade whose two legs do not share a single asset model. A concrete example is a CN-native CC leg on Global and a private or custom instrument leg on a separate synchronizer with its own custody model and no Splice-style registry.

I’m aware of Canton’s native multi-synchronizer support, and I’m not trying to re-implement that. Native routing can place each leg correctly for execution, but it does not by itself give you the trade-level coordination for the mixed case: shared bilateral intent, reservation boundaries, TTL, and documented recovery behavior across both legs.

For pure CN-native assets, the code has already moved toward the more Canton-native path: allocation workflows, Global-pinned settlement, and native routing where the validator supports it. So the main reusable part of CCDS is the pattern around reservation, bilateral intent, topology, and recovery for mixed-asset settlement.

Yes, I mean multi-synchronizer / cross-synchronizer.

I used “cross-domain” in the older / colloquial sense, but the proposal is really about multi-synchronizer settlement flows at the application layer. I can update the wording to use “multi-synchronizer” more consistently so that it matches current Canton terminology better.

Good question — let me map it to the three options you offered.

Not (1). Expressing an atomic swap on a single synchronizer is straightforward in Daml, and the repo already has it: DvPInstruction.Execute and MultiLegInstruction.ExecuteMultiLeg. That is not the contribution.

Closest to (2), with elements of (3). The reference is about multi-synchronizer DvP at the application layer — specifically when the two legs use heterogeneous asset models:

private / custom assets behind a generic Lockable interface CN token-standard assets using allocation-style reservation mixed trades where one leg is CN-native and the other is private / custom Canton's native routing places each leg correctly, but it does not bind heterogeneous legs into one trade with shared reservation, TTL, and recovery. That is the gap.

(3) as a sub-case. When connectivity doesn't overlap — e.g. the private-asset synchronizer isn't reachable from the CN-native side — the same pattern still applies, with reassignment as the bridging primitive. The reference documents that boundary rather than hiding it.

So the reusable contribution is the workflow pattern: reservation / locking at the asset boundary, bilateral settlement intent, both-legs-valid settlement position, checkpointing, and documented recovery — not the atomic swap transaction itself.

To your first question: in the reference topologies, yes, the validator participant(s) are connected to the relevant synchronizers. I am not positioning this as a general solution for disconnected or non-overlapping validator topologies.

For the CN-native lane, I agree with your point entirely. That path now relies on Canton’s native multi-synchronizer behavior: allocation on Global, settlement pinned there, the instruction created directly in AwaitingExecution, and the old manual “legs reassigned” confirmation skipped on the happy path. So explicit reassignment is no longer the intended story for CN-native assets.

Where explicit orchestration still remains is the generic/private-asset lane. It is not because Canton cannot route those contracts. It is because private/custom assets do not come with a standard allocation workflow or registry-defined settlement convention the way CN token-standard assets do. In that lane, the reference makes the reservation boundary, settlement topology, and recovery model explicit so that the pattern is inspectable and reusable for custom assets.

So the remaining orchestration is not re-implementing multi-synchronizer routing at the Ledger API level. It is a reference coordination pattern for assets that do not already have the token-standard reservation/registry machinery behind them.

what is the motivation for choosing a settlement workflow not following token-standard?

I think if we are talking about "reference" then we have to use the token-standard interface for the both instruments. In fact it would be nice to demonstrate that it is agnostic of the instrument itself and only depends upon the interface.

I expect that the demo does make use of token-standard registry/allocationfactory/transfer-factory mechanisms, please provide more context on why it should not be used here.

I would expect even the private assets to provide this interface and allow their use across multi-sync.

@dfordivam

Wherever an instrument exposes the token-standard interfaces, that is the preferred path in the repo today, and I should make that the primary narrative more clearly.

The Daml tests exercise that token through the same core settlement shape as the CN-native path: AllocationFactory_Allocate -> SpliceAllocationBridge -> DvPInstruction.Execute -> Allocation_ExecuteTransfer

For the live CC / CN-testnet path, the repo also uses the registry-backed pieces:

• ScanProxyRegistryClient for choice context and disclosed contracts
• AllocationBridge for the allocation workflow
• SpliceAllocationBridge as the settlement adapter

So I agree with the clean reference direction you describe: if both instruments expose the token-standard reservation / settlement interfaces, the settlement flow is instrument-agnostic and driven by those interfaces.

The remaining generic Lockable lane is there as a pragmatic fallback for assets that do not yet expose HoldingV1 / AllocationFactory / TransferFactory-style interfaces in practice. The local adapter paths are meant as transitional bridges for those assets, not as an argument that token-standard should be avoided.

I will reframe the proposal so the token-standard path is the headline reference story, and the Lockable adapter path is described as the fallback / transition path for pre-existing assets.

Ok, as the "assets that do not follow interface" is somewhat orthogonal to the multi-sync flow. I would even suggest keep it simple and assume token-standard is being followed. There are plenty of per-requisites (and even pitfalls) that may be presented as part of the demo of operation of multi-sync transfer.

Potential Ecosystem Beneficiaries for Voting team @shaul-da

CCDS is intended as public-good infrastructure for projects on Canton that need atomic settlement across applications or synchronizers, especially where the two legs of a trade do not live inside the same asset system.

There are already a number of projects actively integrating with CCDS. BitDynamics is integrating CCDS into its own AMM stack for cross-application and mixed-asset settlement. We are also actively integrating with teams from Zynk and **Lumens.fi and have infrastructure-facing discussions with Gateway around where this pattern could be useful in the broader ecosystem. Zynk is integrating CCDS for atomic payment-versus-liquidity and payout-versus-funding flows. In addition, we are in early conversations with a small number of exchanges and wrapped-asset providers that are exploring similar settlement needs, although those discussions are not yet public.

The strongest fit is for:

• trading venues and exchanges
• AMMs, DEXs, and swap protocols
• bridges and wrapped-asset issuers
• tokenized securities, bond, and debt platforms
• settlement and clearing infrastructure
• custody and trading stacks
• derivatives and multi-leg trading applications
• payment and credit workflows where one leg should only complete if the counter-leg settles successfully

In practical terms, CCDS is most useful where a project needs to coordinate settlement between:

• a Canton-native token-standard asset such as CC or another CIP-56 instrument
• a private or application-specific asset on another synchronizer
• multiple trade legs that must settle together rather than independently

Representative projects from the current Canton project landscape that appear especially well aligned with this problem, and that we are reaching out to about this implementation, include Tradeweb, TradeChain, Global Settlement Holdings, Sats Terminal / OneSwap, Hundred Exchange, CaviarNine / Cantex, OKX CC Exchange Gateway, RootsFi / Bridge by Roots, OpenVector / Trade.Fast, Texture Capital, Obligate, Black Manta, Rho Relay, Helios Finance, Zero Hash.

Note: active development began alongside the DevGrant discussions, and the codebase is now at a stage where it can be exercised end-to-end on testnet.

We plan to build our AMM stack on top of CCDS. Concretely, we expect to use it for:

• Mixed-asset swaps
• Multi-hop trades and atomic pool rebalances

This could be valuable for the community to open-source it.

+1 from us — we at Zynk are in process of integrating CCDS for our atomic payment-versus-liquidity and payout-versus-funding flows.

CCDS gives us that guarantee out of the box, which means we can focus on our payout and credit logic instead of building cross-application settlement ourselves.

Happy this exists as shared infrastructure rather than something every team rebuilds.

From the BitSafe (CBTC) side, the mixed-asset DvP pattern CCDS targets is relevant to atomic settlement of CBTC against non-CN-native or private-synchronizer counter-legs (bilateral options, RWAs, custom instruments). Keen to evaluate CCDS on testnet against CBTC and a representative counter-leg once it's open-sourced, and happy to share feedback from that exercise back to the community.

@srikanth-bitdynamics : given yesterday's video call we had, I understand that you plan to adjust or potentially retire you proposal. Is that correcdt?

Marking it here for other reviewers so they are aware.

Based on the discussion with @meiersi-da changed the scope of this proposal to Reference implementation of Settlement pattern using V2 Paths and DEX Implementation which will be built at production level.

What kind of integration are you thinking about?

consider adding a reference to the relevant PRs and files in the appendix to make it easier to read the grant for people not well versed in the ongoing development of the V2 token standard.

Ultimately you require the PR-5333 to be part of the V2 token standard, as otherwise no assets will be available to be used with your DEX. I'd reformulate to call this dependency out.

Side note: I'm pretty sure that we will add it traded settlement to the standard.

what about the backend and UI?

what kind of registry dependencies do you expect to have?

Very nice. From the perspective of an author of the V2 token standard, this would be very valuable to have as a validation point.

Approving (even tough I don't have write permissions), so GH (hopefully) no longer shows "requested changes".

Sure I'll add those in the proposal

I'll add them it got missed. We will also have a frontend and backend which supports

Changed the framing

sure removing it

Added Appendix to the end of the proposal

@srikanth-bitdynamics @daravep @shaul-da : note that there's another proposal for a reference DEX implementation here: https://github.com/canton-foundation/canton-dev-fund/pull/262/changes#diff-6674b03d457809a0503564c72d8b9f0277f71748f252ef4dc19070808c337c77R118

This proposal here should be deduplicated against the other one.

Milestone 1: Public Release and Initial Ecosystem Adoption

• Estimated Delivery: 4 weeks from project start
• Focus: Publish the settlement-pattern reference and reference DEX baseline in a form external builders can run and evaluate.
• Deliverables / Value Metrics:
  • public Apache 2.0 repository for the settlement-pattern reference and reference DEX
  • Daml modules for pair listing and OTC / RFQ settlement baseline
  • tests showing matched trade settlement using Token Standard V2 patterns
  • workflow documentation explaining pair, trade, order, pool, and LP flows
  • local dev environment and run instructions for external builders
  • at least two concrete ecosystem feedback loops completed
    • example: committee review, builder review, or partner evaluation
  • at least one public walkthrough or demo session delivered

Milestone 2: Public Testnet and Builder Adoption

• Estimated Delivery: 6 weeks after Milestone 1
• Focus: Deliver the first production-shaped AMM surface and operate a public testnet instance that external teams can actually evaluate.
• Deliverables / Value Metrics:
  • constant-product pool implementation
  • add liquidity, remove liquidity, and single-hop swap workflows
  • LP token issued as a token-standard instrument
  • pool funds represented by committed / iterated allocations
  • public testnet deployment operated by the team
  • operator notes covering deployment, recovery, and observability
  • at least two external teams or ecosystem builders actively evaluating the public testnet or codebase
  • documented feedback from those evaluations incorporated into the reference

Milestone 3: Reuse Proof Points, Builder Guide, and Integration Readiness

• Estimated Delivery: 4 weeks after Milestone 2
• Focus: Extend the reference from pool-only trading to prefunded orders and turn it into something builders can realistically adopt or extend.
• Deliverables / Value Metrics:
  • order placement, match, partial fill, and cancel workflows backed by V2.Allocation
  • builder guide explaining workflow choices and Daml contract boundaries
  • guide for adding a new trading pair
  • guide for issuing a new LP token or lifecycle-rich instrument
  • architecture note explaining what is intentionally not included in the reference and why
  • at least one concrete reuse proof point
    • example: external integration, external fork, or documented partner pilot
  • a published summary of ecosystem feedback and resulting design changes

Milestone 5: 12 Months of Maintenance

• Estimated Delivery: begins after Milestone 3 and covers the following 12 months

• Deliverables / Value Metrics:

  • third-party security audit commissioned once Milestone 3 scope is stable and deployment-critical workflows are frozen
  • published audit summary and remediation status
  • closure or accepted-risk disposition for all critical and high-severity findings
  • production hardening pass across the reference workflows
  • examples: authorization review, cancellation paths, failure handling, replay/idempotency checks, and operator recovery procedures
  • maintenance and support for 12 months after audit release
  • security fixes
  • compatibility updates for supported Canton / SDK / token-standard changes
  • bug fixes for the published reference workflows
  • public maintenance log or release notes covering fixes, upgrades, and workflow-impacting changes
  • operator runbook for deployment, monitoring, upgrade, and incident handling
  • documented support for external adopters using or evaluating the reference

Originally posted by @pedrodneves in https://github.com/canton-foundation/canton-dev-fund/issues/108#issuecomment-4388431766

Hi Srikanth, I'm building an open-source algorithmic trading toolkit for Canton: a venue-agnostic Python connector, reference liquidity bots for thin pools, and an MCP interface so AI agents can trade under hard risk caps. It's the demand-side layer that sits on top of venues like your reference DEX and sends programmatic flow to them.

It's already working, not a plan on paper. The connector is validated end to end on Cantex mainnet: challenge-response auth, pool listing, quoting, and a real swap confirmed on ledger. Repo (Apache-2.0, live): https://github.com/olevasyliev/canton-trading-toolkit

I saw you offered to review and be a design partner on the Rust SDK proposal, so I wanted to come to you directly. Two concrete things I'd value your read on.

1. Your settlement pattern and reference DEX are the natural second venue adapter for this connector. If that's useful to you, I'd be glad to make your DEX the target. Your venue gets an open Python client, reference market-making bots, and agent-reachable execution for free, and I get a second venue to prove the venue-agnostic design against.
2. As someone who has shipped a funded Canton grant end to end, does the demand-side framing hold up to you, a trading layer that every venue needs but none of them builds?

Happy to walk through the code or jump on a call, whatever's easiest. Either way, thanks for putting the design-partner offer out there.

Oleksii

@srikanth-bitdynamics Hi, bro. I have experience in DEX, CEX, DeFi, Wallet development as a blockchain developer. I would like to contribute your project. How can I contact you?

Milestone 4: Security Audit

Estimated Delivery: 3-5 months after M3

Scope: a single third-party security audit of the reference Daml package , commissioned once M3 scope is stable and the deployment-critical workflows are frozen

Deliverables for next Milestone: third-party security audit commissioned against a frozen M3 scope published audit report / summary a documented disposition for every critical/high finding — either a fix or an accepted-risk note with rationale which is part of M5 already

Acceptance Criteria : audit engagement completed with a third party and the quotation received.

Ask to be submitted based on quotation from Audit firm.