Executive Summary

Banks, fintechs, payment providers, and trading firms need to protect digital assets while coordinating which people and systems can move funds. Multi-party computation (MPC) distributes cryptographic signing authority across multiple parties, allowing them to produce valid transaction signatures without assembling the complete private key during signing. Combined with transaction policies and tested recovery arrangements, this architecture supports institutional payments, treasury management, trading settlement, tokenization, and staking across supported blockchains.

This guide explains how secure multiparty computation works, how MPC signing differs from custody arrangements and on-chain multisig, and which controls institutions should evaluate when selecting and implementing MPC wallets. It covers key generation, approval workflows, multi-chain stablecoin operations, API integration, and recovery, while distinguishing private-key protection from transaction confidentiality and MPC’s broader applications in privacy-preserving analytics. We also show how our institutional wallet infrastructure combines MPC, granular transaction policies, and programmable workflows to help your organization retain control over digital assets and govern their use.

What Is Secure Multiparty Computation?

Multi party computation allows multiple parties to jointly compute a function over their private inputs while protecting those inputs according to the protocol’s security model. Each participant contributes their own data, and the computation reveals the agreed output rather than exposing the underlying data to everyone involved.

The parties involved might be separate companies, financial institutions, or independently controlled computing systems. Their inputs could include sensitive data such as account records, financial exposures, or private key shares.

The key advantage comes from reducing reliance on a trusted central party that would otherwise collect and process everyone’s information. Participants can obtain a useful result without routinely sharing each other’s data.

MPC explained through a bank-account example

Alice, Bob, and Carol want to calculate their average bank account balance while keeping their individual balances private. An appropriately designed MPC protocol lets them contribute private inputs and receive the average.

The output still needs careful consideration: two parties who combine their own balances with the average can infer the third person’s balance. Protecting the computation does not prevent information being inferred from its result.

Foundational computer science researchin 1987 established general secure-computation results for efficiently computable multiparty functions under specified cryptographic and adversary assumptions. This supports a broad range of practical applications, although a feasible computation can still carry substantial communication and processing costs.

In crypto wallets, the function being computed is typically a digital signature. The private inputs are shares of the signing key.

How Secure Multi Party Computation Works

An institutional MPC wallet has three important cryptographic stages: generating key shares, signing transactions, and refreshing shares.

Generate Distributed Key Shares

Secret sharing represents a secret through multiple shares distributed in such a way that an insufficient subset cannot recover or use the secret as the protocol permits.

With distributed key generation, participating parties jointly establish their shares and the corresponding public key. A properly designed implementation can do this without first creating a complete private key on one machine and subsequently dividing it. Dealerless key generation is an established capability of threshold-signature protocols.

The private key exists mathematically, but each participating system holds its designated share. Those shares require independent protection: distributing them across different machines offers limited benefit when the same compromised administrator can access every machine.

Sign Without Reconstructing the Key

When an authorized transaction reaches the signing stage, the required signing endpoints exchange protocol messages and jointly produce a signature.

In an illustrative two-of-three threshold arrangement, two signing participants can cooperate, while one party alone cannot produce an authorized signature under the protocol’s assumptions. The blockchain verifies the resulting signature using the relevant standard verification algorithm.

A signing threshold describes cryptographic participation. An approval quorum describes organizational authorization. A payment might require approval from finance and compliance before automated signing systems participate in the MPC protocol.

Approval quorum and signing threshold

Define these separately during implementation. “Two people approved the payment” and “two signing endpoints participated” describe different controls. Your architecture should preserve the intended relationship between business authorization and cryptographic execution.

Refresh Shares While Preserving Addresses

Protocols with proactive security can refresh key shares while preserving the underlying signing key. Because the corresponding public key remains unchanged, this can preserve the wallet address.

Refresh procedures help manage exposure over time, provided the implementation follows its security assumptions, including appropriate handling of obsolete shares and backups. Replacing the underlying private key is a different operation and can require address migration.

