W15: Atomic Multi-Leg Settlement Primitive
Avro Digital requests 4,500,000 CC over 6 months across 4 milestones to design, implement, and release an open-source reference implementation of an atomic multi-leg settlement primitive for Canton.
Label: financial-workflows-composability Champion: need Champion (outreach in progress via the SIG) Status: Draft
Why
Canton's core technical differentiation is atomic settlement across multiple assets, parties, and application contexts. The protocol primitive is there, but every exchange, marketplace, settlement venue, and multi-party payment application that needs commit-or-abort semantics across more than two legs today builds its own multi-leg orchestration: allocation ordering, preapproval composition, timeout handling, partial-fulfillment recovery, counterparty-signature coordination. That fragments the ecosystem — wallets and custodians cannot integrate consistently across multi-leg settlement applications because each one defines its own settlement shape.
This proposal ships the standardized reference implementation that turns "build a settlement layer" into "integrate the settlement primitive."
Scope
Four workstreams:
- Workstream A — Multi-Leg Allocation Orchestrator: Daml templates composing CIP-0056 allocations into atomic multi-leg transactions, with parametric orchestrator-controller role per integration shape (venue-operator, marketplace-platform, peer-co-controllers, escrow-agent, attestor)
- Workstream B — Five named institutional settlement patterns: DvP, PvP, Multi-Party, Conditional, Batched, each as a parameterized profile of the orchestrator with a CIP-0104 reward-shaping anti-patterns guide
- Workstream C — TypeScript and Go client libraries with a parity-validated test suite (CI fails on cross-language divergence)
- Workstream D — DFBA reference integration: extends Avro Digital's in-tree DFBA settlement engine with the multi-leg primitive, preserving DFBA's existing 2-leg path unchanged
Reference integration
DFBA (Decentralized Frequent Batch Auction) is the committed reference integration. Appendix D maps the orchestrator concepts onto DFBA's concrete Settlement / IntentFundLock templates, the operator orchestrator-controller, the private-sync synchronizer routing (DFBA's parties are Avro-internal), and the saga-compensator extension. The DvP / PvP / Multi-Party patterns are staged end-to-end in DFBA's make test-devnet-e2e harness; Conditional and Batched are validated as parametric Daml-test fixtures in the primitive's own test harness because DFBA does not implement an oracle-attestor or N-transaction batch composer (a documented feasibility carve-out, not a deferred deliverable).
Composition with existing Canton primitives
The proposal extends rather than replaces. Existing Ecosystem Fit table covers CIP-0056 (composes; v2 alignment in M3), CIP-0103 (composes), CIP-0104 (composes; perverse-incentive surface acknowledged), Splice / Amulet (consumed as-is), PR #76 (Logical Synchronizer Upgrades), PR #186 (CC20 yield), PR #73 (institutional credit), PR #78 (x402), CantonSwap, and the active in-flight token-standard / settlement / yield grants.
Single-objective discipline
The proposal targets a single objective — the multi-leg allocation primitive. Settlement venues, order books, marketplaces, custody solutions, and CIP-0056 changes are explicit non-goals. The five patterns in Workstream B are parameterizations of the same orchestrator, not independent primitives; they are bundled because real applications routinely compose patterns (a DEX with maker-rebate flows uses DvP + Multi-Party + Batched together) and pattern bundling lets every settlement-shaped application adopt the primitive without picking a flavor.
Open source
All deliverables Apache 2.0, public Avro Digital repository.
Refs
- HOUSE_STYLE.md codified patterns 9–13 (architectural-integration rules)
- Companion proposal: W14 Payment Dispute & Reversal Primitive (filed in parallel)
- Avro Digital prior work: SV Governance dApp grant (PR #223), CIP-0105 SV-locking proposal, DFBA, xCC, Avro Pay
