MPC & Key Management
Your keys. Always yours. Never whole.
White Rabbit's MPC system is the foundation of how we handle cryptographic keys — and it's built around a simple but powerful idea: a private key that never fully exists in one place cannot be stolen from one place. No single server, no single breach, no single point of failure can compromise your assets.
The problem with traditional key storage
Most crypto infrastructure stores private keys as a single secret — in a file, a database, or a hardware device. That works until it doesn't. A leaked secret, a rogue employee, a compromised server, or even a routine backup in the wrong hands can mean total and irreversible loss.
White Rabbit eliminates that risk entirely.
How White Rabbit MPC works
When you generate a key with GENERATE_KEY_SHARE, no private key is ever created. Instead, our nodes perform a distributed ceremony where each node independently computes a mathematical fragment — a share — of what would be a private key. These shares are mathematically linked, but individually useless.
To sign a transaction, a minimum number of shares must cooperate. No single node can act alone. No single share reveals anything about the others.
Node 1 holds Node 2 holds Node 3 holds
[ Share A ] [ Share B ] [ Share C ]
│ │ │
└────────────────────┴────────────────────┘
│
Signing ceremony
│
✓ Valid signature
← The private key never exists anywhere →
This is called threshold cryptography — and it's the same class of technology trusted by the world's largest financial institutions and digital asset custodians.
Our node network
The MPC network is made up of nodes operated by completely separate, independent companies — and here is the critical part: you choose which ones you trust.
For example:
| Node | Operated by |
|---|---|
| Node A | Company A |
| Node B | Company B |
| Node C | White Rabbit |
Each company independently deploys and operates their own node. Your key shares are distributed across the nodes you select — so if you choose Node A, Node B, and Node C, your key is split across three organizations with no relationship to each other. Think of it like the Bitcoin network, where independent operators around the world each run their own node: no single company controls the network, and that independence is precisely what makes it trustworthy.
Even White Rabbit cannot act alone. If White Rabbit's node is one of your chosen providers, we hold only one share — never enough to sign anything without the others cooperating.
Each node:
- Is deployed and operated by a separate, independent organization
- Holds only its own encrypted share — it cannot see or access others
- Communicates with peers through an encrypted, authenticated messaging layer
- Stores its share in an isolated, encrypted database — separate from every other node
- Requires independent authentication before participating in any ceremony
No node trusts another blindly. Every message exchanged during a ceremony is cryptographically authenticated, and every share is verified against mathematical proofs before being accepted. A compromised node cannot forge a signature, inject a false share, or learn anything about the key from what it receives.
You decide which organizations hold your key shares. Even if one provider — including White Rabbit — is compromised, shut down, or pressured, the remaining providers hold only fragments. No single organization holds enough to act alone.
┌─────────────────────────────────────────┐
│ Encrypted Communication Layer │
└──────────┬──────────────┬───────────────┘
│ │
┌────────▼───┐ ┌─────▼──────┐
│ Node 1 │ │ Node 2 │
│ [Share A] │ │ [Share B] │
│ Encrypted │ │ Encrypted │
│ Storage │ │ Storage │
└────────────┘ └────────────┘
│ │
└──────┬───────┘
┌─────▼──────┐
│ Node 3 │
│ [Share C] │
│ Encrypted │
│ Storage │
└────────────┘
How your key is stored
Each node stores only its own encrypted share. The encryption is strong enough that even if a node's storage were fully compromised, the attacker would gain nothing useful — shares are individually meaningless without the others, and each share is encrypted with a secret that never touches the database.
There is no "master key" anywhere in our system. There is no recovery backdoor. There is no way for White Rabbit staff to access your key material.
The keyId returned by GENERATE_KEY_SHARE is the only way to reference your key. If you lose it, there is no recovery. Not for you, not for us. Store it in your database the moment you receive it — treat it like the key to a vault that cannot be re-keyed.
How signing works
When your workflow calls SIGN_WITH_KEY_SHARE, our nodes run a signing ceremony:
- The minimum required number of nodes are invited to participate
- Each node independently prepares its contribution to the signature — without seeing the others
- These contributions are combined mathematically to produce a complete, valid signature
- The private key is never assembled at any point — not even temporarily
The result is a standard ECDSA or EdDSA signature, indistinguishable from one produced by a traditional key — compatible with every blockchain, every wallet, every smart contract.
Unlimited addresses from a single key
One generated key can back an unlimited number of blockchain addresses. White Rabbit implements the industry-standard BIP-44 hierarchical derivation scheme, meaning you can derive a unique address for every user, every account, or every purpose — all from a single keyId.
Your keyId (one key, stored once)
│
├──▶ m/44'/60'/0'/0/0 → Ethereum address #0
├──▶ m/44'/60'/0'/0/1 → Ethereum address #1
├──▶ m/44'/501'/0'/0' → Solana address #0
├──▶ m/44'/0'/0'/0/0 → Bitcoin address #0
└──▶ ... unlimited
This means you can operate wallets for thousands — or millions — of end users from a single MPC key, without generating new key material for each one.
Backup & portability
Your key shares are not locked to the nodes you started with. You can export any share at any time, store it anywhere you control, and import it into any node you choose — with no dependency on White Rabbit and no permission required.
Take your shares offline
At any point you can request a copy of your key share from a node, encrypted with your own encryption key. The result is a self-contained encrypted file you can store on your own server, your own device, a cold storage drive, or anywhere else you trust. If every node in the world went offline tomorrow, your encrypted shares would still be yours.
MPC Node Your storage
──────── ────────────
Share (encrypted by node)
│
▼
Re-encrypt with YOUR key ──────▶ Store locally — fully offline
(your server, device, cold storage)
│
▼
✓ No node dependency
Move between nodes freely
You are never locked to a specific node or provider. If you want to migrate a share to a different company's node — because you found a provider you trust more, because you are changing regions, or simply because your security policy changed — you can do so at any time:
Old Node (Company A) New Node (Company B)
──────────────────── ────────────────────
Export share
encrypted for Company B ───────▶ Import + store locally
│
▼
✓ Migration complete
(original key unchanged)
The underlying key never changes. Your keyId stays the same. Your blockchain addresses stay the same. Only the node holding that particular share changes — completely transparent to the rest of your workflow.
Change your node setup anytime
Your threshold policy is not fixed forever. As your business grows or your security requirements evolve, you can:
- Add a new node — export the share to an additional provider for extra redundancy
- Remove a node — retire a provider by deleting their share (after migrating it elsewhere)
- Switch providers entirely — export all shares, import to new providers, done
- Store a cold backup — keep one encrypted share completely offline as a last resort
This gives you the same flexibility as managing your own infrastructure — without having to build or maintain any of it.
Generated your key on our OFFICIAL_1 node? You can move that share to a completely independent third-party node tomorrow. White Rabbit does not need to be involved. Your keys travel with you.
Supported curves
White Rabbit MPC supports every major cryptographic curve used in production blockchain infrastructure today:
| Curve | Use case |
|---|---|
SECP256k1 | Ethereum, Polygon, Arbitrum, Base, BNB Chain, Avalanche, Bitcoin (ECDSA) |
ED25519 | Solana, Aptos, Near, Sui, and other EdDSA chains |
P256 | WebAuthn, Apple Secure Enclave, passkey-based wallets |
P384 | High-security enterprise and government applications |
P521 | Maximum NIST security level |
ED448 | Ultra-high-security EdDSA (stronger than Ed25519) |
SECP256K1_SCHNORR | Bitcoin Taproot (P2TR) |
The curve is selected at generation time. For multi-chain products, generate one key per curve — each keyId can still derive unlimited addresses on its respective chain.
Security at a glance
| What you get | How |
|---|---|
| No single point of failure | Private key never assembled — threshold required for every operation |
| Breach-resistant storage | Each share encrypted independently; database compromise reveals nothing |
| Tamper-proof ceremonies | Every participant verified cryptographically before contributing |
| Safe key transfers | Export always re-encrypts for the recipient; plaintext never leaves a node |
| No backdoors | White Rabbit has no mechanism to access, recover, or reconstruct your key |
| Full portability | Export shares to your own storage, import to any node, switch providers freely |
| No vendor lock-in | Your keyId and addresses never change when you migrate between nodes |
| Blockchain-standard output | Signatures are standard ECDSA/EdDSA — no special chain support required |
| Unlimited scale | BIP-44 derivation enables millions of addresses from a single key |
Categories
| Group | Components | Page |
|---|---|---|
| Key Generation | GENERATE_KEY_SHARE | Key Generation → |
| Signing | COMPUTE_PUBLIC_KEY, SIGN_WITH_KEY_SHARE | Signing → |
| Key Management | IMPORT_KEY_SHARE, EXPORT_KEY_SHARE, REWRAPPING_KEY_SHARE, RECOVER_PRIVATE_KEY | Key Management → |
| Utilities | GENERATE_AGE_ENCRYPTION, GET_NODE_RECIPIENT_KEY | Utilities → |
Full MPC signing workflow
GENERATE_KEY_SHARE (curve: SECP256k1, threshold: 2)
│ keyId ← store this permanently
▼
GET_EVM_DERIVATION_PATH (addressIndex: 0)
│ derivationPath
▼
COMPUTE_PUBLIC_KEY (keyId, derivationPath)
│ publicKey
▼
COMPUTE_EVM_ADDRESS (publicKey)
│ address
▼
BUILD_EVM_TRANSACTION (from: address, ...)
│ serializedHash │ unsignedTransaction
▼ │
SIGN_WITH_KEY_SHARE │
│ signature │
▼ │
SIGN_EVM_TRANSACTION ──────────┘
│ signedTransaction
▼
BROADCAST_EVM_TRANSACTION