> ## Documentation Index
> Fetch the complete documentation index at: https://musubinetwork.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy

> Canton participant + Musubi backend in your infrastructure — provisioning, connectivity, and Day-2 operations.

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

```mermaid actions=false theme={null}
graph LR
  subgraph Your Infrastructure
    CP[Custody Platform] -->|authorize holdings| MB[Musubi Backend<br/>REST + SSE]
    MB --> CP_DB[(PostgreSQL)]
    MB --> CANTON[Canton participant<br/>your Party ID]
  end
  CANTON -->|TLS| SN[Settlement Network]
  MB -->|audit exports| ARCH[Your audit-log archive]
```

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

## Onboarding

<Steps>
  <Step title="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
  </Step>

  <Step title="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
  </Step>

  <Step title="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.
  </Step>

  <Step title="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
  </Step>

  <Step title="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`
  </Step>
</Steps>

## 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:

| Metric            | Description                                                      |
| ----------------- | ---------------------------------------------------------------- |
| Orders by status  | PENDING / QUOTED / EXECUTING / SETTLED / FAILED / EXPIRED counts |
| Settled volume    | Total JPYSC0 and USDCx settled through your custody              |
| Recent settlement | Last 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](/custodian/integration/console) and settlements flow through as [Audit Exports](/custodian/integration/audit-exports). For custodians integrating their own systems directly, see [Programmatic Access](/custodian/integration/programmatic-access).