Canton Network
— and the layer above it.

Canton is best understood not as a blockchain, but as a privacy-preserving synchronisation protocol for multi-party workflows in regulated markets. Public chains optimise for shared visibility and permissionless composition. Traditional permissioned DLT optimises for control but fragments interoperability. Canton sits in the gap: independent participants run their own nodes, hold only the contracts they are entitled to see, and coordinate state changes through synchronisers that order transactions without seeing their contents.

Three primitives. The rest of the architecture follows from them.

The four-layer wiring (apps → participant nodes → synchronisers → ledger) is in slide 03. The property: selective disclosure with global coordination — shared truth without globally readable state.

The brief asked for a description of what to build, not generic platform copy. The repo at naimkatiman/hydrax-app is the implementation; the live app is the running surface.

The premise: institutions need the workflow, identity, approval, audit, notification, and integration layer above the ledger — what an issuer, distributor, custodian, ops team, and investor each operate. HydraX has the rails (tokenisation, custody, trading, regulatory licences in MY/SG); this is the operational platform above them.

1. Single-synchroniser to start. Multi-domain Canton is real complexity for a real benefit; deferred until a tenant needs cross-domain composition.
2. Web2 owns identity, UI, documents, notifications, reporting. Web3 owns shared truth and controlled state transitions. See slide 04 ("Where Canton stops") for the boundary.
3. Browser never touches Daml directly. All ledger I/O routes through Go adapters with audit on the way in and event-stream projections on the way out.
4. Tenant isolation and role-based disclosure from day one, not retrofitted. Each portal is its own role-scoped shell, not the same SPA with feature flags.
5. First wedge is narrow: institutional onboarding + product issuance + subscription servicing. Not secondary market, not portfolio analytics, not a generalised workflow engine.

Slide 04 is the core tension. Public chains get composability because state is globally readable; that property is what disqualifies them for regulated workflows. Canton's contract-level privacy means a custodian doesn't see a competing custodian's positions on the same domain — and it means you cannot compose blindly. Cross-contract logic requires every relevant party to be a stakeholder on every relevant contract. Feature for compliance, constraint for builders.

The implication: composability moves from the ledger to the orchestration plane. The workflow service has to bring the right parties onto a contract at issuance time so the downstream choices are possible. Get this wrong at modelling time and no UI work fixes it.

A common mistake is treating "the app" as a thin wrapper around Daml choices. 80% of institutional value lives in what surrounds the choice: who approved it, what evidence was attached, which SLA clock is running, what notification fired, what audit row was written.

That's why the orchestration plane has more services than the rails plane (workflow-svc, approval-svc, audit-svc, notify-svc, integration-svc, bff). Single-purpose services with their own state machines and `/healthz` endpoints keep debugging, scaling, and tenant isolation tractable. A monolith would have been faster to ship and harder to operate at multi-tenant scale.

Daml upgrade paths are real, but the operational question is harder than the technical one. When entitlements change — a distributor loses a licence, a regulator's reporting party rotates — what happens to in-flight contracts?

Daml gives you the upgrade primitive (interfaces, package versioning), but you still need (a) a deterministic projection of "what's in flight at cutover", (b) a migration plan per contract template, (c) a fallback for participants who haven't accepted the new package, (d) an audit trail that proves no economic state changed during the swap. Not solved — but the lifecycle decisions are isolated in the rails-plane adapters, where they belong.

What's not built, and the reason for each.

• Real HydraX rails integration. The adapter is mocked behind a stable interface, waiting on HydraX engagement to share the API surface. The workflow layer is not blocked by this.
• Multi-domain Canton. Single-synchroniser default. Multi-domain when a tenant pays for the complexity.
• Generalised workflow DSL. Concrete templates for the first wedge (onboarding, issuance, subscription) ship before any DSL.
• Secondary market UX, portfolio analytics, advanced token econ. Explicitly out of MVP scope.
• Open product-type questions. Fund vs. structured product vs. private credit vs. treasury still parked. Current default proposal: short-duration credit (30–180d institutional tenor).

1. Built the mental model from first principles (rails vs. layer above) before reading docs, so I had questions to test against the docs rather than absorb passively.
2. Confirmed against Canton + Daml official documentation. Used Context7 MCP for current SDK references.
3. Mapped each Canton primitive to a real institutional workflow (subscription, approval chain, audit) before touching code.
4. Built the prototype to find where the model breaks — the deferrals above are the points I hit.
5. Wrote the deck last. Drawing the system forced me to defend each box.