Managing Client Shares for MPC Wallets (Wallet SDK)

When you create a wallet with the Tatum Wallet SDK, you are not generating a single mnemonic or private key. Instead, the SDK uses Portal's enclave based MPC architecture to produce two cryptographic shares per curve: a client share and a Tatum share. Both shares are required to produce a valid signature, and neither one alone can move funds. This page explains what each party is responsible for and what happens if a share is lost.

The two shares

A wallet created with the SDK never exists as a single secret. Instead, there are two shares per curve, and both are required to produce a valid signature:

If the client share is lost, the Tatum share alone is mathematically insufficient to sign a transaction or recover funds. This is by design and applies to every Wallet SDK integration, custodial or non-custodial.

Step 1: Tatum and Portal do not store your client share

The client share returned by generateWallet() exists only in that single API response. Tatum's infrastructure, including the Portal powered enclave used for signing, processes the share in memory and never persists, logs, or transmits it elsewhere. If you do not capture and store it at generation time, it cannot be retrieved afterward by Tatum, by Portal, or by anyone else.

Step 2: Confidentiality of shares

Treat the client share with the same level of care you would give a private key. Encrypt it at rest, scope storage and access per end user, and never log it in plaintext, crash reports, or analytics events.

Step 3: Never share a client share, backup share, or ejected key

This includes friends, other team members outside of the relevant system, and Tatum or Portal staff. No legitimate request for these values is ever legitimate.

Step 4: Backup shares are your recovery path, not an optional extra

Call backupWallet() after wallet generation and store the resulting encrypted backup share somewhere separate from the primary client share, ideally a different storage system with different access controls. This is the closest equivalent to cold storage for these wallets.

• If the original client share is lost but a backup share was stored, recovery is possible.
• If both the client share and the backup share are lost, the wallet is not recoverable, including by Tatum.

Step 5: Eject is the user's exit hatch, not a recovery service

enableEject() lets a user reconstruct a full private key from their shares within a defined window (ejectableUntil). This exists so users are never locked into Tatum's infrastructure, but it still depends on the user holding a valid client share or backup share at the time of ejection. Eject cannot help once both shares are already gone.

Step 6: Periodic checks

Periodically confirm updateSigningSharePairs() has been completed for each wallet and that backup share storage is intact and reachable. A share that technically exists but cannot be retrieved at signing time is operationally the same as a lost share.

Discharge of Responsibility

Tatum's enclave, built on Portal's confidential computing infrastructure, never stores, logs, or has visibility into your client share or backup share. Securing, backing up, and retaining access to these shares is solely your responsibility as the integrating customer, and by extension your end users' responsibility wherever you pass that obligation downstream.

No legitimate Tatum or Portal staff member will ever ask for a client share, backup share, or ejected private key. Any such request should be treated as a scam attempt.

🚧

Attention

The responsibility for keeping client shares and backup shares secure and recoverable rests solely with you, the integrating customer.

❗️

Warning

If a client share is lost with no corresponding backup share, Tatum and Portal cannot recover the wallet. The 2-of-2 model means one share alone, including Tatum's own share, is never enough to sign or reconstruct a key. Tatum cannot help you.