MPC or MultisigA Threat-Model Decision Framework for Institutional Signing

The companion report on the custody control plane made a deliberate choice to keep signing technology in its place, beneath the authorization policy, and to defer the detailed comparison of signing mechanisms to a separate treatment. This is that treatment. It examines the two mechanisms that dominate institutional signing, multi party computation and on ledger multisignature, and sets out how to choose between them.

The framing matters, because the choice is usually presented as a contest in which one mechanism is better and the institution should adopt the winner. That framing is wrong. The two are not points on a single scale of quality. They are different shapes of trust and different shapes of failure. Multi party computation places its protection in an off ledger cryptographic protocol. Multisignature places its protection in on ledger logic that the network enforces and anyone can read. These are genuinely different architectures, with different things to verify, different ways to break, and different operational profiles.

Because they are different architectures rather than competing products, the right question is which mechanism fits the institution's situation: the adversary it is defending against, the networks it must operate on, the way it needs to recover from incidents, and the assurances its auditors and regulators require. This report builds that decision framework. It describes what each mechanism actually is, where they diverge in ways that affect real decisions, and how to map an institution's threat model onto the choice. The aim is to let an institution choose deliberately, against its own circumstances, rather than adopting whatever its provider happens to sell or whatever the market currently favors.

Both mechanisms exist to ensure that no single party can authorize a transaction alone. They achieve that shared goal through different means, and the means is where everything else follows from.

Multi party computation, in this context, is a way for several parties to jointly produce a single digital signature without any one of them ever holding the complete private key. The key is split into shares, distributed among the parties, and when a signature is needed the parties run a cryptographic protocol that combines their shares into one valid signature. The crucial properties are that the whole key never exists in one place, not even at the moment of signing, and that what reaches the ledger is an ordinary single signature indistinguishable from any other. The splitting and the joint computation happen off the ledger, inside the protocol, and the network sees only the result.

On ledger multisignature takes a different approach. Instead of producing one signature from shares, it requires several separate signatures from several distinct keys, and the requirement that a given number of those signatures be present is enforced by the ledger itself. The arrangement is recorded on chain: the ledger knows that this account requires, say, a certain number of signatures out of a defined set, and it will reject a transaction that does not meet the threshold. Each signer holds a complete key of their own, signs independently, and the network checks that enough valid signatures are present before accepting the transaction.

The difference in one line is where the logic lives. Multi party computation puts the multi party requirement in an off ledger protocol and presents a single signature to the network. Multisignature puts the requirement in on ledger logic and presents multiple signatures to the network. Almost every practical distinction between the two flows from this.

The grid compares the two across the dimensions that actually shape a decision. For each, it states the multi party computation behavior, the multisignature behavior, and why the difference matters.

No row makes one mechanism the winner. Each row is a place where the two diverge and where an institution's circumstances tip the choice one way or the other. An institution that operates across many chains and values privacy reads the chain coverage and visibility rows toward multi party computation. An institution that values direct on chain verifiability and operates mainly where multisignature is well supported reads them the other way.

The strength of multi party computation is that the complete key never exists in one place at any time. There is no single moment, not even during signing, when an attacker could capture the whole key, because the whole key is never assembled. The protection is built into the cryptography rather than added around a key that exists somewhere. For an institution whose primary fear is the compromise of a single store of key material, this is a powerful property.

Two further properties follow from the design and matter in practice. The first is portability. Because the protocol outputs a standard single signature, the same arrangement works across many different networks without each network needing to support anything special. An institution operating across a range of chains can use one signing approach everywhere, which simplifies operations and reduces the number of distinct arrangements to secure. The second is uniformity and privacy on the ledger. The network sees an ordinary signature and learns nothing about how many parties were involved or who they were, which keeps the institution's signing arrangement private and indistinguishable from any other account.

The cost is where the assurance rests. With multi party computation, the protection is only as good as the protocol, its implementation, and the controls of whoever operates it, and none of that is visible on the ledger. An institution cannot verify the arrangement by reading the chain; it must instead trust the design and the implementation, which means reviewing them, or relying on others who have. A flaw in the protocol or, more commonly, in a specific implementation can undermine the protection in ways that are not externally observable. This is not an argument against multi party computation. It tells you where to spend review effort: on the protocol, its implementation, and the operator, since that is where the security actually lives and the ledger will not surface a flaw in any of them.

The strength of on ledger multisignature is transparency. The arrangement is recorded on the network, so the signer set and the threshold can be inspected and verified by anyone, including the institution's own auditors and its counterparties. There is no need to trust a claim about how signing works, because the requirement is enforced by the network and visible on it. For an institution that values being able to demonstrate, directly and verifiably, that its assets require multiple parties to move, this is a strong property.

The transparency also simplifies certain kinds of assurance. An auditor can confirm the signing requirement by examining the chain rather than by reviewing a protocol and an implementation. A counterparty can satisfy itself about the arrangement the same way. The protection is legible in a way that an off ledger protocol is not, and for some institutions and some regulators that legibility is worth a great deal.