For operators, this distinction matters when personnel leave, devices are replaced, or signing infrastructure changes.

Evaluate Protocols and Signing Performance

Different multi party protocols make different choices about communication rounds, preprocessing, cryptographic assumptions, and resilience.

These characteristics come from the respective protocol papers; a protocol name alone does not establish the security or performance of a commercial implementation.

Some MPC designs use homomorphic encryption, which permits operations on encrypted values. The Paillier encryption scheme appears in several threshold-ECDSA constructions. Fully homomorphic encryption supports a broader class of computations on encrypted data and is a distinct technology that can be combined with other privacy techniques.

For payments and trading, benchmark the complete workflow with required controls enabled. Include authorization, network communication, signing, broadcasting, and confirmation. Fast cryptographic computation addresses only part of transaction latency.

Build Institutional Controls Around MPC

An institutional deployment should connect transaction requests to business authorization, distributed signing, and operational records.

Our API architecture organizes activity into vaults and wallets. Vaults provide an organizational environment for shared policies and key material; wallets group addresses around an entity or purpose. APIs support wallet creation, transfers, balance monitoring, and transaction automation.

Private key controls should cover who can initiate a request, approve it, operate a signer, change a policy, enroll a device, and execute recovery.

Apply Granular Transaction Policies

A useful policy configuration expresses the business purpose of a transaction.

The following examples illustrate controls to define during implementation; they are not recommended universal thresholds.

Our treasury management capabilities include role-based policies, transaction limits, and multi-step approvals. Our tokenization infrastructure also supports contract-call controls involving functions, parameters, and conditions.

Utila feature: Govern administrative changes

Our security model requires an administrator quorum to define and manage transaction policies. Transaction initiation and signing use separately controlled paths, supporting separation of duties. New CLI signing devices also require administrator approval before they can be used.

Configure these controls so that a person requesting a payment cannot independently weaken the rules governing its release.

Separation of duties reduces opportunities for unilateral misuse and raises the difficulty of insider collusion. Review the actual permissions and combinations of people or systems that could bypass the intended process.

Separate Signing Architecture From Custody

MPC describes how a cryptographic operation is performed. Custody describes who controls assets and under what operational and legal arrangements.

Custodial wallets can use MPC internally. A self custody wallet can also use MPC, with customer-controlled participation and recovery arrangements. Evaluating direct ownership therefore requires examining who can authorize transactions, who controls recovery material, and what happens when a service provider becomes unavailable. Threshold-signature research explicitly supports arrangements involving customers, financial institutions, and additional trustees.

MPC threshold signatures can be verified through conventional signature-verification mechanisms. Smart-account multisig can instead express ownership thresholds and additional execution controls in contracts.

Migration requirements depend on the implementation. Some multisig arrangements require a new address when their underlying configuration changes; smart accounts such as Safe support adding, removing, and replacing owners within the existing account. Avoid assuming that every multisig change requires moving assets.

The practical comparison with traditional wallets should therefore cover both signing architecture and operational control.

Evaluate Multi-Chain Stablecoin Wallets

MPC can protect signing authority across digital assets on different blockchains. Multi-chain support comes from implementing the required networks, signing algorithms, transaction formats, and asset integrations.

For example, our wallet API distinguishes ECDSA and EdDSA keys and selects the appropriate key for supported networks. This lets institutions manage different blockchain environments through a common operational interface.

An institution evaluating a stablecoin wallet should verify each required asset-network combination. Supporting a blockchain does not automatically establish support for every stablecoin, contract interaction, or transaction workflow on that chain.

Our article on multi-chain stablecoin infrastructure examines the operational implications of managing stablecoins across different networks and settlement routes.

Assess the Best Stablecoin Wallets

The best stablecoin wallets for an institution depend on its operating requirements. Assess how well the wallet supports the payment systems, approval processes, and accounting records your organization already uses.

For institutional operations, evaluate the depth of these capabilities against actual workflows. A wallet offers more value when its security features, automation, and records fit the way your organization receives and releases funds.

