Institutional Vault applies policy evaluation to every operation, not just transfers. This includes administrative actions such as adding or updating users and groups, updating policy sets, and other configuration changes—each action is evaluated and enforced by 3 independent policy nodes before it can take effect.

High-level transaction and approval flow

This is the high-level flow of submitting a transaction intent through Institutional Vault. Because approval signatures are decoupled from MPC transaction signatures, an arbitrary number of checkers—either programmatic Automated Approvers or human approvers—can be configured dynamically at runtime on a per-transaction basis.

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

    participant Client as Wallet Client
    box Institutional Vault
        participant MPA as MPC Policy Authority nodes<br>(3x MPA nodes)
    end
    participant BA1 as Automated Approver 1<br>(Sanctions Screening)
    participant BA2 as Automated Approver 2<br>(AML)
    actor Human as Human Approver 1<br/>(App / Device)

    Client->>MPA: submit transfer request
    activate MPA
    Note over MPA: Policy evaluation

    MPA->>BA1: request approval
    activate BA1
    BA1-->>MPA: approval signature
    deactivate BA1

    MPA->>BA2: request approval
    activate BA2
    BA2-->>MPA: approval signature
    deactivate BA2

    MPA->>Human: request approval
    activate Human
    Human-->>MPA: approval signature
    deactivate Human


    Note over MPA: MPC signing
    MPA-->>Client: tx signature
    deactivate MPA

End-to-end transaction flow

This is the flow of submitting a transaction intent through the Institutional Vault API, including policy evaluation, approvals, broadcasting, and status tracking. A transaction intent can either be a high-level construct specifying just the from/to addresses and assets, or the wallet client can supply the full unsigned transaction (nonce, gas/fees, call data, etc.). In either scenario, Institutional Vault decodes the intent and subjects it to policy evaluation.

sequenceDiagram
    participant Client as Wallet Client
    participant Wallet as Institutional Vault
    participant Blockchain as Blockchain Network

    Note over Client, Blockchain: 1. Transaction Intent Submission
    Client->>Wallet: POST /api/v2/transfers<br/>(High-level intent or full unsigned transaction)
    Wallet->>Wallet: Validate transfer request
    Wallet->>Wallet: Evaluate transfer policies
    alt Policy allows transfer
        Wallet-->>Client: 201 Created<br/>Transaction ID returned
    else Policy blocks transfer
        Wallet-->>Client: 403 Forbidden<br/>Policy violation
    end

    Note over Client, Blockchain: 2. Policy Evaluation & Approvals & MPC signing
    loop Until required approvals received
        Wallet->>Wallet: Collect approvals
        Wallet-->>Client: WebSocket: /api/v2/events/ws-receive<br/>Approval status updates
    end
    
    Wallet->>Wallet: Transaction approved
    Wallet->>Wallet: Threshold sign transaction

    Note over Client, Blockchain: 3. Broadcasting & Blockchain Submission
    Wallet->>+Blockchain: Broadcast signed transactions
    Blockchain-->>-Wallet: Transaction hash returned
    Wallet->>Wallet: Update transaction status with txHash
    Wallet->>Wallet: Emit transaction broadcast events
    Wallet-->>Client: WebSocket: /api/v2/events/ws-receive<br/>Transaction broadcast status

    Note over Client, Blockchain: 4. Status Monitoring & Confirmation
    loop Polling for final status
        Client->>Wallet: GET /api/v2/transactions/{transactionID}<br/>getTransaction()
        Wallet-->>Client: Transaction with status & txHash
        alt Transaction confirmed
            Wallet->>Wallet: Emit confirmation events
            Wallet-->>Client: WebSocket: /api/v2/events/ws-receive<br/>Transaction confirmed
        else Transaction still pending
            Note over Client: Continue polling
        end
    end

    Note over Client, Blockchain: 5. Final Status
    Client->>Wallet: GET /api/v2/transactions/{transactionID}<br/>getTransaction()
    Wallet-->>Client: Final transaction status<br/>- blockNumber<br/>- txHash<br/>- status: "confirmed"<br/>- fee

Detailed Approval flow (intent signatures → MPC transaction signatures)

This Institutional Vault implements a MPC‑based wallet and policy engine where approvals (intent‑level signatures) are cryptographically decoupled from MPC transaction signatures. Approvers hold their own ECDSA P‑256 keys and sign intents, while policy nodes hold sharded ECDSA/Ed25519 master keys and only sign validated transactions once policies are satisfied and approvals are verified against a signed system state.

sequenceDiagram
    autonumber
    participant User as Approver<br/>(Approval Key)
    box Institutional Vault
      participant Wallet as Wallet Service
      participant Policy as 3x Policy Nodes
      participant MPC as 3x MPC key shares
    end

    Wallet->>Wallet: StartOperation(intent)
    Wallet->>Wallet: Enrich intent and<br/>determine approvers
    loop For each approver
        Wallet->>User: Request approval<br/>(EnrichedIntent, MPASignature)
        User->>Wallet: Approve / reject intent<br/>(sign enriched intent)
        Wallet-->>Wallet: Store approval record<br/>(pubkey + signature)
    end
    Wallet->>Policy: ExecuteStep(intent,<br/>approvals)

    Policy->>Policy: Verify approvals against<br/>User table + ECDSA P‑256
    Policy->>Policy: Re‑evaluate policy using<br/>signed policies, users, groups
    alt Policy not satisfied
        Policy-->>Wallet: Error (missing / invalid approvals)
        note over Policy,Wallet: No MPC signatures produced
    else Policy satisfied
        Policy->>Policy: Build & validate unsigned tx<br/>(destinations, amounts, fees, chain, code auth)
        Policy->>MPC: Threshold sign transaction hash<br/>with sharded keys
        MPC-->>Policy: Transaction signature(s)
        Policy-->>Wallet: Signed transaction(s)
    end

Why this is cryptographically secure end‑to‑end

Decoupled key material

Approvals: Use per‑user or AutomatedApprover ECDSA P‑256 keys – for mobile approvers these are bound to OIDC identities at onboarding time, and for Automated Approvers they are provisioned by the wallet service. These users are stored in the signed User table. Transactions: Use MPC ECDSA/Ed25519 master keys, sharded across policy nodes and never reconstructed; approver key compromise does not expose wallet keys.

Signed and verified system state

Core tables (Users, UserGroups, PolicySets, NodeInfos, tokens, etc.) are updated only via policy nodes, which sign each new generation with an MPC Ed25519 system-key. Orchestrator cannot change policies or user/group membership without breaking these signatures; nodes verify them before using the data. These signatures allow core tables to be stored in an untrusted database or orchestrator while still being verifiable by every policy node before use.

Node‑side policy enforcement

Policy nodes treat orchestrator data (including approvals) as untrusted inputs and:

• Re‑verify every approval signature against the signed User table.
• Re‑evaluate policies using the signed policy and group configuration.
• Reject execution if any approval or confirmation is missing or invalid.

Intent‑to‑transaction binding

MPA Transaction validation ensures the unsigned transaction from the collector exactly matches the approved intent (destinations, amounts, fees, chain parameters, code authorizations, nonce accounts). MPC signatures are only produced over these validated transaction hashes, so a malicious orchestrator cannot trick the nodes into signing a different transaction than the one approved.