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

# Custodian Overview

> What changes in a digital asset custodian's stack when connecting to Musubi.

You already custody stablecoins: key management, whitelisting, multisig, on-chain settlement. Musubi keeps all of that. What it adds is an active role in a multi-party FX settlement workflow — your cryptographic co-signature is one of four required for every atomic DvP.

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

See [Integration Guide](/custodian/integration-guide) for the architecture and onboarding.

<Info>
  For how Canton's custody and transfer model differs from EVM/UTXO at the protocol level, see [Ethereum vs Musubi](/ethereum-comparison). The Canton Holding model (sole-signatory, no allowance pattern) is covered in [Settlement & Safekeeping](/custodian/settlement-and-safekeeping).
</Info>

## Two Distinct Roles

<Tabs>
  <Tab title="Sender 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
  </Tab>

  <Tab title="Receiver Custodian">
    Familiar territory: receive stablecoin deposits and credit client balances. The main difference is that deposits arrive via atomic DvP — fully settled on arrival, no confirmation wait.

    * Receive USDCx deposits from settled trades
    * Settlement confirmations arrive on your node automatically
    * Update your client's balance — the deposit is final, not pending
  </Tab>
</Tabs>

## Guide Structure

<CardGroup cols={3}>
  <Card title="Authorization Workflow" icon="key" href="/custodian/authorization-workflow">
    How multi-party DvP co-signing works, quote review, and how this differs from standard multisig.
  </Card>

  <Card title="Settlement & Safekeeping" icon="vault" href="/custodian/settlement-and-safekeeping">
    Atomic DvP mechanics, Canton Holding model vs ERC-20, asset movements, reconciliation.
  </Card>

  <Card title="Security" icon="lock" href="/custodian/security">
    Signing authority, Canton privacy vs public chain transparency, data isolation.
  </Card>

  <Card title="Integration" icon="plug" href="/custodian/integration/overview">
    Deploy + Console + Audit Exports, with a programmatic access path for custodians who need it.
  </Card>

  <Card title="API Reference" icon="code" href="/custodian/api-reference">
    Endpoints, accept quote examples, SSE events, order lifecycle.
  </Card>
</CardGroup>