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
nullfor DAML optional fields in JSON (never rely onundefinedsurviving 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.