Multisignature and MPC crypto custody are two ways to distribute the authority to sign a transfer. A script-based multisignature wallet requires signatures from several separate private keys. In threshold signing, an application of secure multiparty computation (MPC), participants use shares of one group signing key to create a signature without reconstructing that key during signing. Both can reduce dependence on a single key holder. A desk can still miss a collateral deadline if too few participants are available. That makes the signing arrangement part of the operational risk of crypto wallet and key custody. NIST threshold cryptography project
The same quorum can produce different evidence
In a Bitcoin script multisig example, a 3-of-5 witness script specifies five public keys and requires three separate valid signatures. Each participant signs with their own private key. When the output is spent, Bitcoin nodes evaluate the script and check the signatures against its authorised public keys. Bitcoin BIP 383, specification
In a separate FROST(Ed25519, SHA-512) example, five participants each hold a share of one group signing key. In the first round, the selected signers supply one-time commitments. In the second, each produces a signature share for the transaction message and the selected set of commitments. The coordinator combines those shares into one Ed25519 signature. A compatible verifier checks that signature under the group public key. The signature itself carries no roster or threshold count. An application can use this ciphersuite where it accepts Ed25519 signatures under that group key and uses the matching transaction message and encoding. RFC 9591, signing protocol, Ed25519 ciphersuite
For the same three-participant quorum, the multisig script verifies three signatures while the Ed25519 verifier checks one group signature.
When the desk needs to move collateral
Suppose five distinct participants hold valid FROST key shares and the desk has no alternate spending or recovery path for this transfer. With two participants offline before signing, the three remaining participants can form a quorum if they are authorised and can finish both rounds with valid contributions. With three participants offline, the two remaining participants fall one short. Availability at the start and completion of a signing attempt are separate. If a selected signer drops out after supplying a commitment, that attempt can fail. Any retry uses a fresh signing attempt with an eligible group and fresh commitments. RFC 9591, aggregation and aborts
The signing quorum counts the valid contributions needed for a cryptographic signature. The approval policy decides whether the transfer should proceed. A desk might require a risk officer to approve a new destination before the signers participate. That approval can be required even when three signing participants are ready. If the risk officer also holds a signing share, only their contribution to the signing protocol counts toward the cryptographic quorum. Both flows can implement the same internal approval policy. The verifier checks signatures for the transaction message under the required keys. The desk records policy approvals separately. RFC 9591, application-specific message validation
Share setup and recovery are also separate from transaction signing. A trusted dealer can create the full key and distribute its shares. A distributed key generation protocol can establish shares without a dealer who sees the full key. The informational FROST RFC describes trusted-dealer setup in Appendix C and leaves distributed key generation to a separate protocol. Recovery after losing access to a quorum depends on the custody arrangement's separate backups or spending path. RFC 9591, introduction and trusted-dealer setup