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

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

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

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?