MPC/TSS Wallet Operations Overview
BitGo wallets leverage either multisignature (multisig) or multi-party computation (MPC) technology. For MPC wallets, BitGo uses a threshold signature scheme (TSS). Both wallet types use a 2-of-3 key model with three keys: a user key, a backup key, and a BitGo key. Normal transactions are signed using the user key and the BitGo key. The backup key is reserved for disaster recovery or wallet recovery scenarios.
The fundamental difference is that with multisig wallets, each party holds a complete private key and produces an independent signature. With MPC/TSS wallets, each party holds a key share — an incomplete fragment that is useless on its own. Two key shares must cooperate in an interactive, multi-round cryptographic protocol to produce a single signature, without ever reconstructing the full private key.
What happens if one key share holder is unavailable?
Since MPC/TSS wallets use a 2-of-3 threshold, any two of the three key shares can cooperate to sign a transaction. If one key share holder is unavailable, the remaining two can still authorize transactions:
| Unavailable Party | Who Signs | Scenario |
|---|---|---|
| Backup key share | User + BitGo | Normal operations — this is the default signing path. The backup key is not used for day-to-day transactions. |
| BitGo key share | User + Backup | Disaster Recovery — if BitGo is unavailable, you can recover funds using the Wallet Recovery Wizard with your user and backup key shares. For more information, here is a folder on WRW |
| User key share | Backup + BitGo | Wallet Recovery — if you lose access to your user key share, contact BitGo support to discuss recovery options. Recovery workflows for TSS wallets using the backup and BitGo key shares may require additional coordination with BitGo, as the process differs from multisig wallet recovery. |
Key takeaway
Your backup key share is your lifeline. Store it securely and separately from your user key share. If both your user and backup key shares are lost, funds cannot be recovered. For self-managed wallets, always keep your backup key share in a secure, separate location and maintain documentation of who holds each key share.
Where are consolidation and transaction fees stored — MPC vs. Multisig?
Multisig wallets
Multisig wallets use a separate fee address (sometimes called a "gas tank") to pay transaction fees. This fee address is funded independently from the wallet's main balance.
- Consolidation fees: Paid from the gas tank (fee address)
- Withdrawal fees: Paid from the wallet's base address
- Benefit: Gas management is isolated — running low on gas doesn't affect your spendable balance
MPC/TSS wallets
MPC wallets pay fees directly from the main wallet address. There is no separate fee address.
- Consolidation/Flush fees: Paid from the wallet's base address, except for EVM chains (e.g., ETH, Polygon) and some other chains (e.g., SOL) that have a gas tank — in those cases, flush and consolidation fees are funded by the gas tank.
- Withdrawal fees: Paid from the wallet's base address. For EVM chains, withdrawal fees are paid from the gas tank (fee address).
- Important: Because fees come from the same pool as your spendable balance, withdrawing 100% of your balance can leave nothing to cover transaction fees, potentially causing transactions to get stuck
Note: It is good practice to always maintain a small reserve of the native token in your wallet to cover transaction fees. For most chains, MPC wallets do not use a separate gas address. However, on EVM chains, a gas tank is available and is used for flush/consolidation fees. Withdrawal fees on MPC wallets are always paid from the base address.
Do policy approvals work differently for MPC/TSS vs. multisig?
The policy framework itself — spending limits, whitelists, admin approvals, final approvers — works the same way regardless of wallet type. Both MPC and multisig wallets support the same set of policy rules and approval workflows.
The difference is in when signing happens relative to the approval process:
Multisig signing flow
- You build and half-sign the transaction locally
- Submit the half-signed transaction to BitGo
- Policies are evaluated
- If a pending approval is created, wallet admins approve
- BitGo co-signs and broadcasts
Multisig signing is asynchronous — each party signs independently with their complete key. The transaction can be partially signed, set aside, and completed later.
MPC/TSS signing flow
- A transaction intent is created (unsigned)
- Policies are evaluated
- If a pending approval is created, wallet admins approve
- After approval, signing occurs as a multi-round interactive protocol between your client and BitGo
- The signed transaction is broadcast
TSS signing is synchronous — it requires real-time cooperation between two key share holders over multiple rounds of message exchange. This means:
- Signing cannot happen in pieces. Both parties must be online and participating simultaneously during the signing ceremony.
- The transaction is rebuilt at signing time with the most current blockchain fees and nonce, which means you always get up-to-date fee estimates.
- If approval is required, signing happens after approval, not before. The approving admin can trigger a re-sign to get fresh on-chain data.
Practical implications
| Aspect | Multisig | MPC/TSS |
|---|---|---|
| Signing timing | Before or during approval | After approval |
| Co-signer coordination | Asynchronous | Synchronous (real-time) |
| Fee freshness | Fee set at build time | Fee set at sign time (fresher) |
| Fee bumping | Full admin control via API/UI | Must use BitGo Web UI or Change Fee API |
Note: If an MPC/TSS transaction gets stuck due to low gas, you can accelerate it through the BitGo Web UI ("Accelerate Transaction") or via the Change Fee API. Direct admin-level gas price commands are not available for MPC wallets because fee changes require threshold signing.
What are the limitations of TSS wallets vs. multisig for specific assets?
Blockchain compatibility
One of the major advantages of TSS is that it does not require native blockchain support. TSS signing produces a single standard signature that looks identical to a normal single-key transaction on-chain. This means:
- TSS works on any blockchain, including chains that don't support multisig natively (e.g., Solana, NEAR, Polkadot, Algorand, Sui)
- Multisig requires the blockchain to support it at the protocol level. On EVM chains, multisig uses a smart contract (WalletSimple) to enforce 2-of-3 signing on-chain.
Known limitations
| Limitation | Details |
|---|---|
| Cross-chain recovery | Cross chain recovery for some EVM-chains (e.g., Avalanche C-Chain, Celo, Ethereum Classic) is not possible. |
| On-chain visibility | TSS transactions appear as standard single-signature transactions on-chain. This provides better privacy and lower fees, but it also means you cannot determine which key shares were used to sign a transaction from on-chain data alone. |
| Cold signing complexity | Cold MPC wallets require multiple round-trips between the BitGo platform and the Offline Vault Console (OVC) during signing. This is more complex than multisig cold signing, which requires only a single sign-and-submit step. |
| Transaction fees | TSS transactions are cheaper on-chain since only one signature is verified, compared to multisig which requires verifying multiple signatures. However, the interactive signing process adds latency. |
How does key share rotation work?
Key share rotation is the concept of generating new key shares without changing the underlying public key or wallet address. After rotation, old key shares become invalid — an attacker who compromised an old key share cannot use it.
When rotation applies
- Protocol upgrades: When BitGo migrates MPC implementation to a more secure protocol, BitGo will coordinate with you to perform a key migration.
- Personnel changes: If an employee who held a key share leaves the organization, contact your BitGo account team to discuss key rotation options.
- Security incidents: If you suspect a key share may have been compromised, contact BitGo support immediately.
Current state
Key share rotation is performed in coordination with BitGo and is not a self-service operation. The process requires all key share holders and their signing devices to be present, and involves multiple rounds of cryptographic ceremony between the parties.
For MPCv2 migration specifically
The process involves using the Offline Vault Console (OVC) on two devices alongside the BitGo platform, with multiple rounds of file transfer between them. Your wallet address remains unchanged — no need to move funds.
Note: New wallets should always use ECDSA MPCv2 for EVM/Cosmos chains or EdDSA for EdDSA-based chains.
Quick Reference: MPC/TSS vs. Multisig
| Feature | Multisig | MPC/TSS |
|---|---|---|
| Key structure | 3 complete independent keys | 3 interdependent key shares |
| Signing | Asynchronous, independent | Synchronous, multi-round |
| On-chain footprint | Multiple signatures, smart contract | Single signature, standard EOA |
| Fee source | Separate fee address | Main wallet address (gas tank used for EVM flush/consolidation) |
| Blockchain support required | Yes | No |
| Transaction cost | Higher (multiple sig verification) | Lower (single sig verification) |
| Privacy | Multisig visible on-chain | Indistinguishable from single-sig |
| Cold signing complexity | Simple (sign and submit) | Multi-round OVC ceremony |
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article