The customer requests a wallet transfer and the transfer approval policy is fulfilled, using the same quorum machinery as local recovery.
All recovery shares including the customer shares are posted and available to the TEE, along with the address list (public keys, derivation paths, chain codes) for the wallets to transfer.
The TEE reconstructs the backup encryption key, recovers the backup private key, and recovers the backup contents, entirely inside the enclave.
The TEE reconstitutes wallet private keys and derives individual key material: for HD wallets, Lagrange interpolation to a root key, then derivation by chaincode and path.
The TEE re packages keys in the destination provider’s format, splitting with Shamir secret sharing and encrypting shares to provider and customer public keys.
Encrypted destination materials go to the failover wallet over a secure API; the customer downloads their client share, authenticates at the new provider, and sees the reconstituted wallet.
A group of wallet providers that accept encrypted backups from other MPC providers while maintaining the same MPC security posture.
The same customer controlled quorum that governs local recovery governs a provider transfer.
Recomposition and re packaging happen inside the enclave. On termination, all intermediate key material is destroyed.
Per provider logic that re splits and re encrypts keys to match the destination wallet’s share format.
Delivers the destination specific ciphertexts to the failover provider; the customer share goes only to the customer.
Reconstructing private keys in a non hardened environment is the biggest risk in a crisis recovery. This flow keeps recomposition inside a TEE with no durable storage and no general network access.
Customers pressed for time in a disaster make mistakes. The transfer uses the same approval flow they already know from recovery drills.
The destination provider receives only material in its own share format, encrypted to its keys. It never sees the source provider’s format or surplus key material.
Common reasons to invoke: provider outage during a trading window, or a suspected breach where routing transactions through the compromised provider is unacceptable.
Walk through the trust model, policy design, and rollout with our security and solutions team.