Utila feature: Operate stablecoins across supported networks

Our stablecoin infrastructure combines programmable approvals, batch payouts, deposit workflows, and gas-management capabilities across supported EVM and non-EVM environments. Dedicated gas wallets and sponsored transactions can simplify fee funding for operational wallets. Network fees still need to be paid and accounted for.

Apply MPC to Institutional Workflows

MPC provides distributed signing authority. Its operational value depends on how that authority connects to the transaction being performed.

Treasury and Cross-Border Payments

Treasury teams can use dedicated wallets to separate reserves, operating liquidity, and customer-related flows. Approval requirements should reflect each wallet’s purpose and exposure.

Use case: Cross-border payroll and vendor payments

An illustrative workflow for a global enterprise begins with an approved payment file. The system validates recipients and supported assets, applies transaction policies, and requests the required approvals. Signing systems then authorize the transfers.

Finance reconciles the resulting wallet activity against payroll or invoice records, including conversion costs and transaction fees.

Our payments infrastructure supports workflows involving deposit attribution, automated sweeps, batch payouts, and policy-controlled transfers.

Stablecoin payments can also support payment providers and payment processors serving merchants or funding downstream settlement. Everyday spending may happen through mobile apps or card interfaces, while the provider manages liquidity, conversion, and settlement behind that user interface.

Design these as distinct processes. A customer-facing payment authorization, a stablecoin transfer, and settlement into a bank account may have different counterparties and completion criteria.

Trading and DeFi Operations

Trading teams need to transfer funds between wallets, exchanges, and decentralized applications while retaining control over destinations and contract permissions.

Use case: Controlled trading settlement

A trading desk can propose settlement to an approved venue while a separate authorization process checks the destination, asset, and amount. Higher-risk contract interactions can follow a different approval path.

Our trading operations infrastructure combines wallet, exchange, and DeFi workflows with governance controls and APIs for execution and settlement.

MPC protects the signing inputs used in these workflows. Confidential trading or DeFi execution additionally depends on the network and application handling transaction data.

Tokenization and Contract Administration

Token issuers must govern permissions that can affect an entire asset supply, including minting, burning, and contract administration.

Use case: Govern token issuance

Separate routine token transfers from privileged contract actions. Require designated approval for issuance or administrative calls, and restrict the permitted functions and parameters.

Our tokenization infrastructure supports MPC-protected operations and granular contract-call policies, helping institutions apply distinct authorization requirements to different tokenization activities.

The same review should cover contract permissions already granted on chain, because those permissions may continue to matter independently of future wallet-signing decisions.

Institutional Staking

Staking creates additional transactions and permissions that need institutional oversight.

Use case: Authorize institutional staking

An institution can govern staking transactions through distributed signing and designated approvals, keeping signing authority separated across participating systems.

Through our Dawn Labs collaboration, clients can delegate SOL to Dawn Labs’ validator within our MPC-secured operating environment. Validator selection, protocol rules, and liquidity requirements remain separate evaluation areas.

Efficient MPC protocols can reduce the signing component of a staking workflow. They do not determine the blockchain’s confirmation times or the staking protocol’s withdrawal conditions.

Understand MPC’s Privacy Boundaries

MPC supports both distributed signing and privacy-preserving computation. These applications protect different information.

In wallet signing, MPC protects key shares during the computation. In collaborative analytics, MPC can protect records contributed by different parties. The transaction or analytical result may still disclose information that requires additional controls.

Protect Transaction Data Appropriately

Our MPC infrastructure protects signing keys. Transaction confidentiality depends on the supported blockchain, token, and application.

For institutions that require confidential asset operations, our blockchain privacy guide for banks explains how capabilities associated with Aleo, Canton, and Zama relate to transaction visibility and authorized access. The appropriate design depends on what information must remain private and who must be able to inspect it.

This distinction matters when assessing claims that MPC enhances trading infrastructure by preventing data leaks. Specify whether the claim concerns key material, order information, customer records, or on-chain transaction details.

