DTCC Tokenization Service - July Event

Blockdaemon offers a stack of Canton Validator + DTCC Besu AppChain + Institutional Vault (IV) custody to two audiences:

• Participant Members (banks, broker-dealers)
• End Investors (asset managers, hedge funds, corporates): Onboarded by a Participant Member.

---

Canton Systems Architecture — Where Participants Fit

%%{init: {'themeVariables': { 'fontSize': '11px' }}}%%
flowchart TB
    subgraph DTCC_LAYER["🏛️ DTCC SETTLEMENT & GOVERNANCE"]
        direction LR
        REG["<b>Registrar · DTCC Ops</b><br/>────────────────<br/>Instrument Mint / Burn<br/>Master Allow-List"]
        COMP["<b>Compliance Officer</b><br/>────────────────<br/>Freeze / Clawback<br/>Pause Instruments"]
    end

    subgraph BROKER_LAYER["DTCC MEMBER PARTICIPANTS"]
        direction LR
        PB_A["<b>Participant A</b><br/>────────────────<br/>Participant Service<br/>Investor Onboarding<br/>Allow-List Management"]
        PB_B["<b>Participant B</b><br/>────────────────<br/>Participant Service<br/>Investor Onboarding<br/>Allow-List Management"]
    end

    subgraph INVESTOR_LAYER["👤 END INVESTORS"]
        direction LR
        INV1["<b>Institutional Investors</b>"]
        INV2["<b>Asset Managers</b>"]
        INV3["<b>Hedge Funds</b>"]
    end

    REG -- "Credentials &<br/>Allow-List" --> BROKER_LAYER
    COMP -. "Regulatory<br/>Oversight" .-> BROKER_LAYER
    PB_A -- "Onboards &<br/>Manages" --> INV1
    PB_A -- "Onboards &<br/>Manages" --> INV2
    PB_B -- "Onboards &<br/>Manages" --> INV3

---

DTCC Canton Participant Member Onboarding Flow

%%{init: {'themeVariables': { 'noteBkgColor': '#9370DB', 'noteTextColor': '#ffffff', 'noteBorderColor': '#4B0082' }}}%%
sequenceDiagram
    participant PB as Participant Member
    participant CO as DTCC<br/>Client Onboarder
    participant REG as DTC<br/>Registrar
    participant ML as Master<br/>Allow-List

    Note over PB,ML: Participant Member Onboarding

    PB->>CO: Submit ParticipantOnboardingRequest
    CO->>CO: Validate credentials against requirements
    CO->>PB: Create ParticipantService
    CO->>PB: Issue Credential (isMemberOfAllowList)
    CO->>PB: Create Participant Member AllowList
    CO->>PB: Grant ClawbackReceiverDelegation
    CO->>PB: Grant HoldingOperationsDelegation
    CO->>ML: Add Participant Member AllowList → Master AllowList

    Note over PB,ML: ✅ Participant Member is now fully onboarded

---

DTCC Canton End Investor Onboarding Flow

%%{init: {'themeVariables': { 'noteBkgColor': '#9370DB', 'noteTextColor': '#ffffff', 'noteBorderColor': '#4B0082' }}}%%
sequenceDiagram
    participant PB as Participant Member
    participant ML as Master<br/>Allow-List
    participant EI as End<br/>Investor

    Note over PB,EI: End Investor Onboarding

    PB->>EI: Offer EndInvestorOnboarding
    EI->>EI: Accept → receives Credential + Delegations
    PB->>ML: Add investor to Participant Member AllowList

    Note over PB,EI: ✅ End Investor can now hold & transfer tokenized securities

---

Canton Transaction Signing Flow (simplified)

This is a simplified view of submitting a Canton operation through Institutional Vault: authentication, intent submission, policy evaluation, human approval, MPC signing, and ledger submission. Approval signatures are separate from MPC transaction signatures, as described in Transaction and approval flows.

%%{init: {'themeVariables': { 'noteBkgColor': '#9370DB', 'noteTextColor': '#ffffff', 'noteBorderColor': '#4B0082' }}}%%
sequenceDiagram
    autonumber

    participant Client as Wallet Client /<br/>Customer System(s)
    participant IdP as Blockdaemon IdP

    box rgba(147, 112, 219, 0.2) Institutional Vault
        participant CCM as Canton Contract<br/>Management UI
        participant Vault as Wallet API
        participant PN as Policy Nodes (3x)
    end
    participant AA as ApproverApp
    participant Val as Canton Validator<br/>(Ledger API)

    Note over Client,IdP: Sign in
    Client->>IdP: OIDC login
    IdP-->>Client: Access token

    Note over Client,Val: Submit Canton operation
    Client->>CCM: Prepare transaction intent<br/>(transfer / allocations / enrollment accept)
    CCM->>Vault: Start operation (CWP intent)
    Vault->>PN: Policy evaluation

    PN->>AA: Approval request
    AA-->>PN: Approval signature

    Note over PN: MPC threshold signing
    PN-->>Vault: Signed Canton transaction

    Vault->>Val: Submit via Ledger API
    Val-->>CCM: Ledger result

