Seeking builder feedback: reusable Daml package for structured settlement workflows on Canton

Hi Canton builders,

We’re working on a reusable Daml package for structured settlement workflows on Canton, starting with a 3-party DvP wedge.

The problem we’re trying to solve is simple: teams keep rebuilding the same workflow plumbing for each new settlement use case — proposal, acceptance, disclosed contract handling, expiry/cancel paths, and settlement completion.

Our current framing is not a general execution layer or a new app. It’s a reusable workflow primitive underneath structured Canton applications.

We’d value feedback on a few specific questions:

1. Do you see a real need for a reusable settlement workflow layer on Canton?
2. For structured settlement flows, what parts of the workflow are most painful to rebuild today?
3. Would you expect teams to adopt a reusable Daml package for this, or do they prefer app-specific logic?
4. What would make this useful enough to integrate instead of rebuilding in-house?
5. For a first wedge, does 3-party DvP feel like the right starting point?

If you’ve built on Canton or are planning to, we’d appreciate candid feedback — especially from teams working on settlement, lending, RFQ, treasury, or other multi-party workflows.

Thanks.

One question this raises at the infrastructure level is whether reusable settlement/orchestration layers eventually become institutional dependencies or remain interchangeable components.

Our latest research looks at this from the broader tokenization stack: as settlement, custody, routing and workflow span multiple rails, the important question may shift from who issues the asset to which coordination points become costly to replace.

The evidence currently supports interoperability as a coordination bottleneck. It does not yet establish interoperability as a durable moat.

We mapped the evidence, the competing incumbent-absorption thesis and the indicators that would actually demonstrate switching costs here:

Tokenization’s Real Story Is the Crossing Points - HackMD

Tokenization is often framed as a race between assets, tokens and blockchain networks. This deep dive examines a different question: what happens when money, securities and collateral operate across multiple digital rails at once? The analysis maps...

I’d be particularly interested in where builders see the strongest evidence that workflow integration is creating real dependency versus where teams can still substitute infrastructure relatively easily.

Interesting framing — I think SettleFlow is a good example of a crossing point layer in the tokenization stack.

It doesn’t issue assets or replace custody rails. Instead, it coordinates the part that becomes expensive to rebuild repeatedly: multi-party authorization, leg matching, readiness tracking, execution/cancel logic, and audit visibility for private settlement workflows on Canton.

That means the key question is not whether SettleFlow is “the moat” by itself, but whether repeated workflow integration creates switching costs over time. If teams start depending on a shared settlement coordination model, that layer can become sticky. If it stays a thin wrapper around native primitives, it remains interchangeable.

So I’d frame the evidence as follows:

• Strong evidence for coordination friction
• Some evidence that integration can become sticky
• Not enough yet to claim durable moat effects

For SettleFlow specifically, I’d say it sits exactly at the point where interchangeability could turn into dependency — but only if it becomes embedded across counterparties, audit processes, and settlement operations.

The next thing I’d look for is whether builders are seeing:

1. reused workflow patterns across multiple applications,
2. partner expectations around compatible settlement flows,
3. audit/compliance processes that depend on the orchestration layer,
4. and increasing cost to substitute once integrations are in place.

That’s where crossing points start to look less like convenience and more like infrastructure.

After reading your research Tokekenization’s Real Story Is the Crossing Points - HackMD

This thesis maps closely onto SettleFlow.

SettleFlow sits at a crossing point in the tokenization stack: it coordinates multi-party authorization, leg matching, readiness tracking, execution/cancel logic, and audit visibility for private settlement workflows on Canton. That makes it a good example of the kind of reusable orchestration layer that could become sticky if counterparties and operations teams build around it.

At the same time, SettleFlow does not yet prove the stronger claim that crossing points automatically become durable moats. It may remain interchangeable if teams can substitute the workflow layer easily using native primitives.

So I’d frame it as evidence for coordination friction, not yet evidence for durable rent. The key question is whether workflow integration creates measurable switching costs over time.

What would strengthen the dependency case would be repeated adoption across teams, partner expectations around compatible settlement flows, and audit/compliance processes that depend on the orchestration layer.

In that sense, SettleFlow is a useful test case for the broader tokenization question: when does interoperability become a bottleneck, and when does it become an economic control point?

Thanks — that distinction is useful. Has SettleFlow demonstrated workflow reuse across independent applications or counterparties yet, or is that still being validated? I’m particularly interested in evidence of operational dependency and switching costs beyond the initial integration.

Thanks — that’s the right distinction.

SettleFlow has validated the need for a reusable settlement coordination layer and demonstrated the pattern in a working demo, but it has not yet proven durable workflow reuse across independent applications or measurable switching costs beyond initial integration.

So at this stage, I’d describe it as:

• a working coordination pattern
• with early evidence of reusability
• but no proven operational dependency yet

The stronger evidence would be:

• reuse by a second or third independent workflow
• adoption by a different team with minimal redesign
• counterparties expecting SettleFlow-compatible flows
• audit / ops processes depending on its receipts or state model
• clear cost to replace once integrated