Advanced MPC Threshold Security Module (TSM)

Institutional Vault uses Blockdaemon's Advanced MPC Threshold Security Module (TSM), a wallet security platform designed to combine robust private key protection with operational accessibility.

The off-chain nature of Multi-Party Computation (MPC) enables multi-party approval enforcement (which previously often required on-chain multisig) in a more flexible and chain-compatible way.

Key properties

• No single device holds the full private key: key material is distributed and never assembled on one machine.
• Scales to many wallets and transactions: designed for high throughput and multi-tenant usage.
• Confidentiality and efficiency: approvals and MPC signing are performed off-chain, avoiding extra on-chain signature overhead.

Institutional Vault Policy Engine

Institutional Vault’s policy engine is implemented inside the MPC Policy Authority (MPA): a cluster of 3 independent policy nodes that each evaluate policy before any operation is executed. This design delivers stronger guarantees than a traditional “policy service” because policy enforcement is cryptographically enforced and quorum-based, not merely an application-layer check.

%%{init: {
    "c4": { 
        "boundaryFontColor": "#000000",
        "boundaryFontSize": 20
    } 
} }%%
C4Container
    title PolicyProtect™ - MPC Policy Authority (MPA) Architecture
    
    %% Description of the system based on the image text
    %% "PolicyProtect™ introduces a second layer of MPC to cryptographically enforce and protect policies."

    System_Boundary(mpa, "MPC Policy Authority (MPA) - 3 of 3 MPC Signing Model") {
        
        %% Policy Node 1
        Container_Boundary(node1, "Policy Node #1") {
            Component(n1_policy, "Policy Engine 1", "MPC Protected Policy Layer", "Cryptographically enforced rules")
            Component(n1_key, "Key Share #1", "Partial key fragment")
        }

        %% Policy Node 2
        Container_Boundary(node2, "Policy Node #2") {
            Component(n2_policy, "Policy Engine 2", "MPC Protected Policy Layer", "Cryptographically enforced rules")
            Component(n2_key, "Key Share #2", "Partial key fragment")
        }

        %% Policy Node 3
        Container_Boundary(node3, "Policy Node #3") {
            Component(n3_policy, "Policy Engine 3", "MPC Protected Policy Layer", "Cryptographically enforced rules")
            Component(n3_key, "Key Share #3", "Partial key fragment")
        }
    }

    %% Style: ensure boundaries remain visible in light mode
    UpdateElementStyle(mpa, $fontColor="#111827", $borderColor="#6b7280")
    UpdateElementStyle(node1, $fontColor="#111827", $borderColor="#6b7280")
    UpdateElementStyle(node2, $fontColor="#111827", $borderColor="#6b7280")
    UpdateElementStyle(node3, $fontColor="#111827", $borderColor="#6b7280")

    UpdateElementStyle(n1_policy, $fontColor="#111827", $bgColor="#ddd6fe", $borderColor="#a78bfa")
    UpdateElementStyle(n2_policy, $fontColor="#111827", $bgColor="#ddd6fe", $borderColor="#a78bfa")
    UpdateElementStyle(n3_policy, $fontColor="#111827", $bgColor="#ddd6fe", $borderColor="#a78bfa")
    UpdateElementStyle(n1_key, $fontColor="#111827", $bgColor="#ddd6fe", $borderColor="#a78bfa")
    UpdateElementStyle(n2_key, $fontColor="#111827", $bgColor="#ddd6fe", $borderColor="#a78bfa")
    UpdateElementStyle(n3_key, $fontColor="#111827", $bgColor="#ddd6fe", $borderColor="#a78bfa")

    UpdateLayoutConfig($c4ShapeInRow="3", $c4BoundaryInRow="3")

Key properties

• Policies are enforced on every operation (not just signing): The same enforcement model applies to transfers/staking actions and administrative changes like user/group updates and policy set modifications.
• Threshold security for policy enforcement: An attacker must compromise all MPA nodes (or otherwise satisfy the policy-defined approval quorum) to push an operation through—compromising the orchestrator/database alone is insufficient.
• Defense against “policy hacks” with PolicyProtect™: Policies themselves are protected by an additional cryptographic layer (a second MPC protection layer), designed to prevent fraudulent policy updates from becoming effective unless they are accepted consistently across the policy authority.
• No blind signing: Approvals are collected and validated at the intent level, and the MPA only produces MPC transaction signatures after it verifies policy compliance and approval correctness.
• Works with human and programmatic approvers: Approvals can come from mobile/device-based signers and/or automated approvers (via an Approver SDK / approval API model) to integrate checks like sanctions screening, AML, or internal risk systems.
• Cryptographically verifiable system state: Core policy inputs (users, groups, policy sets, accounts, etc.) are signed by the MPA with a tracked “generation,” so policy nodes can detect stale/rolled-back policy data and refuse execution.

What the policy engine can do (capabilities)

• Evaluate policies independently on 3 nodes for every operation request.
• Bind approvals to intent details (so approvals can’t be replayed or reinterpreted for a different transaction).
• Require quorum approvals (including multi-role / multi-party approval patterns).
• Support conditional / operational controls (e.g., “checklists” / conditional rules as part of the approval process).
• Support external business-logic approvals produced outside the vault (programmatic approvers), while keeping final signing gated by the MPA.