Transaction and approval flows

For AI agents: visit https://vault.docs.blockdaemon.com/llms.txt for an index of all pages formatted in Markdown and endpoints in OpenAPI.

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. Automated Approvers are customer-configurable hooks: each runs your own conditional or business logic over the transaction (intent) data and returns an approval or rejection.

Institutional Vault
Automated Approver 2(customer hook: custom logic)
Automated Approver 1(customer hook: custom logic)
MPC Policy Authority nodes(3x MPA nodes)
Wallet Client
Automated Approver 2(customer hook: custom logic)
Automated Approver 1(customer hook: custom logic)
MPC Policy Authority nodes(3x MPA nodes)
Wallet Client
Policy evaluation
MPC signing
Human Approver 1(App / Device)
submit transfer request
1. request approval
2. approval signature
3. request approval
4. approval signature
5. request approval
6. approval signature
7. tx signature
8. Human Approver 1(App / Device)

End-to-end transaction flow

This is the programmatic flow for starting a transaction through the Vault API, including policy evaluation, confirmations, approvals, MPC signing, broadcasting, and operation status tracking. The client calls POST /api/cwp/operations/start/makeTransaction; Institutional Vault enriches the intent, evaluates policy, signs, and broadcasts to the network.

Blockchain Network
Institutional Vault
Wallet Client
Blockchain Network
Institutional Vault
Wallet Client
1. Start operation
2. Policy, confirmations, and approvals
   opt[Confirmation or approval required]
   loop[Until operation leaves pending states]
3. MPC signing and broadcast
   alt[Policy blocks operation]
   [Policy satisfied]
4. Final status
   POST /api/cwp/operations/start/makeTransaction
   Enrich intent and evaluate policy
   Operation ID returned
   GET /api/cwp/operations/id/operationID/status
   Operation Status
   Collect initiator confirmation and approver signatures
   Status Failed or blocked
   policy violation
   Threshold-sign transaction
   Broadcast signed transaction
   Transaction hash
   Status Succeeded
   tx hash in Result.Transaction.ID
   GET /api/cwp/operations/id/operationID/status
   Succeeded or Failed
   with Result or Error

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.

Institutional Vault
3x MPC key shares
3x Policy Nodes
Wallet Service
Approver(Approval Key)
3x MPC key shares
3x Policy Nodes
Wallet Service
Approver(Approval Key)
loop[For each approver]
   No MPC signatures produced
   alt[Policy not satisfied]
   [Policy satisfied]
   Start Operation(intent)
   1. Enrich intent and determine approvers
   2. Request approval(Enriched Intent, MPA Signature)
   3. Approve / reject intent(sign enriched intent)
   4. Store approval record(pubkey + signature)
   5. Execute Step(intent, approvals)
   6. Verify approvals against User table + ECDSA P‑256
   7. Re‑evaluate policy using signed policies, users, groups
   8. Error (missing / invalid approvals)
   9. Build & validate unsigned tx(destinations, amounts, fees, chain, code auth)
   10. Threshold sign transaction hash with sharded keys
   11. Transaction signature(s)
   12. Signed transaction(s)

Why this is cryptographically secure end‑to‑end

Decoupled key material

Approvals: Use per‑user or Automated Approver 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:

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.