Multi party computation is a cryptographic way to avoid the most dangerous wallet assumption: one complete private key sitting in one place. For crypto infrastructure, MPC lets multiple participants jointly create a signature without reconstructing the key. The chain receives a normal signature, but operational control is split across participants, policy and Co-Signer boundaries.
For institutions, the point is not academic cryptography. The point is operational: who holds shares, who can approve signing, what happens when a participant fails, how resharing works, and how finance proves that a requested transaction became the broadcast result.
Зміст
- Single key problem, який MPC має вирішити
- Що насправді означає Multi Party Computation
- Distributed Key Generation і threshold signing під капотом
- MPC versus custodial HSMs and multisig
- Як production MPC stack wired together
- Risks and controls, які визначають чи MPC витримає
- Як правильно вибрати і deploy MPC
Single key problem, який MPC має вирішити
Traditional wallet security often starts with a complete private key. If that key is copied, leaked, extracted or misused, funds can move. Hardware, HSMs and cold storage reduce exposure, but they do not fully solve the operating question for high-frequency systems: how can a team automate transactions without creating one irresistible secret?
MPC replaces that single-secret model with distributed signing. No participant holds the complete key. Each holds a share, and a valid signature is produced only when enough approved participants cooperate.
Before buying MPC, ask:
- How are shares created and backed up?
- Where does each share live?
- Who can approve resharing or decommissioning?
- What happens when a Co-Signer goes offline?
- Can an administrator compel enough participants to sign?
- How does finance reconcile the requested transaction with the broadcast result?
These are operating questions, not only security questions.
Що насправді означає Multi Party Computation
Multi party computation allows parties to compute a result together while keeping their private inputs hidden. In wallet infrastructure, the result is usually a valid transaction signature. The private input is each participant's key share.
MPC does not mean "nobody controls anything." It means control is distributed and should be governed by policy. If all participants sit under one admin account, same cloud region and same emergency process, the cryptography is stronger than the operation around it.
Wallet mental model
- Share ownership: independent trust domains hold separate key shares.
- Transaction proposal: application submits transaction and policy context.
- Participant validation: Co-Signers verify transaction, authorization and local conditions.
- Joint signing: participants exchange protocol messages and contribute partial signing values.
- Signature output: network receives standard signature, not visible collection of approvals.
This is why MPC works well for embedded wallet infrastructure. The user-facing product can stay simple, while the signing authority remains split behind the scenes.
Distributed Key Generation і threshold signing під капотом
Distributed Key Generation, or DKG, creates shares without ever assembling the full private key in one place. Participants jointly establish a wallet signing setup. Later, threshold signing lets a subset, such as 2-of-3 or 3-of-5, create a valid signature.
Signing round у production
- Application submits transaction with idempotency key and scoped authorization context.
- Coordinator selects eligible participant set.
- Each participant validates transaction and contributes protocol messages.
- Participants verify commitments and partial results.
- Protocol combines contributions into valid ECDSA, EdDSA or Schnorr signature.
- Broadcaster submits signed transaction, while operating ledger records request and outcome.
| Parameter | 2-of-3 | 3-of-5 |
|---|---|---|
| Required participants | Two eligible Co-Signers | Three eligible Co-Signers |
| Availability profile | One participant can be offline | Two participants can be offline |
| Collusion concern | Smaller colluding set reaches quorum | Larger colluding set required |
| Coordination | Fewer protocol participants | More protocol coordination |
| Failure handling | Easy to understand, participant diversity matters | More resilient if failure domains are truly independent |
| Reconfiguration | Tightly controlled because group is smaller | More placement options, more lifecycle state |
The threshold is a business/security decision. 2-of-3 may fit fast operations with one client-controlled Co-Signer. 3-of-5 may fit higher-risk treasury controls, but it adds coordination and governance overhead.
MPC versus custodial HSMs and multisig
| Dimension | MPC | Custodial HSM | On-Chain Multisig |
|---|---|---|---|
| Authority model | Distributed across protocol participants | Concentrated with custodian/operator | Distributed across on-chain signers |
| Address behavior | Usually one logical address per signing setup | One key or custodian-controlled structure | Depends on chain multisig model |
| Signing path | Off-chain protocol rounds | Local hardware operation | Multiple signatures/approvals on-chain |
| Latency profile | Network round trips and coordination | Hardware signing can be very fast | Waits for signing actions and broadcasts |
| Operational burden | Share lifecycle, quorum health, resharing, events | Custodian due diligence and dependency | Chain-specific tooling and signer management |
| Recovery | Controlled share replacement/resharing | Custodian recovery procedure | Signer replacement or wallet migration |
| Chain coverage | Signature-scheme dependent | Depends on custodian integrations | Chain-specific |
MPC is not automatically better in every case. It is strongest when a team needs automation, policy, auditability and chain-agnostic signing without one reconstructable key.
Як production MPC stack wired together
An MPC protocol is not enough. Production requires an operating layer around the protocol: API authentication, policy, event delivery, ledger records, monitoring and incident response.
Operating layer навколо protocol
- Scoped API keys: limit each integration to wallets, assets, actions and environments it needs.
- WebSocket events: push deposit observations, confirmations, withdrawal status, quorum changes, share refresh events and policy outcomes.
- Append-only ledger: record wallet creation, DKG completion, signing requests, approvals, broadcasts, failures, resharing and decommissioning.
- Idempotency: require stable idempotency key for every transaction intent.
- Health checks: test Co-Signer availability continuously.
- mTLS termination: enforce authenticated node-to-node communication without hiding participant identity from audit.
BroSettlement's MPC wallet infrastructure uses this kind of operating model: customer-hosted Co-Signer, scoped API access, WebSocket events and ledger records around wallet operations.
Risks and controls, які визначають чи MPC витримає
MPC can fail operationally even when the cryptography is sound. The common failures are poor share placement, weak admin separation, unclear recovery, missing event visibility and no rehearsed incident path.
Controls, які survive real incidents
- Proactive resharing: governed refresh when participant membership or infrastructure boundaries change.
- Independent failure domains: place Co-Signers across separate providers, regions, accounts or teams where threat model requires it.
- Hardware-backed storage: keep shares in protected vaults and restrict export paths.
- Dual control: separate people and credentials for policy changes, participant enrollment, resharing and decommissioning.
- Tamper-evident records: reconstruct requested transaction, policy result, participant responses, broadcast result and reconciliation state.
- Abort handling: define what happens when participant sends invalid message, times out or becomes unreachable.
The risk is not just theft. It is also unavailable signing, unprovable approvals, duplicate withdrawals, broken reconciliation and emergency recovery that has never been tested.
Як правильно вибрати і deploy MPC
Procurement should evaluate protocol, operating model and evidence. A provider saying "we use MPC" is not enough. The team needs to understand how the control boundary works in normal flow and in failure.
Five questions for procurement
- Which protocol fits the threat model? Compare GG20, GG21, FROST and Lindell17 by signature scheme, abort handling, malicious participant assumptions, key refresh and reconfiguration.
- Who controls the Co-Signer? Determine whether your team runs Co-Signer inside its own VPC and controls credentials, network boundary and procedures.
- What does the ledger preserve? Require append-only records for DKG, signing, resharing, decommissioning, policy decisions and broadcast outcomes.
- Which events are available? Test WebSocket/webhook coverage for quorum formation, participant failures, share refresh, deposit confirmation, withdrawal state and policy outcomes.
- How do compliance workflows connect? Check KYC, AML screening, approvals, RBAC, audit exports and case management.
FAQ for serious buyers
Is MPC the same as multisig? No. MPC produces a standard signature through off-chain protocol participants. Multisig usually exposes multiple signers or approval transactions on-chain, depending on the network.
Does MPC remove custody risk? No. It changes the control model. Teams still need policy, share governance, recovery, monitoring, contracts and audit evidence.
Can an AI agent use an MPC wallet? Yes, but the agent should submit structured transaction intents through scoped API access. It should not receive private keys, seed phrases or MPC shares in prompt context.
What is the role of a Co-Signer? The Co-Signer validates policy and participates in signing only when local conditions are satisfied. For client-controlled infrastructure, it is the practical boundary between provider service and customer authority.
What should be tested before production? DKG readiness, participant outage, duplicate transaction retries, policy rejection, resharing, WebSocket delivery, ledger reconciliation and emergency pause.
MPC is powerful when it is paired with operating discipline. BroLabel combines embedded MPC wallets, client-controlled Co-Signer workflows, scoped API access, WebSocket events and ledger records so teams can build wallet infrastructure without placing complete private keys in one place.