Key Concepts

This glossary defines the core terminology used throughout The Vault documentation.

Profile

A Profile is the top-level organisational entity in The Vault. It maps to a single institutional customer or deployment. All wallets, users, policies, and audit records belong to a profile. In a self-hosted deployment, a single Vault instance typically runs one profile, but multi-profile deployments are supported for service providers.

Wallet

A Wallet in The Vault is a logical container that groups one or more blockchain addresses under a common identity, policy set, and balance view. Wallets are derived from the MPC master key using HD derivation (BIP-32/BIP-44) — creating a new wallet does not require a new DKG ceremony.

A wallet is not chain-specific: a single wallet can hold Ethereum, Bitcoin, and TRON addresses simultaneously, each backed by the same threshold key.

Key Share

A Key Share is one fragment of a cryptographically split private key, generated during the DKG ceremony. Key shares are mathematically related but independently useless: fewer than the threshold number of shares reveals nothing about the underlying private key. The number of shares required to sign is the configured threshold k (default 3).

In the default 3-of-4 configuration, the four key shares are held by:

• Server Signer 1 (encrypted at rest, optionally TEE-protected)
• Server Signer 2 (same)
• Mobile Signer A (share encrypted at rest in the device’s secure storage)
• Mobile Signer B (same)

Coordinator

The MPC Coordinator orchestrates signing sessions. When a transaction is approved, the coordinator contacts the required signers, collects their partial signature contributions, and combines them into a single valid on-chain signature. The coordinator never holds a key share itself; it only sees partial signatures during the session window.

Signer

A Signer is any participant that holds a key share and can contribute a partial signature to a signing session. The Vault has two types:

• Server Signer — a backend service running in your infrastructure, always available, contributing automatically when a session is initiated.
• Mobile Signer — the iOS or Android app on an authorised signer’s device. When a signing session runs, the user confirms it on the device (Approve Signing + PIN) and the app then contributes its partial signature. A signer is distinct from a governance approver — see Approval Flows.

Policy

A Policy is a set of rules that governs what transactions are allowed for a given wallet. Policies are evaluated by the policy engine before any signing session is initiated. If a transaction fails policy evaluation, it is rejected without contacting the signers.

Policy rules include:

• Address whitelist — only allow transfers to pre-approved destination addresses
• Transaction limits — maximum amount per transaction
• Approval quorums — require N approvals from eligible users (a count, not a named list of individuals) before signing

Whitelist

An Address Whitelist is a policy rule that restricts outgoing transactions to a pre-approved set of destination addresses. Addresses are added to the whitelist through a governed process (requiring admin approval) and each entry can be labelled for audit purposes. Transactions to non-whitelisted addresses are blocked at the policy layer, before any signing occurs.

MFA (Multi-Factor Authentication)

Every login requires a second factor in addition to the password. By default this is a one-time code sent by email; a user can optionally enrol TOTP (an authenticator app) and use that instead.

For sensitive operations — such as policy changes, user and role changes, whitelist edits, and transfers — the dashboard session alone is not enough. These are stepped up to the paired mobile signer app, which cryptographically confirms the action; the dashboard shows a “confirm in mobile app” prompt and waits for the device’s signed approval. Step-up is a mobile-device confirmation, not a re-entered TOTP code. See Multi-Factor Authentication for details.

Device Binding

Device Binding ties a mobile signer’s key share to a specific physical device using an X.509 certificate. When a mobile signer enrolls, the device generates a certificate signing request (CSR) with a device-unique key pair. The Vault issues a certificate bound to that CSR. The key share is wrapped with the device certificate’s public key, meaning it can only be used on the original device.

If a device is lost or stolen, an administrator can block the device from the dashboard. The blocked device is immediately logged out and its local key share is wiped, so it can no longer participate in signing sessions.

DKG (Distributed Key Generation)

Distributed Key Generation is the cryptographic ceremony that creates the MPC master key. All signers (configurable k-of-n, default 3-of-4) participate simultaneously; each produces its key share locally without any party transmitting secret material. At the end of the ceremony, each signer holds exactly one key share and the master public key is known to all parties. Individual wallets are then derived from this master key without repeating the DKG ceremony.

mTLS (Mutual TLS)

All internal service-to-service communication in The Vault uses mutual TLS, where both the client and server present certificates and verify each other’s identity. This prevents any unauthenticated process — even inside the same network — from speaking to Vault services.

Audit Log

The Audit Log is an append-only, tamper-evident record of every significant action taken within The Vault: user logins, wallet creation, policy changes, transaction initiations, approval decisions, and signing events. Each entry is timestamped, attributed to an authenticated principal, and includes a cryptographic chain that allows detection of any post-hoc modification.

Client

A Client is an aggregate entity representing an organisation or individual on the platform. A client can be either INDIVIDUAL or CORPORATE. One client can have multiple profiles — for example, a company might maintain separate profiles for different operational needs or legal entities.

Customer

A Customer is a client of your client. In a B2B2B model, this could be a custodian whose client is a company like a fund or exchange. In a B2B2C model, the customer might be an end-user-facing company (e.g., a neobank) using your platform to offer crypto features to their users.

End-User

An End-User is the final consumer of the service. The platform does not interact with end-users directly — they are served by your customers. For example, in a B2B2C model: The Vault → provides custody to your customer → your customer provides crypto services to their end-users.

Service Provider

A Service Provider is the company operating the custody platform for its clients. The platform is designed to support a single service provider per deployment. The service provider manages client onboarding, platform configuration, and overall operations.

Platform Administrator

A Platform Administrator is an internal user of the platform — part of the team building or maintaining the deployment. Administrators create profiles for clients (including the initial owner user) and have access to manage all profiles and users across the platform.

Asset

An Asset is the currency in which a transaction or wallet operates. Each asset is linked to a specific node provider (adapter) defined in the platform’s configuration, which connects to the corresponding blockchain infrastructure. Examples include ETH, BTC, TRX, and tokens like ERC-20 or TRC-20.

Address

An Address is a blockchain address associated with an asset within a wallet. Each wallet can contain multiple assets, but each asset type is unique within that wallet — for example, only one BTC asset per wallet. If an additional asset of the same type is needed, a new wallet must be created.

Master Key

A Master Key is the root cryptographic key for a profile, created from shares during the MPC Distributed Key Generation ceremony. It is never assembled on any single device — it exists only as distributed shares across the participating signers.

Child Key

A Child Key is derived from the master key following BIP-32 and BIP-44 standards, using non-hardened derivation paths. Child keys are used to generate HD wallet addresses for specific blockchains. Because derivation is non-hardened, generating new addresses does not require participation from all MPC parties.

Relay

The Relay is a secure communication tunnel that enables real-time interaction between MPC nodes during signing and key generation ceremonies. The Relay functions solely as a router — it cannot see or decrypt the traffic passing through it (which is end-to-end encrypted via the Noise Protocol). The Coordinator orchestrates sessions, while the Relay handles the encrypted transport between signers.