Multisig, MPC and threshold signatures compared

Three ways to remove the single key

A single private key is a single point of failure for theft, loss and coercion. There are three families of fixes, and they differ in where the policy lives:

"MPC wallet" is the marketing name for the third family: secure multiparty computation is the general technique, and threshold signing is the specific computation. The schemes themselves are covered in signature schemes; this guide is about the systems built from them.

Onchain multisig: policy you can read

Bitcoin has had script multisig since the start. OP_CHECKMULTISIG accepts at most 20 keys, and P2SH’s 520 byte script limit caps it at 15 compressed keys. Tapscript (BIP 342) retired that opcode for OP_CHECKSIGADD, which counts valid signatures one key at a time and supports batch verification, and Taproot lets a MuSig2 or FROST key sit on the key path with the explicit m of n script as a fallback leaf.

EVM chains implement multisig as a contract account. Safe (formerly Gnosis Safe) is the common example: a proxy holding owners, a threshold and a nonce, which executes a transaction once enough owners have signed its EIP-712 hash. Solana has program based multisigs, Squads being the usual example, where a program owned account holds the policy. What owners sign on Safe is worth knowing field by field:

// What every Safe owner actually signs: an EIP-712 hash of this struct.
SafeTx(
  address to,
  uint256 value,
  bytes   data,            // hashed as keccak256(data) inside the struct
  uint8   operation,       // 0 = CALL, 1 = DELEGATECALL: run code at 'to' inside the Safe's own storage
  uint256 safeTxGas,
  uint256 baseGas,
  uint256 gasPrice,
  address gasToken,
  address refundReceiver,
  uint256 nonce
)
domainSeparator = keccak256(abi.encode(DOMAIN_SEPARATOR_TYPEHASH, chainId, safeAddress))
safeTxHash      = keccak256(0x19 || 0x01 || domainSeparator || hashStruct(SafeTx))

// The proxy keeps its implementation address ('singleton') in storage slot 0.
// A DELEGATECALL into code that writes slot 0 replaces the wallet's logic.

The strengths are real. The policy is public and chain enforced, anyone can verify who signed what, signers can be rotated with an ordinary transaction, and modules and guards can add timelocks, spending limits and allowlists. The costs: a deployment per chain (a contract wallet’s address and features can differ between chains), extra gas for each signature, a public map of your security setup, and contract risk of its own; the 2017 Parity multisig failures are the classic case (see vulnerability classes). The user level view is in multisig wallets.

Secret sharing and distributed key generation

Threshold schemes start from Shamir secret sharing. Hide the secret s as the constant term of a random polynomial of degree t − 1 and give party i the share f(i). Any t shares determine the polynomial; fewer reveal nothing.

A toy 2 of 3 example modulo 13 with s = 7 and f(x) = 7 + 3x gives shares f(1) = 10, f(2) = 0 and f(3) = 3. Parties 1 and 3 get λ₁ = 3 ÷ 2 and λ₃ = 1 ÷ (−2), and 10 × 3/2 + 3 × (−1/2) = 27/2, which is 7 modulo 13. Any other pair gives 7 too.

Reconstructing s anywhere recreates the single key you were trying to avoid, so threshold signing never does. Key generation is distributed as well: in a DKG each party deals shares of its own random polynomial and publishes Feldman commitments a_ik·G so the others can check their shares. Each party’s final share is the sum of what it received, the group key is the sum of everyone’s a_i0·G, and no one ever knows the group secret.

Two maintenance operations matter in production. Proactive refresh has the parties add shares of a random polynomial whose constant term is zero: every share changes, the public key and address do not, and shares stolen before the refresh become useless. Resharing moves the same key to a new set of parties or a new threshold. Neither is possible with a plain multisig without moving funds or changing the onchain policy.

Threshold ECDSA: why it is hard

ECDSA computes s = k⁻¹(z + r·d). Both the nonce inverse and the product with the key are non-linear in secrets that are now spread across parties, so threshold ECDSA needs multiplicative to additive conversions built from Paillier encryption or oblivious transfer, wrapped in zero knowledge proofs that each party behaved. The protocol lineage runs from Lindell’s two party scheme (2017) through GG18 and GG20 (Gennaro and Goldfeder) to CGGMP21 (Canetti, Gennaro, Goldfeder, Makriyannis and Peled), which adds identifiable aborts, proactive refresh and presigning.

That complexity is the attack surface. In August 2023 researchers disclosed CVE-2023-33241: implementations of GG18 and GG20 that did not verify a counterparty’s Paillier key could be fed a malicious one with a cheating range proof, letting an attacker extract the full private key after about 16 signatures or more. CVE-2023-33242 showed that Lindell17 implementations mishandling aborted signing attempts leaked one bit per attempt, 256 attempts in all. In both cases the flaw was a missing validation step, not a break of the underlying mathematics.