---

Deployment models

Blockdaemon offers three Institutional Vault custody options for the July event, ordered from the smallest customer footprint to full self-custody. Organizations may begin on Blockdaemon-hosted Vault and later adopt Hybrid or customer-hosted Vault using a planned migration (database backup/restore and MPC key reshare). Canton party identity on-ledger is unchanged across those transitions.

In every model, Blockdaemon operates the Canton Validator and, where required, DTCC Besu AppChain RPC connectivity. The models differ in who runs the wallet UI/API, message broker, and three MPC policy nodes.

---

Model - Fully Blockdaemon Hosted

Recommended starting point for the July event. Blockdaemon hosts the full Institutional Vault (wallet UI/API, message broker, three policy nodes, databases, and observability) plus the Canton Validator and DTCC Besu AppChain RPC. The customer supplies only ApproverApp on mobile or desktop so designated users can approve transaction intents and policy updates.

Customer systems and browsers reach Vault over outbound HTTPS only; see Networking and firewall for egress requirements.

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    subgraph CUST["Customer"]
        CSYS["Customer<br/>System(s)"]
        WEB["🌐 Web Browser"]
        AA["ApproverApp 🔑<br/>(mobile/desktop)"]
    end
    subgraph BD["Blockdaemon"]
        direction TB
        subgraph IV["Institutional Vault"]
            API["Wallet UI / API<br/>+ Wallet DB"]
            BROKER["Message Broker"]
            MPA0["MPC Policy-Node 0 🔑<br/>+ DB"]
            MPA1["MPC Policy-Node 1 🔑<br/>+ DB"]
            MPA2["MPC Policy-Node 2 🔑<br/>+ DB"]
        end
        subgraph VAL["Canton Validator"]
            direction TB
            LAPI["Ledger API<br/>(gRPC / JSON)"]
            subgraph CTEN["Customer Tenant IdP"]
                TENANT_DATA["Users + External Parties"]
            end
            DARS["DARs"]
        end
        BESU["DTCC Besu<br/>AppChain Node"]
    end
    CSYS -- "HTTPS" --> API
    CSYS -- "HTTPS" --> LAPI
    AA -- "HTTPS" --> API
    WEB -- "HTTPS" --> API
    API -- "mTLS" --> BROKER
    MPA0 -- "mTLS" --> BROKER
    MPA1 -- "mTLS" --> BROKER
    MPA2 -- "mTLS" --> BROKER
    API -- "Ledger API" --> LAPI
    API -- "RPC" --> BESU
    LAPI --- TENANT_DATA
    classDef bd fill:#e8e0ff,stroke:#4B0082,color:#000
    classDef cust fill:#d4f1d4,stroke:#1f7a1f,color:#000
    class API,BROKER,MPA0,MPA1,MPA2,LAPI,TENANT_DATA,DARS,BESU bd
    class AA,WEB,CSYS cust

• Blockdaemon operates: Canton Validator, DTCC Besu AppChain RPC, Wallet UI/API, Message Broker, 3× MPC Policy-Nodes, all DBs, observability, attestation infrastructure.
• Identity and Authentication: Institutional Vault uses the Blockdaemon OIDC Identity Provider for the July event. Customers sign up new Vault accounts on the Blockdaemon IdP (not a customer-owned IdP). Account email addresses must be provided to Blockdaemon ahead of time so users can complete sign-up and ApproverApp onboarding before go-live.
• Customer operates: ApproverApp(s) only. Transaction intent approval signing.
• Time to onboard: Hours to days.

---

Model - Hybrid (Customer Runs One MPC Policy-Node)

Blockdaemon hosts Validator + 2 of 3 MPC Policy-Nodes. Customer hosts a single MPC Policy-Node binary connected over the network to Blockdaemon's Message Broker.

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    subgraph CUST["Customer"]
        CSYS["Customer<br/>System(s)"]
        WEB["🌐 Web Browser"]
        AA["ApproverApp 🔑<br/>(mobile/desktop)"]
        MPA2["MPC Policy-Node 2 🔑<br/>+ DB"]
    end
    subgraph BD["Blockdaemon"]
        direction TB
        subgraph IV["Institutional Vault (partial)"]
            API["Wallet UI / API<br/>+ Wallet DB"]
            BROKER["Message Broker"]
            MPA0["MPC Policy-Node 0 🔑<br/>+ DB"]
            MPA1["MPC Policy-Node 1 🔑<br/>+ DB"]
        end
        subgraph VAL["Canton Validator"]
            direction TB
            LAPI["Ledger API<br/>(gRPC / JSON)"]
            subgraph CTEN["Customer Tenant IdP"]
                TENANT_DATA["Users + External Parties"]
            end
            DARS["DARs"]
        end
        BESU["DTCC Besu<br/>AppChain Node"]
    end
    CSYS -- "HTTPS" --> API
    CSYS -- "HTTPS" --> LAPI
    AA -- "HTTPS" --> API
    WEB -- "HTTPS" --> API
    API -- "mTLS" --> BROKER
    MPA0 -- "mTLS" --> BROKER
    MPA1 -- "mTLS" --> BROKER
    MPA2 -- "mTLS" --> BROKER
    API -- "Ledger API" --> LAPI
    API -- "RPC" --> BESU
    LAPI --- TENANT_DATA
    classDef bd fill:#e8e0ff,stroke:#4B0082,color:#000
    classDef cust fill:#d4f1d4,stroke:#1f7a1f,color:#000
    class API,BROKER,MPA0,MPA1,LAPI,TENANT_DATA,DARS,BESU bd
    class AA,WEB,CSYS,MPA2 cust

