That claim is too shallow. MPC solves key management, but the decision is who can approve, delay, or block fund movement when a co-signer, a vendor, and a client policy all sit in the signing path.
The market is still early. Analysts at Ainvest cite one forecast that values the global MPC wallet market at $70.8 million in 2025 and projects $137 million by 2031, which implies an 8.2% CAGR; the same forecast says the white-label MPC wallet segment is growing faster at 11.3% CAGR Ainvest forecast summary. Another estimate places the broader development market at $61.4 million in 2024, rising to $120 million by 2031 at 8.1% CAGR Ainvest forecast summary. That is not saturation, it is early commercialization.
Table of Contents
- Hidden Control Is the Real Threat
- How Threshold Signing Works
- The Client-Controlled Co-Signer Model
- Signing Policies and Operational Controls
- MPC Wallets Compared to Custodial and Multisig Alternatives
- Real-World Integration Scenarios
- Risks and Controls Before You Sign Anything
- Procurement Checklist and Buyer FAQ
Hidden Control Is the Real Threat
Institutional teams often discover that a wallet labeled non-custodial still routes signing through a vendor-controlled co-signer, opaque policy rules, or a recovery path that gives one party real blocking power. That is a governance failure dressed up as security.
A thief can only steal what the operating model gives away. In an MPC wallet, the cryptography matters, but the operating question matters more, who holds shares, who enforces policy, who can recover, and who can veto. If your vendor can change signing behavior without clear disclosure, custody has been moved behind the curtain.
The enemy is hidden control.
CTOs should stop asking whether an MPC product is “secure” in the abstract. Ask whether it changes the failure model from single-key compromise to quorum compromise, or whether it only relocates custody into a vendor policy engine. That distinction decides whether you are reducing risk or just repackaging it.
Operational control is the point. If the approval path is unclear, the wallet is already weak, no matter how clean the cryptography looks on the sales page.
How Threshold Signing Works
Threshold signing distributes private-key shares across multiple parties so no single node ever holds the complete key. The system only produces a valid signature when the required quorum cooperates.
DKG creates the shares from the start
The setup phase uses Distributed Key Generation (DKG). The parties generate the wallet together, rather than creating one private key first and then splitting it afterward. Independent technical guides explain that this changes the failure model because no one ever handles a full secret, only threshold shares Stackup technical guide.
A practical 2-of-3 setup works like this. One share sits with the client-controlled co-signer, one sits on the vendor node, and one sits in a backup tier or device-controlled recovery path. Any two can sign, so one lost device or one compromised service does not automatically expose funds.
Practical rule: if the full key can be reassembled anywhere, you do not have threshold custody, you have key storage with extra steps.
Signing is a protocol, not a magic trick
When a transaction is signed, each share participates in a multi-round cryptographic protocol. Public technical comparisons list older GG18 (2018) schemes at 9 signing rounds, GG20 (2020) at 6 to 7 rounds, CGGMP21 (2021) at 4 rounds, and Fireblocks' proprietary MPC-CMP (2020) at 1 round with preprocessing Fireblocks technical report. Fewer rounds usually mean less latency and less coordination overhead for treasury, exchange, or iGaming flows.
That performance profile matters operationally. In the same analysis, an ECDSA MPC wallet uses about 68 virtual bytes per input, while P2SH 2-of-3 multisig is about 296 vB Fireblocks technical report. On high-volume systems, that smaller footprint is a real advantage because the chain sees a normal-looking signature instead of a heavier on-chain multisig structure.
BroLabel's explanation of why MPC wallets are replacing seed phrases gives a useful product-level view of the operational tradeoff, but the core point stays the same, threshold signing removes single-key exposure and shifts control into the share-and-policy model Why MPC wallets are replacing seed phrases.
Threshold signing spreads signing authority across multiple shares, keeps the full key from ever being assembled, and reduces the operational bottleneck of older multisig flows. The architect version is simpler still, fewer exposed secrets, smaller blast radius, and a signing path that can be tuned for latency.
The Client-Controlled Co-Signer Model
A client-controlled co-signer gives your organization one share in the threshold and the ability to enforce signing policy at the node level. The client, or a dedicated custody provider chosen by the client, operates that node as part of the signing path. It is not a magical trustless layer, and it is not a third-party custodian by default. It is a governance node that carries one share and participates in policy-gated signing.
Who holds what matters more than the label
In a typical institutional setup, the vendor operates one share, the client operates one share, and a third share sits in a recovery tier or another controlled environment. A 2-of-3 policy then governs how transactions move, and the power sits in share custody and policy enforcement, not in the marketing term attached to the wallet.
That is the part procurement teams miss. If the vendor can sign with its own share plus a policy exception, the wallet may still behave like custody, even if the brochure says “non-custodial.” Independent security writing has also pointed out that many products marketed as MPC are threshold-signature systems rather than full general-purpose MPC Zellic primer. Buyers need to ask which construction is deployed.
A clean role assignment looks like this:
- Client co-signer: approves within policy, logs decisions, and keeps one threshold share.
- Vendor node: participates in signing, but only under defined rules.
- Backup share tier: supports recovery or continuity if one node is offline.
The share map is the contract. The algorithm only makes it possible.
Why policy files matter
A co-signer model only works if the policy lives where signing happens. If a central application can override node-level rules, the app becomes the control point and the threshold structure turns into theater. That is the load-bearing issue for finance, compliance, and operations teams.
If you are evaluating this model, map it to your org chart, not your vendor demo. Ask who can approve, who can block, and who can recover. If those answers are not crisp, the co-signer is just another place where custody hides.
Signing Policies and Operational Controls
Signing policy is where cryptography becomes an operating control. Without policy, threshold signing only proves that multiple shares can cooperate. With policy, it starts to look like a treasury system that can survive real-world abuse, mistakes, and compliance review.
What the controls should actually enforce
Strong wallets usually enforce per-transaction limits, address allowlists, time locks, role-based approval, and step-up authentication for higher-risk actions. Those controls shouldn't live only in the front-end app, because a front-end can be bypassed. They need to be evaluated at the signing node before a share is released.
Vendor-default policy and client-defined policy are not the same thing. Client-defined policy gives your team change control, audit evidence, and predictable escalation. Vendor-default policy gives the vendor the power to rewrite how your money moves.
The operational difference is blunt:
| Control layer | Client-defined policy | Vendor-default policy |
|---|---|---|
| Rule changes | Your team controls them | Vendor controls them |
| Auditability | Clear internal evidence trail | Depends on vendor logs |
| Response speed | Internal escalation path | Vendor support queue |
| Failure mode | Your policy may be too strict | Vendor can become the real gatekeeper |
Why node-level enforcement wins
If the policy only exists in the application, a compromised application can ask for a signature it shouldn't get. If the policy is evaluated at each signing node, the node itself refuses to contribute a share. That's the difference between a cosmetic control and a real control.
MPC wallets are stronger than single-key custodial wallets because they shrink single-point key compromise. They're often cheaper and less exposed on-chain than multisig, but the control plane still decides whether the system is safe. A weak policy on top of strong threshold signing still produces a weak wallet.
MPC Wallets Compared to Custodial and Multisig Alternatives
Choose the architecture by failure mode, not by brand familiarity. A single-key custodial wallet concentrates control in one account layer, on-chain multisig exposes the signer set on-chain, and MPC keeps the signature format standard while splitting signing authority across shares.
| Dimension | MPC Wallet | Custodial Wallet | On-Chain Multisig |
|---|---|---|---|
| Blast radius | Lower than single-key custody if shares are separated | Highest, one key or one account layer is decisive | Lower key risk, but signer roles are visible on-chain |
| Fee cost | Lower than on-chain multisig in ECDSA flows, because the signature looks standard | Usually low at signing time | Higher because the chain carries multisig logic |
| Recovery | Depends on share design and policy | Depends on custodian process | Depends on contract design and signer replacement process |
| Regulatory framing | Can still be custodial in practice if one party controls signing | Clearly custodial | More transparent, but not always operationally simple |
| Integration effort | Moderate, because policy and share custody need design | Low to medium | Medium to high, especially across chains |
The strongest technical case for MPC is the smaller on-chain footprint. Industry technical comparisons note that 68 virtual bytes per input for ECDSA MPC is materially lighter than roughly 296 vB for legacy P2SH 2-of-3 multisig Fireblocks technical report. That matters when your business pushes lots of transfers, sweeps, or payouts.
The limitation is just as clear. MPC does not fix chain coverage, vendor uptime, or governance ambiguity. If your provider holds the only workable recovery path, your so-called non-custodial wallet can still behave like a hosted wallet when it matters most.
A serious buyer should test five things before integration:
- Confirm the threshold construction. Ask whether it is true threshold signing, plain multisig, or a hybrid.
- Audit share custody. Know where each share lives and who can move it.
- Review policy defaults. Do not accept vendor-default approval rules blindly.
- Stress-test sandbox signing. Measure latency and failure behavior under load.
- Verify event streams. Make sure deposits, confirmations, and withdrawals are observable.
If you are comparing vendors, start with best crypto custody solutions for MPC and wallet operations and check how each provider handles signing authority, policy control, and recovery before you commit.
If the vendor cannot walk you through those checks without hand-waving, keep looking.
Real-World Integration Scenarios
An exchange operations lead usually wants one thing, less hot-key exposure. A 2-of-3 model with a client-controlled co-signer lets the exchange keep one share under its own policy, while the vendor node and a recovery tier cover continuity. That reduces the chance that a single compromised machine becomes the drain point for the whole treasury.
A fintech product manager has a different problem. They need embedded wallets per user, buy and sell flow, and card spend without ever holding customer funds in one central key. DKG, quorum signing, scoped API keys, and WebSocket events let the platform create wallets, observe deposits, and trigger downstream actions without building a custom custody stack from scratch.
An iGaming treasury owner cares about payout speed and clean accounting. Per-player deposit addresses, an append-only ledger, and event-driven reconciliation keep deposits visible before any payout signing happens. In that workflow, the wallet is only one piece, because the operating ledger and the event feed decide whether finance trusts the balance enough to release funds.
BroLabel is one option in this category, its stack combines BROsettlement with DKG/MPC 2-of-3 signing, a client-controlled co-signer, an immutable operating ledger, WebSocket event streams, and embedded wallets for user, agent, or player models. That kind of stack matters when the team needs wallet operations, reconciliation, and policy in one API rather than stitched across separate vendors.
The common thread across all three scenarios is control. A good MPC system doesn't just sign, it gives operations teams a defined approval path, a ledger they can reconcile, and event visibility that finance can use.
Risks and Controls Before You Sign Anything
The first failure mode is share loss below threshold. If too many shares disappear, signing stops, so the control is geographic and provider separation, plus explicit recovery procedures that work before an incident, not after one.
The second failure mode is vendor lock-in around proprietary share formats. If you can't move your shares or migrate the wallet without a vendor ticket, you don't own the control surface. The control is exportable or interoperable key-share handling, documented upfront.
The third failure mode is policy bypass via out-of-band approvals. If support staff, operators, or a hidden admin console can override the signing policy, the policy isn't real. The control is node-level enforcement, strict role separation, and a signed approval workflow that can be audited later.
The fourth failure mode is regulatory ambiguity around who has control. U.S. regulatory writing has broadened the idea of control to include the power to unilaterally execute or indefinitely block transactions, which means the legal question is who can approve, delay, or veto transfers in practice BitGo compliance discussion. That's not a cryptography issue, it's an operating model issue.
Don't sign a custody contract until the control path, recovery path, and audit path are all written down.
Procurement Checklist and Buyer FAQ
Use this as the last gate before vendor selection.
- Confirm the threshold design. Ask whether the wallet uses true threshold signing, and what quorum rules apply.
- Verify share custody and exportability. Know where each share lives and whether migration is possible.
- Review default signing policy. Check limits, allowlists, time locks, and who can change them.
- Test sandbox latency. Measure signing behavior before production traffic hits it.
- Confirm event coverage. Deposits, confirmations, withdrawals, and policy outcomes should all stream cleanly.
FAQ
What changes operationally versus multisig? MPC hides the multi-party structure off-chain, so you get a standard-looking signature with lower on-chain footprint, while multisig exposes signer logic on-chain.
Can an MPC wallet still be custodial in practice? Yes. If the vendor can sign, block, or recover without your real control, the wallet is functionally custodial even if the marketing says otherwise.
How do I evaluate a vendor's co-signer architecture? Ask who operates each node, who can change policy, how shares are separated, and what happens if one node goes offline.
BroLabel publishes embedded wallet infrastructure, including MPC-based signing, client-controlled co-signer flows, WebSocket events, and ledger support for teams that need control before volume is predictable. If you're evaluating MPC wallet architecture for exchange, fintech, or treasury operations, visit BroLabel and compare the controls against your own signing policy, recovery plan, and audit requirements.