Milestone 3 — Production Hardening, Canton-Specific Patterns, Observability & Mobile
Estimated Delivery: 3 weeks Funding: 100,000 CC
Effort Rationale: Approximately 3 weeks of full-team engineering effort distributed across vertical-specific dApp templates (~25%), Canton-specific developer patterns (~20%), application-layer UI primitives and theme system (~15%), production observability layer and structured logging (~15%), React Native bindings (~10%), error taxonomy design and integration (~10%), and PartyLayer Production Migration Checklist with performance optimization (~5%). The vertical templates serve as integration vehicles that exercise and validate the application-layer patterns, UI primitives, and Canton-specific helpers established in earlier deliverables, reducing redundant implementation work. This milestone carries the highest production-readiness burden, balanced by reusing patterns and primitives established in earlier milestones.
Deliverables:
- Canton-Specific Developer Patterns
Privacy-aware query helpers (view decomposition handling, witness filtering) Multi-party transaction flow patterns (multi-confirmer workflows, atomic settlement coordination) CIP-0056 token standard interaction helpers (holdings queries, transfer instruction submission, allocation flows for FoP and DvP-style workflows) Explicit contract disclosure helpers (auto-attach disclosed_contracts on Ledger API commands, leveraging Daml's explicit disclosure feature) * Synchronizer-aware operation utilities (multi-synchronizer party operations)
- Vertical-Specific dApp Templates
Reference dApp templates that compose PartyLayer's application-layer surface — framework-native hooks, UI primitives, Canton-specific patterns, and CIP-0104 cost visibility — in production-oriented examples of real Canton use cases. These are not reference implementations of the base Canton dApp SDK; they are application-layer references that demonstrate how teams can build production-grade Canton dApps on top of the canonical SDK foundation.
Tokenization Template — issuance, transfer, and holdings management flows built on the CIP-0056 token standard Issuer dashboard with mint, freeze, and supply management UI User-facing holdings view via useHoldings and <PartyAvatar /> Transfer flow using CIP-0056 transfer instructions with <TransactionToast /> lifecycle UI CIP-0104 cost preview before signing via <CostPreview /> Multi-party demonstration (issuer party + user party) with wallet-switch-safe state * Typed Daml contract reads via useDamlContract with generated DAR types
DvP Settlement Template — atomic delivery-versus-payment flows between two parties, exercising the deepest set of Canton-specific patterns Two-party UI (buyer + seller) with multi-confirmer transaction workflow Atomic settlement coordination via CIP-0056 allocation flow (proposed → counter-signed → executed → settled lifecycle states) Explicit contract disclosure auto-attach for cross-party visibility Privacy-aware queries demonstrating per-party witness filtering Synchronizer-aware operations with <SynchronizerSwitcher /> for multi-synchronizer settlements * CIP-0104 cost preview per settlement leg
Each template ships as an open-source GitHub repository with a working DevNet deployment, README with documented user flows, and deployment instructions. Templates are reference quality — they demonstrate composition patterns and exercise PartyLayer's stack end-to-end — and are explicitly not production-audited integrations.
- Application-Layer UI Primitives
<TransactionToast /> — transaction lifecycle UI (preparing → submitted → confirmed → finalized → failed states) <CostPreview /> — CIP-0104 cost visualization component (built in M2, extended here with theme integration) <PartyAvatar /> — party identity display with metadata resolution <SynchronizerSwitcher /> — multi-synchronizer selection modal * Theme system (light / dark / Canton variants with configurable accent color, border radius, font stack)
- Production Observability Layer
Application-level event emission across integration lifecycle phases (connect, authorize, prepare, submit, confirm, error) Vendor-neutral adapter interfaces for optional integration with external monitoring tools (OpenTelemetry, Sentry, Datadog) * No network-level telemetry, no centralized tracking, no user-identifying data collection
- Structured Logging Hooks
Standardized, machine-readable log events for each application-layer interaction phase Configurable verbosity levels (debug, info, warn, error) * Correlation identifiers for tracing multi-step wallet operations
- Standardized Error Taxonomy
* Canonical error classification aligned with CIP-0103 response categories
