Keys
This is the operator’s guide — how to run DKG, derive addresses, and handle refresh/recovery from the dashboard. For the cryptographic protocol detail (DKG rounds, threshold signing math, security guarantees), see Security → MPC Protocol.
A key in The Vault is a master cryptographic secret — split across multiple signers using MPC — from which all wallet addresses are derived.
Master Keys vs. Wallets
| Concept | What It Is |
|---|---|
| Master key | A set of key shares generated during a DKG ceremony — one share per signer, each generated locally by that signer. The full private key never exists in one place. |
| Wallet | An operational unit with blockchain addresses, policies, and transaction history — derived from a master key. |
One master key can back many wallets across multiple blockchains. Creating a new wallet does not require a new DKG ceremony — addresses are derived using HD derivation (BIP-32/BIP-44).
Key Share Layout
Each signer holds one key share under a configurable k-of-n threshold scheme (default 3-of-4):
| Signer | Share Storage | Always Online |
|---|---|---|
| Server Signer 1 | Kubernetes persistent volume (encrypted) | Yes |
| Server Signer 2 | Kubernetes persistent volume (encrypted) | Yes |
| Mobile Signer A | Encrypted at rest in app storage (key in OS secure storage) | No |
| Mobile Signer B | Encrypted at rest in app storage (key in OS secure storage) | No |
Server-Only Wallets
By default, a wallet includes mobile signers, and the platform always reserves at least one slot in every signing set for a mobile signer (servers fill at most threshold − 1 slots) — so a human must confirm signing on their device before any transaction can be signed. (This is separate from governance approvals, which a policy may also require beforehand — see Approval Flows.)
A server-only wallet is a deliberate exception: a wallet whose master key is created with no mobile devices — every signer is a server. It is not a separate wallet type or a toggle; a key is server-only precisely when zero mobile devices are selected during master key creation.
How Automatic Signing Works
A transfer from a server-only wallet still passes through the full policy
evaluation first — whitelists, limits, and approval quorums are applied exactly
as for any other wallet. The difference appears only once a transfer reaches
PENDING_SIGNATURE:
- For a normal wallet, signing does not begin until the mobile signer confirms it on their device.
- For a server-only wallet, a background auto-signer continuously picks up
transfers that are in
PENDING_SIGNATUREand submits them to the server signers automatically — typically within seconds, with no device confirmation.
The policy engine therefore remains the control point; what a server-only wallet
removes is only the mobile signer’s confirmation at signing time. Governance
approvals are unaffected — if the wallet’s policy requires approvals, those
human votes are still collected (in PENDING_APPROVAL) before signing, exactly as
for any other wallet.
A server-only wallet trades the human signing confirmation for automation. Because the servers can sign on their own, protect these wallets with strict policy rules — tight whitelists and low limits — and reserve them for funds and flows where that trade-off is acceptable. Choose server-only only when you explicitly want unattended signing.
Key Lifecycle
| Phase | What Happens | When |
|---|---|---|
| Generation | DKG ceremony — each signer generates its own key share; no full key is ever assembled | First-time setup |
| Derivation | Child keys and addresses derived from master key | New wallet or address |
| Signing | k-of-n shares cooperate to produce a signature | Every transaction |
| Refresh | All shares replaced — master key and addresses unchanged | Quarterly or after incident |
| Recovery | Lost share re-issued to a replacement device | Device lost or replaced |