FROST: threshold Schnorr in two rounds

Schnorr is linear, so threshold Schnorr is far simpler. FROST (Komlo and Goldberg, 2020), standardized as RFC 9591 in June 2024, signs in two rounds, and the first can be done in advance:

# FROST signing (RFC 9591), for signer i in the chosen signing set S.
# From key generation: secret share s_i and group key PK = s*G. The full
# secret s = sum(lambda_i * s_i) is never computed by anyone.

# Round 1: can run ahead of time, one pair per future signature
d_i, e_i = random_scalar(), random_scalar()      # fresh and random, never derived deterministically
publish (D_i, E_i) = (d_i*G, e_i*G)

# Round 2: the coordinator sends msg and the list B of everyone's (D_j, E_j)
rho_j = H1(PK, msg, B, j)          for each j in S    # binding factors
R     = sum(D_j + rho_j*E_j        for j in S)        # group nonce
c     = H2(R, PK, msg)                                # Schnorr challenge
lam_i = prod(j / (j - i)           for j in S if j != i)
z_i   = d_i + e_i*rho_i + lam_i*s_i*c                 # signature share, sent to coordinator

# Aggregate z = sum(z_i). (R, z) is an ordinary Schnorr signature:
#   z*G == R + c*PK

The binding factor ρ ties each signer’s nonce to the message and the full commitment list, which blocks the concurrent session forgeries (Drijvers and co-authors, 2018; the ROS attack, 2020) that break simpler two round designs. FROST is not robust: one misbehaving signer makes the session abort, though the faulty share can be identified and excluded; ROAST (2022) wraps FROST to keep retrying until an honest quorum succeeds. RFC 9591 defines ciphersuites for Ed25519, ristretto255, Ed448, P-256 and secp256k1, and output from the first can be checked by any standard Ed25519 verifier. Its secp256k1 suite, however, hashes and encodes points differently from BIP 340, so Taproot use needs a BIP 340 compatible variant rather than the RFC suite as written.

The tradeoffs that decide the choice

Recoverability and vendor dependence deserve a line each. A multisig built from hardware wallets can be operated with open source tools if every vendor disappears. Many MPC deployments depend on one provider’s software for signing and for any key export, so read the disaster recovery terms before trusting one with a treasury. The approaches also compose: TSS keys can be owners on a Safe, putting an institutional quorum behind each onchain signature.

Bybit, February 2025: the interface is part of the key

Bybit kept ether in a Safe multisig cold wallet, with signers approving transactions through the Safe{Wallet} web interface. Reports by Sygnia and others, drawing on Mandiant’s findings for Safe, reconstruct the sequence:

The attribution is in the FBI’s public service announcement. Every signature was genuine and the threshold worked exactly as designed. The attackers never needed a key; they needed every signer to look at the same compromised screen. Earlier incidents followed the same pattern, including WazirX in July 2024 (about $230 million) and Radiant Capital in October 2024 (about $50 million), where the interface showed legitimate data while something else was signed. Our Bybit case study tells the story for a general audience.

Designing the signing path

1. Verify on something the interface cannot touch

   Recompute the safeTxHash (or the equivalent digest) on a separate machine from the raw fields, and compare it with the hash the hardware wallet displays. Decode to, operation and data independently. A DELEGATECALL on a routine transfer is an immediate stop.

2. Insist on clear signing

   Devices that show decoded intent rather than a hash remove blind signing. In May 2026 an Ethereum working group with the Ethereum Foundation launched an open registry of ERC-7730 descriptors so wallets can display human readable transaction details consistently.

3. Enforce policy onchain, not in the UI

   A Safe guard can reject DELEGATECALL except to allowlisted targets such as a known batching contract, and timelocks on upgrades and large transfers give monitoring time to react. Rules in a web app can be rewritten by whoever controls the web app.

4. Remove the common dependency

   Signers on different operating systems, interfaces and networks, with at least one using an independently built client, turn a single compromise into a detectable disagreement.

5. Simulate and monitor

   Simulate the exact signed payload before execution and alert on any change of implementation, owner set or threshold. For MPC, keep policy approval separate from the signing nodes and refresh shares after any device loss.

Choosing, and what is still open

A treasury on one EVM chain with public governance usually fits onchain multisig with guards and timelocks: the transparency is a feature. Custody across many chains with private internal policy leans toward TSS. On Bitcoin, Taproot lets you have both, a MuSig2 or FROST key path for everyday spends and an explicit script path for recovery. Individuals rarely need either; a hardware wallet and a tested backup are covered in structuring your wallets.

Open problems remain: a BIP 340 compatible FROST standard, robust threshold signing that does not abort on one bad participant, post quantum threshold signatures (lattice schemes do not share Schnorr’s tidy linearity), and signing interfaces that can prove to a signer what a transaction will do.

Common questions

Where to go next