Skip to content

OCP Canton SDK

Architecture

How ocp-canton-sdk layers on canton-node-sdk and how source folders are organized.

Layer stack

@open-captable-protocol/canton   ← OCP SDK (this package)
        │  peers
@fairmint/canton-node-sdk        ← Ledger / Validator / Scan clients

Canton Network / DAML

Runtime documentation for the lower layer: Canton Node SDK — sdk.canton.fairmint.com

High-level tree

src/
├── functions/
│   ├── OpenCapTable/        # Per-entity OCF ↔ DAML
│   ├── CantonPayments/
│   └── OpenCapTableReports/
├── types/
├── utils/
└── OcpClient.ts             # Facade over injected clients

Each OCF entity gets its own folder under OpenCapTable/{entity}/ with converters (*ToDaml.ts, get*AsOcf.ts, optional create*.ts). Central dispatchers only route to those modules — implementation lives beside the entity.

Non-negotiables (summary)

  • Strict TypeScript — avoid any; narrow unknowns early.
  • Fail fast with actionable errors (Ocp* hierarchy).
  • Use null for DAML optional fields in JSON (never rely on undefined surviving serializers).
  • Explicit field mapping in converters — no blind spreads from unvalidated OCF input.
  • Pin peer dependency ranges per repo policy (see wiki).

User-oriented API names: Reference · Batch cap-table API: Workflow recipes → Batch.