Key Management Lifecycle

The Institutional Vault ensures that a complete private key never exists at any point in its lifecycle. The following sections describe the data flow for key generation, encrypted storage, and threshold signing.

Key Generation

Private keys are generated through a distributed key generation (DKG) protocol coordinated by the Wallet Service orchestrator. Each MPA Node independently contributes cryptographically secure randomness, and the MPC protocol produces a key share per node along with a shared public key. The complete private key is never assembled, computed, or transmitted.

MPA Node 2    MPA Node 1    MPA Node 0
Broker      Wallet Service (Orchestrator)  API Client
MPA Node 2    MPA Node 1    MPA Node 0
Broker      Wallet Service (Orchestrator)  API Client
Each node contributes  local CSPRNG randomness
DKG completes: each node holds a key share
complete key never exists
CreateMasterKey request
Distribute DKG session
DKG round
DKG round
DKG round
MPC protocol messages
MPC protocol messages
MPC protocol messages
Encrypt share (AES-256-GCM) and persist to local DB
Encrypt share (AES-256-GCM) and persist to local DB
Encrypt share (AES-256-GCM) and persist to local DB
Public key + success
MasterKey created (public key)

Key Storage

Each policy node's key share is encrypted at rest using AES-256-GCM with a per-node Master Encryption Key (MEK) derived via HKDF. Encrypted shares are persisted to that node's isolated PostgreSQL database. Shares are protected at rest (cloud KMS / Key Vault), in transit (TLS and mTLS between nodes), and in use inside a hardware-attested Trusted Execution Environment (TEE) on AWS Nitro Enclaves or Azure Confidential Containers.

For Nitro and Azure Confidential Container isolation, KMS attestation, hardware-bound storage, and how MPC combines with TEE versus physical HSMs, see MPC and TEE Security Architecture.

TEE Protection

Isolated Databases

MPA Node 2

MPA Node 1

MPA Node 0

Protected by

Protected by

Protected by

MEK 0

HKDF

AES-256-GCM Encrypt

Key Share 0 (in-memory only)

Encrypted Share 0

MEK 1

HKDF

AES-256-GCM Encrypt

Key Share 1 (in-memory only)

Encrypted Share 1

MEK 2

HKDF

AES-256-GCM Encrypt

Key Share 2 (in-memory only)

Encrypted Share 2

MPA Node 0 PostgreSQL

MPA Node 1 PostgreSQL

MPA Node 2 PostgreSQL

AWS Nitro Enclave / Azure Confidential Containers

KMS Remote Attestation

Key Usage (Signing)

When a transaction intent is submitted, it passes through policy evaluation and approval before the Wallet Service initiates a threshold MPC signing ceremony. Each MPA Node decrypts its share in memory, validates the transaction against the approved intent, and participates in the multi-party signing protocol. The partial signatures are combined into a single standard ECDSA or EdDSA signature. The complete private key is never reconstructed during signing.

MPA Node 2    MPA Node 1    MPA Node 0
Broker      Wallet Service (Orchestrator)
MPA Node 2    MPA Node 1    MPA Node 0
Broker      Wallet Service (Orchestrator)
Transaction approval quorum completed
Pre-sign validation: outputs, fees, spec, code authorizations must match intent
Threshold signing completes: single ECDSA/EdDSA signature
key never reconstructed
Initiate signing ceremony
Sign request
Sign request
Sign request
Decrypt share with MEK from local DB
Decrypt share with MEK from local DB
Decrypt share with MEK from local DB
MPC signing protocol
MPC signing protocol
MPC signing protocol
Combined signature