Support Privacy-Preserving Financial Analytics

MPC can support secure computation across multiple sources without requiring the parties to exchange their entire datasets. Potential applications include risk calculations, fraud detection, privacy-preserving data mining, and joint machine learning.

For example, institutions can compute an agreed statistic or aggregate model updates while keeping raw records under their own control. Research systems such as Conclave and MPC-enabled federated-learning designs explore these approaches and their performance tradeoffs. (arXiv)

Private set intersection is another useful application: parties determine which entries overlap across their datasets without disclosing the full datasets. In a financial-services setting, that can support carefully scoped matching exercises as part of a broader collaborative analysis.

In anti-money-laundering work, combining information held by multiple banks can improve the visibility of suspicious transaction networks. The BIS’s Project Aurora explored collaborative analytics and privacy-enhancing technologies, and its 2025 work sought further evidence about real-world applications. These initiatives should be distinguished from claims that a particular MPC system has been deployed throughout banking.

Reducing raw-data exposure can support privacy and compliance objectives. Institutions still need to establish permitted purposes, access rules, retention requirements, and the legal basis for the proposed collaboration.

Control What Outputs Reveal

The only information intentionally released by a secure computation may be its result, yet that result can still expose sensitive facts. Small groups, repeated queries, or auxiliary information can make individual records inferable.

Differential privacy addresses this output problem by limiting what can be inferred about individual contributions. It can complement MPC or fully homomorphic encryption, which protect information during computation. Selecting the function, permitted queries, recipients, and privacy parameters therefore belongs in the system design.

Test the Complete Security Model

A major challenge in an MPC deployment involves preserving independence across the participating systems.

Security claims commonly describe tolerance for up to t adversarial parties out of n total parties. The permitted threshold and guarantees depend on the protocol and adversary model. Privacy, resistance to forged signatures, and continued availability are separate properties.

Research on robust threshold ECDSA highlights that some protocols can be interrupted by a misbehaving or unavailable signing participant. A protocol can protect key secrecy while still requiring operational measures to restore service.

Review external and internal compromise paths across signing devices, identity systems, administrator accounts, automation permissions, backups, and recovery processes. Shared control over these components can undermine the intended separation.

Protect Shares in Their Deployment Environment

Depending on the implementation, shares may be protected using hardware-isolated trusted execution environments, hardened signing services, encrypted storage, or combinations of these controls. Hardware isolation should be evaluated as a specific implementation property.

For our customer-operated CLI, the state contains sensitive material including device keys and wallet key shares. It can be stored locally or in supported cloud storage, with encryption options including AWS KMS and Google Cloud KMS. Our documentation recommends KMS-backed encryption for production state.

Security review checkpoint

Verify where each share exists at rest, during computation, in backups, and during recovery. Ask which identities can access those environments and which failures affect multiple signers at once.

Encrypted storage and hardware-isolated execution address different parts of that review.

Integrate APIs and Validate Recovery

Begin with a narrowly defined transaction workflow and expand after validating its controls.

Define authorization first. Identify the source wallets, permitted assets, destinations, limits, approvers, signing participants, and recovery owners. Specify how exceptions are handled.

Test complete transaction lifecycles. Use test environments where supported. Include rejected requests, duplicate submissions, unavailable approvers, signing failures, and delayed confirmations.

Verify event handling. Our webhook documentation describes signed event payloads and retry behavior. Validate signatures, handle repeated notifications safely, and reconcile important state through the API rather than relying solely on event delivery.

Review production readiness. Obtain relevant cryptographic and implementation audit material, assess the proposed configuration, and validate applicable onboarding and transaction-screening requirements. Include restoration and incident-response exercises before committing material balances.

Utila feature: Control automated signing

Our co-signer supports a signing-decision webhook that lets your system decide whether to sign or cancel an eligible transaction. If that endpoint fails or times out, the transaction remains pending.

