One paragraph per slide. Read the deck out loud in five.

On screen: deck cover (slide-0).

Hello, I'm Naim. Over the last few weeks I've built a workflow platform for institutional tokenisation that sits on top of HydraX's regulated rails and a Canton synchronizer. Thesis in one sentence: Canton owns the shared truth, we own the path that gets there. It's live on Railway, five Daml scripts run green.

On screen: trust-boundary diagram (slide-1).

The whole presentation hangs on this slide. Clean trust boundary down the middle. On the left, Canton — multi-party truth on Daml, sub-transaction privacy, atomic cross-institution commits. On the right, the application layer — five role-scoped React portals, workflow state machines with SLA timers, approval ceremonies that gate on-chain commands, plus notification, KYC, and audit fabric. The browser never holds rails credentials.

On screen: three pillars (slide-2).

Why Canton. Three primitives. First, selective disclosure — signatories see full state, observers get a scoped view, no global state. Privacy by design, the way regulated finance actually needs it. Second, atomic interop — trade and settlement commit together across domains, all-or-nothing, no reconciliation glue between institutions. Third, multi-party coordination — issuer, distributor, custodian, regulator each get authorisation rules enforced by the contract itself.

On screen: participant nodes + synchronizer (slide-3).

Quick wiring diagram. Four layers. Top — the application, our portals and orchestration. Below, participant nodes — each institution runs one, holding its private slice. Below that, the synchronizer — Canton's sequencing fabric, the thing that orders multi-party commits. Underneath, Daml — the contract language and runtime. Commands flow down, events flow back up. Our code only ever talks to the participant node.

On screen: boundary table (slide-4).

The boundary slide — load-bearing. Canton handles shared truth, atomic transitions, signatory disclosure, multi-party authorisation. Canton does not handle SLA timers, retry policy, human approvals with escalation, KYC pipelines, audit outside the ledger, role-aware UI, or notifications. Every one of those is on the app side. Put SLA logic inside Daml and you regret it within a week. Recreate Canton's commits in your app and you regret it forever.

On screen: three-plane stack (slide-5).

Above the rails, three planes. Plane one, rails. Two adapters — hydrax-adapter and canton-adapter — translate domain commands into HydraX REST calls and Daml commands. The hydrax-adapter mock now covers issue, subscribe, transfer custody, settle, and NAV. The canton-adapter ships an in-memory ledger with parties, commands, and event polling. Plane two, orchestration. Nine Go and Node services — workflow, approval, audit, notify, integration, BFF, market-data, plus the two adapters — each owning one concern. Plane three, UX. Five React portals — issuer, distributor, investor, ops, admin — same component library, role-scoped at the route.

On screen: investor → workflow → approval → notify → rails → audit (slide-6).

One workflow end-to-end. An investor opens the portal, submits a subscription. workflow-svc validates and forwards to approval-svc, which opens the ceremony, starts an SLA timer, routes to approvers. notify-svc fans out an email and a toast. The approver clicks accept; workflow-svc reads the lifecycle as approved and calls hydrax-adapter, which posts to the HydraX issuance endpoint. canton-adapter commits the Daml command on the synchronizer. The event flows back through audit-svc, the UI refreshes, the investor sees their subscription allocated. Submit to ledger — every state change provable, attributable, replayable. That's the whole product in one diagram.

On screen: status grid (slide-7).

Status, grounded in commits. Five Daml scripts green. Nine backend services with health checks, persistence, per-service tests. Five React portals live across three Railway services — institutional landing, Canton homework site, original prototype. Auth substrate complete: passkeys, magic-link over SMTP, dev login removed. Subscription lifecycle and approvals persisted in Postgres. Q3 credit FSM wired. The mocked HydraX adapter is a deliberate bet — workflow ships now, real API drops in later.

On screen: trade-offs + roadmap (slide-8).

Trade-offs and roadmap. Today, scope is disciplined — single synchronizer, mocked rails, demo-mode portals, no secondary market UX. Right cut for v1. Next — ship portal auth UI, connect the real HydraX adapter when the API drops, harden audit-svc for institutional retention, start a pilot with a real issuer and distributor. Four open PRD questions: rails surface, product type, tenant persona, pricing. Decision memos exist for each. None block the stack. The rails are yours. The layer above is moving. Thank you.