· "Daml multi-party authorization — what tripped you up?"

App Development
1

Questionnaires for Daml Developers/ Smart contract Engineers, etc

1· “When a transaction touches more than one asset, do you write the settlement logic inline or reuse something?”
2· “How do you handle it when different parties on the same transaction should see different fields?”
3· “Has anyone found a reusable pattern for multi-leg settlement, or does everyone just write their own?”
4· “For those who’ve built a structured product — repo, fund subscription, something with more than one leg — how much of that was bespoke?”

2

On #3:

See Allocation/DvP: CIP-0056: Canton Network Token Standard - Canton Network Docs

If you’re already thinking about token standard v2, you could start to have a look at splice-api-token-allocation-v2

3

Thanks Colin.

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.

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

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?
4

There are definitely a few existing efforts to build reference implementations and/or canonical design patterns for different parts of the stack. Maybe worth a look, if you haven’t already.
Ex: Proposal: OpenZeppelin Canton Ecosystem Stack by xdaluca · Pull Request #262 · canton-foundation/canton-dev-fund · GitHub

Otherwise, I think the answers to these questions probably vary quite a bit between teams, especially where they begin to become/involve business decisions.

5

Thanks — that’s helpful, and we have looked at #262. Our view is that SettleFlow is complementary rather than overlapping: OpenZeppelin Canton Ecosystem Stack is about standardizing reusable contract foundations and canonical patterns, while SettleFlow is focused on the missing coordination layer for 3-party DvP workflows on top of existing primitives like CIP-56 and Daml Finance.

We’re intentionally staying narrower so we can prove one concrete end-to-end workflow, rather than trying to define the whole stack. If you know of any teams working on reference implementations for settlement coordination specifically, I’d love to look at those too.