Skip to main content
The backend runs in your infrastructure, protected by your existing network and key-management controls. This page walks onboarding, verification, and the Day-2 operational surface.

​
Deployment architecture

Two processes, one Postgres instance, TLS to the settlement network — that’s the footprint.

​
Onboarding

1

Receive credentials

Musubi provisions:
  • Canton Party ID — your identity on the settlement network
  • JWT signing credentials — for API authentication
  • Network connectivity details — settlement network endpoint + TLS certificates
2

Deploy the backend

Deploy the Musubi custodian backend in your infrastructure:
  • Configure with your Party ID and role (custodian-sender or custodian-receiver)
  • Point it at your PostgreSQL instance
  • Establish TLS connectivity to the settlement network
3

Whitelist the settlement address

Whitelist the Musubi settlement address in your custody platform. One-time setup. This is the only destination that receives assets during DvP.
4

Onboard institutional clients

For each institution that will use you as custodian:
  • Set up their custody account in your platform (your existing process)
  • Confirm their Canton Party ID
  • Ensure sufficient stablecoin balance
  • They reference your Party ID when creating orders
5

Connectivity test

  • GET /health — backend is running and connected
  • GET /whoami — correct Party ID and custodian role
  • Have your integration contact create a test order referencing your Party ID
  • Confirm the order appears in GET /api/v1/orders

​
TLS + networking

  • All traffic to the settlement network is mTLS. Certificates are provisioned as part of your credentials.
  • The backend’s REST + SSE endpoints should terminate behind your own TLS ingress.
  • Outbound egress from the backend to the settlement network endpoint must be allowed through your firewall.
  • The PostgreSQL instance should sit on a private subnet; the backend connects via your internal connection string.

​
Day-2 operations

​
Monitoring

GET /api/v1/dashboard/stats provides:
MetricDescription
Orders by statusPENDING / QUOTED / EXECUTING / SETTLED / FAILED / EXPIRED counts
Settled volumeTotal JPYSC0 and USDCx settled through your custody
Recent settlementLast settlement timestamp and average settlement time
Watch for:
  • PENDING accumulating — quoting issues or institution-side delays
  • FAILED orders — investigate failure_reason, notify the affected institution
  • Volume spikes — ensure sufficient stablecoin balances

​
Institution relationships

Institutions reference your Party ID (sender_custodian_party_id or receiver_custodian_party_id) when creating orders. Practical implications:
  • Onboard them first — institutions can’t reference you until you’ve set up their custody account
  • Multiple institutions can reference you simultaneously
  • You see all orders where you are the custodian, across all institutional clients
Establish operational contacts for escalation, balance notifications, and reconciliation cadence. The settlement protocol handles per-transaction authorization — you don’t need to coordinate per-trade with institutions.

​
Testnet validation

Scenarios to run before production:
  1. Sender custodian happy path — see proposal → accept → review quotes → co-sign best quote → verify SETTLED
  2. Receiver custodian happy path — verify settlement confirmation arrives with correct amounts
  3. Reject proposal — reject a proposal, verify the order is cancelled
  4. Quote expiry — wait for quotes to expire, verify EXPIRED transition
  5. Reconciliation — match transaction_hash, amounts, and timestamps across your systems
  6. Audit export — run your first batch download against settled testnet orders and confirm it reconciles

​
Next steps

Once deployed, your ops team logs into the Console and settlements flow through as Audit Exports. For custodians with custom compliance rails, see Programmatic Access.