I’ve been thinking about where a project like SettleFlow fits relative to the existing Daml Finance / FinLib stack.
FinLib already provides a lot of the important settlement building blocks: asset deposits, asset transfers, DvP templates, lifecycle handling, allocation helpers, and settlement triggers. In that sense, it covers much of the mechanics of settlement.
But FinLib also explicitly leaves one part open: how a DvP gets instructed is often bespoke to the use case. That seems like the gap SettleFlow is aiming at.
My current understanding is that SettleFlow is not trying to replace FinLib or invent a new primitive. It looks more like a reusable workflow layer that sits above those building blocks and handles the coordination that applications still need to implement:
- trade proposal / instruction flow
- multi-party authorization collection
- leg matching and readiness tracking
- execute / cancel / withdraw lifecycle
- audit-friendly workflow state
If that’s right, then SettleFlow is less about settlement primitives and more about making settlement workflows reusable across applications that otherwise end up rebuilding the same orchestration logic in different ways.
Curious how others think about this:
- Do you see this as a useful reusable layer?
- Or is this something most teams would just implement directly on top of FinLib / Canton primitives?
- Where do you think the line is between a helpful reference implementation and a real infrastructure layer?