What’s net-new for your stack
Three integration points. Everything else in your custody stack stays where it is.| Seam | What you wire | Why |
|---|---|---|
| Canton participant + Musubi backend | Deploy the Musubi custodian backend in your infrastructure with a Canton Party ID | This is your identity on the settlement network; your signing key here becomes your co-signer on every DvP |
| Order proposal review + quote co-signature | Wire GET /api/v1/orders and the accept endpoints into your ops UI | You review competing market maker quotes and co-sign the chosen one — this is the authorization gate |
| Settlement event → accounting | Subscribe to the SSE stream for SETTLED events and hand transaction_hash to your accounting systems | One-way fan-out. Musubi emits, your systems consume |
For how Canton’s custody and transfer model differs from EVM/UTXO at the protocol level, see Ethereum vs Musubi. The Canton Holding model (sole-signatory, no allowance pattern) is covered in Settlement & Safekeeping.
Two Distinct Roles
- Sender Custodian
- Receiver Custodian
You’re not just holding and releasing assets — you’re an active participant in an FX workflow.
- See order proposals from your institutional clients and accept / reject them
- Review competing market maker quotes — unusual for a custodian, but you’re the authorization gate for best execution
- Co-sign the best quote alongside the institution (dual authorization)
- Your co-signature is one of four required for the atomic DvP settlement
Guide Structure
Authorization Workflow
How multi-party DvP co-signing works, quote review, and how this differs from standard multisig.
Settlement & Safekeeping
Atomic DvP mechanics, Canton Holding model vs ERC-20, asset movements, reconciliation.
Security
Signing authority, Canton privacy vs public chain transparency, data isolation.
Integration
Deploy + Console + Audit Exports, with a programmatic access path for custodians who need it.
API Reference
Endpoints, accept quote examples, SSE events, order lifecycle.