Teams comparing MPC wallet infrastructure need to know who can authorize a transaction, where each key share runs, how a failed signer is recovered, and which operating records the application receives. A feature checkmark does not answer those questions. This guide compares documented control models and gives teams a way to test them against a real payment flow.
For a wider view of custody providers, see the institutional crypto custody comparison.
What MPC Changes in Wallet Operations
Multi-party computation (MPC) can produce a valid blockchain signature without reconstructing a full private key in one place. The threshold, share holders, approval path, and recovery process still depend on the product and configuration. A vendor can offer multiple wallet models, so ask about the exact one in the proposed contract.
MPC is one part of the operating system. A product team also needs wallet creation, transaction policy, network support, lifecycle events, and a ledger that can be reconciled. A regulated custodian may be the better fit when the requirement is legal safekeeping of client assets rather than embedded wallet infrastructure.
What to Verify Before Choosing a Provider
- Signing control: Identify every share holder and the quorum for normal transactions.
- Policy enforcement: Test who can reject a payout and whether API access alone can initiate signing.
- Recovery: Ask what happens when the vendor, customer signer, or network is unavailable.
- Wallet operations: Test the exact assets, networks, deposit flow, and withdrawal path you need.
- Records and events: Reconcile a deposit, failed withdrawal, and retry against the operating ledger and event stream.
- Commercial scope: Compare the current plan limits, overage fees, support terms, and implementation work in writing.
MPC Wallet Infrastructure Options
BroSettlement
BroSettlement provides embedded wallets, DKG-generated 2-of-3 MPC signing, a customer-hosted Co-Signer, an append-only operating ledger, and WebSocket lifecycle events. Normal signing uses the platform share and the customer Co-Signer share. The separately held customer recovery share gives the customer a second quorum for recovery; the available recovery procedure and asset coverage must be checked for the selected network.
Its Free plan is testnet only. The Agent mainnet plan is listed at $30 per month with defined wallet and volume limits. Check the current plan page before quoting a price to a customer.
Fireblocks
Fireblocks offers several products with different key and wallet models, including Direct Custody and Embedded Wallets. Its documentation describes a customer-managed API Co-Signer for applicable configurations. Compare the proposed product and share topology rather than assigning one custody model to the entire Fireblocks platform.
Dfns and Utila
Dfns documents wallet APIs and a policy engine that governs signing. Utila documents wallet APIs, webhooks, and an automated Co-Signer. These are distinct products: evaluate their exact policy execution, key control, event coverage, and commercial terms separately.
Blockdaemon Institutional Vault
Blockdaemon documents a deployable Institutional Vault with MPC policy nodes, approvals, a transaction API, and network broadcast. Deployment responsibility and operational complexity should be tested against the team's own security and infrastructure capacity.
Compare the Control Model, Not Just Feature Names
| Platform | Publicly documented model | Question for the evaluation |
|---|---|---|
| BroSettlement | 2-of-3 DKG/MPC, customer-hosted Co-Signer, separate customer recovery share, ledger and WebSocket events | Which assets and recovery procedures are available for this deployment? |
| Fireblocks | Multiple wallet products; customer-managed API Co-Signer is documented for applicable configurations | Which product, key-share topology, policy path, and event service are included? |
| Dfns | Wallet API with signing governed by its policy engine | Where are approvals enforced and how are policy decisions exported? |
| Utila | Wallet API, webhooks, and automated Co-Signer | Who runs the signer and what can its rules reject before signing? |
| Blockdaemon Institutional Vault | Deployable MPC wallet and policy nodes with an API | Who operates the nodes, backups, approvals, and recovery process? |
Sources: BroSettlement API reference, Fireblocks API Co-Signer, Dfns policy engine, Utila API overview, and Blockdaemon deployment guide. Product availability and contract terms can change; verify the configuration offered to your organization.
BroSettlement Signing and Recovery Boundaries
Three Shares, Two Different Paths
| Share | Holder | Operational role |
|---|---|---|
| A | BroSettlement platform | Participates in normal A+B signing |
| B | Customer-hosted Co-Signer | Holds the customer share and evaluates the customer signing policy |
| C | Customer, stored separately from the active Co-Signer | Forms a B+C recovery quorum when the supported recovery procedure is used |
A single share is insufficient to sign. The normal A+B path and the B+C recovery path have different prerequisites and responsibilities. The public independent recovery tooling currently covers native TRX and standard TRC-20 transfers on TRON mainnet or Nile; it does not restore the BroSettlement API, ledger, or event service. Review the disaster recovery guide before treating recovery as an operational control.
Test One Transaction End to End
Start with a testnet wallet and a narrow API identity. Bring the customer Co-Signer online, complete MPC readiness, and create one ledger account and wallet. Fund it, observe the deposit event, and reconcile the ledger entry. Then test a small permitted withdrawal and a policy rejection. Check that an idempotent retry does not create a second logical transaction.
The API authenticates the request, but authentication is not spending approval. The Co-Signer and its rules remain part of the signing path. After signing, verify broadcast, confirmation, failure handling, and the final ledger state. The API reference documents the current endpoint surface; verify network and asset support in the current contract.
Which Option Fits?
Choose the provider whose documented control boundaries match your business obligations and integration capacity. BroSettlement is a candidate when an application needs embedded wallets, customer participation in signing, ledger reconciliation, and transaction events in one infrastructure layer. Fireblocks, Dfns, Utila, and Blockdaemon offer different mixes of wallet control, policy, custody, and deployment. A product-specific demonstration and written commercial terms are more useful than an unsupported universal ranking.