• Blockdaemon operates: Canton Validator, DTCC Besu AppChain RPC, Wallet UI/API, Message Broker, MPC Policy-Nodes 0–1 + DBs, observability for Blockdaemon-side components.
• Identity and Authentication: Vault UI and ApproverApp login use the Blockdaemon OIDC Identity Provider. Customers sign up new accounts on the Blockdaemon IdP; email addresses must be provided ahead of time for provisioning and sign-up.
• Customer operates: ApproverApp, MPC Policy-Node 2 + DB, secrets manager, monitoring for their node.
• Time to onboard: 1–3 weeks. Customer infra build-out, key ceremony, node monitoring runbook.

---

Model - Customer-Hosted IV (Full Self-Custody)

Blockdaemon hosts only the Canton Validator. Customer hosts the entire IV deployment.

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    subgraph CUST["Customer"]
        CSYS["Customer<br/>System(s)"]
        WEB["🌐 Web Browser"]
        AA["ApproverApp 🔑<br/>(mobile/desktop)"]
        subgraph IV["Institutional Vault (full)"]
            API["Wallet UI / API<br/>+ Wallet DB"]
            BROKER["Message Broker"]
            MPA0["MPC Policy-Node 0 🔑<br/>+ DB"]
            MPA1["MPC Policy-Node 1 🔑<br/>+ DB"]
            MPA2["MPC Policy-Node 2 🔑<br/>+ DB"]
        end
    end
    subgraph BD["Blockdaemon"]
        subgraph VAL["Canton Validator"]
            direction TB
            LAPI["Ledger API<br/>(gRPC / JSON)"]
            subgraph CTEN["Customer Tenant IdP"]
                TENANT_DATA["Users + External Parties"]
            end
            DARS["DARs"]
        end
        BESU["DTCC Besu<br/>AppChain Node"]
    end
    CSYS -- "HTTPS" --> API
    CSYS -- "HTTPS" --> LAPI
    AA -- "HTTPS" --> API
    WEB -- "HTTPS" --> API
    API -- "mTLS" --> BROKER
    MPA0 -- "mTLS" --> BROKER
    MPA1 -- "mTLS" --> BROKER
    MPA2 -- "mTLS" --> BROKER
    API -- "Ledger API" --> LAPI
    API -- "RPC" --> BESU
    LAPI --- TENANT_DATA
    classDef bd fill:#e8e0ff,stroke:#4B0082,color:#000
    classDef cust fill:#d4f1d4,stroke:#1f7a1f,color:#000
    class LAPI,TENANT_DATA,DARS,BESU bd
    class AA,WEB,CSYS,API,BROKER,MPA0,MPA1,MPA2 cust

• Blockdaemon operates: DTCC Besu AppChain RPC and the Canton Validator.
• Customer operates: Full IV stack: Wallet UI/API, Message Broker, all 3 MPC Policy-Nodes + DBs, secrets, observability, ApproverApp.
• Identity and Authentication: Vault UI, ApproverApp, and programmatic API access use the customer's OIDC identity provider.
• Time to onboard: 3–6 months. Full infra transfer, training, key ceremony, runbook handoff.

---

Networking and firewall (customer egress)

Fully Blockdaemon Hosted requires outbound connectivity from the customer network only. Blockdaemon hosts Institutional Vault and the Canton Validator; the customer does not open inbound firewall rules for Vault or Canton. Allow TCP 443 (HTTPS / TLS) unless noted. Production hostnames are provisioned at onboarding.

Blockdaemon provides the final hostnames and TLS trust anchors after sign-up and deployment.

---

Comparison

---

Migration path

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    M1["Fully Blockdaemon Hosted"]
    M2["Hybrid"]
    M3["Full Self-Custody"]

    M1 -- "State Backup/Restore<br/>+ Key Reshare" --> M2
    M2 -- "State Backup/Restore<br/>+ Key Reshare" --> M3
    M1 -. "State Backup/Restore<br/>+ Key Reshare" .-> M3

    classDef model fill:#e8e0ff,stroke:#4B0082,color:#000
    class M1,M2,M3 model

Each transition requires a State Backup/Restore + Key Reshare, not a key migration. Canton party ID and on-chain identity remain constant across all transitions. No asset movement required.

---

References