The documented co-signer flow handles eligible API-created transactions; console-created transfers are not sent to the co-signer. Account permissions and initiation/signing responsibilities should be configured deliberately.

Plan for Continued Asset Access

Document responses to a lost device, unavailable signer, suspected compromise, personnel change, and provider outage. Define which recovery materials are required, who controls them, and how the organization validates a restored environment.

Choose share-refresh procedures around the protocol’s requirements and your threat model. Avoid assigning an arbitrary rotation cadence without considering how shares, device enrollment, backups, and recovery interact.

Our business continuity capabilities support compatible wallet and operational configurations, including supported key-import and address-preservation scenarios. Compatibility depends on factors such as key types and derivation paths. Test the proposed continuity arrangement with the actual wallets and workflows it must support.

Evaluate Providers Through Real Workflows

When assessing Utila alongside Fireblocks, BitGo, Dfns, or other providers, ask each team to demonstrate the same operating scenario.

Use a stablecoin payout or treasury transfer that includes policy approval, signing, screening, broadcasting, reconciliation, and recovery. Request evidence for the deployed protocol, supported assets, security boundaries, and failure behavior.

Where cryptographic policy enforcement is a requirement, ask how administrator-approved rule versions are authenticated and checked by the signing path. Verify whether administrators digitally sign policy changes and how those changes become effective. A signed audit record alone does not demonstrate that a signing system enforces the approved rules.

For regulated activities, define the responsibilities of your organization and each service provider. Our Licensed Partner Network connects institutions with partners for relevant regulated activities and jurisdictions, while we provide wallet infrastructure, policies, APIs, and supporting operational tooling. Partner coverage must match the proposed service.

Explore our wallet infrastructure to evaluate how MPC signing, operational policies, and APIs fit your institutional transaction workflows.

Key Takeaways

• MPC protects signing authority. Key shares participate in a cryptographic computation without being combined into a complete key during normal signing.

• Institutional control requires several layers. Cryptographic signing thresholds, transaction approvals, and administrator permissions serve different purposes.

• Multi-chain operations require supported integrations. Confirm the assets, transaction types, and operational features available on each network.

• Recovery belongs in the initial design. Test how your organization maintains access when devices, personnel, or infrastructure become unavailable.

Frequently Asked Questions

Who Holds the Private Key?

In a distributed MPC arrangement, participating systems hold key shares. During normal threshold signing, those shares produce a signature without reconstructing the complete key. The allocation of shares and authority depends on the wallet’s implementation and configuration.

Can MPC Wallets Use Cold Storage?

Yes, suitable threshold-signing designs can support cold-wallet architectures. “MPC” describes distributed cryptographic participation; “hot” and “cold” concern connectivity and operational handling. A reserve wallet with strict approvals should not automatically be described as cold storage.

Does an MPC Wallet Need a Seed Phrase?

MPC does not inherently require users to manage a conventional seed phrase. Recovery can use other arrangements involving protected shares, devices, or recovery material. Evaluate the specific recovery design and its dependencies rather than assuming that removing a seed phrase removes recovery risk.

Can a Signature Prove Ownership?

A valid signature demonstrates the relevant signing authority under the cryptographic scheme. Establishing legal ownership requires additional context and records. Zero knowledge proofs can demonstrate that a statement holds without revealing the secret information used to establish it, but they serve a different purpose from determining legal title.

Does MPC Make a Wallet Compliant?

MPC can strengthen key management and reduce sensitive-data exposure. Regulatory obligations depend on the activity, jurisdiction, custody arrangements, and parties involved. Institutions must assess those obligations separately and implement the required operational processes.

What Happens If a Share Is Lost?

The response depends on the signing threshold and recovery design. Remaining authorized participants may be able to continue operating or provision replacement access where supported. Insufficient available signing authority requires the documented recovery process, which should be tested before the wallet holds material assets.

Glossary and Further Reading

Technical resources include NIST’s threshold-cryptography project, the CMP paper, the DKLS23 paper, and our API documentation. For deployment due diligence, review the materials available through our Trust Center.