The costs are twofold. First, multisignature depends on each network's own support for it, and that support varies. An arrangement that is clean and well supported on one network may be awkward, limited, or absent on another, which complicates operating across many chains. Second, multisignature involves managing several complete keys, one per signer, each of which is a full key that exists and must be protected. The failure topology is therefore about protecting a set of real keys and about the correctness of each network's signing logic, rather than about a single off ledger protocol. Neither cost is disqualifying. For multisignature, the review effort goes elsewhere: into per network support and into protecting and managing several full keys. As with multi party computation, the mechanism can be excellent or can be undermined by how it is deployed, and the deployment is where the attention belongs.

The decision between the two mechanisms should follow from the threat model, which is the specific account of what an institution is defending against. Choosing on any other basis, on novelty, on familiarity, on what a provider prefers to sell, risks adopting a mechanism whose strengths do not match the institution's actual risks.

Start by naming the adversary and the failure the institution most fears. If the dominant fear is the compromise of a single concentrated store of key material, the property that the whole key never exists favors multi party computation. If the dominant need is to demonstrate the signing arrangement directly and verifiably to auditors, regulators, or counterparties, the on chain transparency favors multisignature. If the institution operates across many networks and wants one uniform approach, portability favors multi party computation. If it operates mainly where multisignature is well supported and values direct verifiability, that favors multisignature. The threat model turns these abstract differences into a concrete preference.

The deeper point is that the choice is also about where an institution is willing to place its trust and concentrate its diligence. Multi party computation asks the institution to trust and verify a protocol, an implementation, and an operator, none of it visible on chain. Multisignature asks the institution to trust and verify per network logic and the protection of several full keys, with the arrangement visible on chain. Both are legitimate places to put trust, and an institution should choose the one whose diligence it can actually perform and sustain. A mechanism whose security depends on review the institution cannot do, or on an operator it cannot assess, is not made safe by being the better technology in the abstract. The right choice is the one whose assurances the institution can genuinely stand behind, matched to the adversary it actually faces.

How an institution changes its signing arrangement, when a signer leaves, a key is compromised, or the structure needs to evolve, differs between the two mechanisms, and the difference is operationally significant enough to factor into the choice.

Under multisignature, changing the signer set is an on chain action. The account's configuration is altered by a transaction that adds or removes signers or changes the threshold, and the change is recorded on the network. This has the advantages and disadvantages of everything on chain. It is transparent and verifiable, and it is also a network action with whatever cost, latency, and exposure that entails, executed under the same authority that governs the account. Rotating a compromised signer means performing this on chain change correctly and promptly, which the arrangement must be designed to allow.

Under multi party computation, changing the set of parties is a protocol level operation, often described as a reshare, in which the secret is redistributed among a new set of shares without the underlying key changing or ever being assembled. This happens off the ledger, within the protocol, and the network sees nothing change. The reshare can rotate shares, replace a compromised party, or change the structure, and it does so without an on chain footprint. The advantages and disadvantages mirror the off ledger nature of the whole mechanism: the change is private and not tied to a network's capabilities, and its correctness rests on the protocol and the operator rather than on anything observable on chain.

For recovery specifically, the question an institution should ask of either mechanism is the one from the control plane report: what is the designed, tested path for a lost key, a compromised signer, and an unavailable party, and does it maintain control throughout the transition. Both mechanisms can support sound recovery, and both can be deployed without it. The mechanism shapes how recovery is performed, on chain reconfiguration in one case and protocol reshare in the other, but it does not by itself guarantee that recovery was designed. That remains the institution's responsibility regardless of which signing technology sits underneath.

Multi party computation (MPC)

A cryptographic technique that lets several parties jointly compute a single signature from key shares, without any party ever holding the complete key.

Multisignature

An arrangement requiring signatures from several distinct keys before a transaction is valid, with the requirement enforced by the network.

Key share

A portion of a split key held by one party in a multi party computation arrangement, useless on its own.

Threshold

The number of signatures or shares required to authorize a transaction, for example three out of five.

Reshare

A protocol level operation that redistributes a secret among a new set of shares without changing or assembling the underlying key.

Failure topology

The shape of how a system can fail: where risk concentrates and how a compromise would propagate.

Threat model

A specific account of the adversaries and failures a system is designed to defend against, used to drive security decisions.

Signer set

The defined group of keys or parties permitted to participate in authorizing transactions.

On chain visibility

The extent to which an arrangement can be inspected and verified directly on the network.

Citation slots below mark claims and context that require source verification before this document is treated as externally citable. They are placeholders by design. This library does not assert sourced facts without sources.

1. 01

   Cryptographic literature on threshold signatures and multi party computation as applied to key management.

   Citation pending[Citation needed: peer-reviewed threshold-signature and MPC references]

2. 02

   Documentation of native multisignature support and its variation across major networks.

   Citation pending[Citation needed: protocol documentation on multisignature support]

3. 03

   Security analyses of implementation flaws in deployed signing systems.

   Citation pending[Citation needed: published reviews of signing-system implementations]

4. 04

   Custody and key management standards addressing signer rotation and recovery.

   Citation pending[Citation needed: recognized key-management standards]

For adjacent BlockHedge work, see The Custody Control Plane for the authorization layer that sits above the signing mechanism, and Custody Architecture in Digital Asset Markets for the surrounding custody analysis.