Multisig Is Broken. Here’s How MPC and FROST Fix It.

Introduction

There is frequent confusion in the blockchain and wallet ecosystem between multisignature schemes such as MuSig2 and true Threshold Signature Schemes (TSS) implemented using Multi-Party Computation (MPC). Both approaches allow multiple participants to jointly authorize a transaction and produce a single valid signature. However, their security models, cryptographic assumptions, and trust guarantees differ substantially.

This article compares MuSig2, TSS, and MPC from both a mathematical and implementation perspective.

Background: The WazirX Multisig Case

WazirX, one of India’s largest exchanges, used a multisignature scheme to secure its wallets. Their custody model relied on multiple keyholders, with transactions requiring approval from a set of signers.

In practice, this was an N-of-N (or M-of-N) multisig setup, where multiple independent private keys had to sign before funds could move. This design protected against unilateral compromise but also created bottlenecks and operational risks and WazirX hack (July 2024) did happen. Around $230M was drained from their multisig wallet.

Lessons from WazirX

• Operational rigidity: In a pure multisig (like MuSig2 or simple M-of-N), if one signer is unavailable or compromised, the system can stall.
• Transparency: On-chain multisig schemes expose signer sets and thresholds, which can reduce privacy and sometimes create attack surfaces.
• Not MPC: Despite being called “multisig security,” the model did not involve distributed key generation or threshold signatures. Each keyholder still had a complete private key.

A user loses his savings after hackers exploit a multisig setup. As seen in the WazirX case, multisig exposed weaknesses: once attackers controlled enough keys, they could drain the wallet.

Schnorr/Ed25519 Signature Recap

At the core, both MuSig2 and TSS build on Schnorr-style signatures (Ed25519 is a Schnorr variant). A standard signature is: s = r + k * x

• x: private key scalar
• X = g^x: public key
• r: random nonce
• R = g^r: public nonce point
• k = H(X || R || message): challenge hash

The final signature is (R, s) and is verified by checking:

g^s == R + k * X

1. MuSig2: N-of-N Multisignature Aggregation

Key Generation

Each participant generates a full keypair (x_i, X_i). These are independent and equivalent to any standard Ed25519 keypair.

Public Key Aggregation

All public keys are collected and combined: X_agg = Σ (a_i * X_i)where coefficients a_i are computed via a hash of all public keys to prevent rogue-key attacks.

Nonce Generation

Each participant generates a nonce r_i and publishes R_i = g^r_i. These are combined: R = Σ R_i

Partial Signatures

Each participant computes: s_i = r_i + k * a_i * x_i, where k = H(X_agg || R || message).

Signature Aggregation

The final signature is: s = Σ s_i, σ = (R, s)

Characteristics

• Each participant holds a complete private key.
• Security is enforced by requiring all N participants (N-of-N).
• No secret sharing or threshold reconstruction.
• Output is indistinguishable from a normal Ed25519 signature.

2. Classic Threshold Signatures (TSS with VSS/DKG)

Key idea

One logical private key x is split into shares x_i using secret sharing. Signing is done by locally computing γ_i = r_i + k * x_i and then interpolating.

Key Generation

Dealer-based TSS

• A trusted dealer generates x.
• Splits it into shares x_i using Shamir or Feldman VSS.
• Distributes shares and deletes x.

Weakness: you must trust the dealer not to keep or leak x.

Dealerless DKG (Feldman/Pedersen VSS)

• Each party proposes randomness and commitments.
• Shamir-style polynomials are combined to define one global key x.
• Each party receives their share x_i.
• Public key X = g^x is derived collectively.

No one ever explicitly knows the full x.

Nonce Generation

• Each party generates a nonce share r_i.
• Nonce point: R = g^(Σ r_i).

Signing

• Each party computes: γ_i = r_i + k * x_i
• A combiner uses Lagrange interpolation over the subset of signers to reconstruct: s = Σ λ_i * γ_i,where λ_i are interpolation coefficients.

Properties

• Works with t-of-n flexibility.
• Heavy on communication (verification of shares, polynomial proofs).
• Each signature requires a fresh round of communication.
• Signers reveal partials that a combiner interpolates into s.

3. MPC-DKG with FROST (Flexible Round-Optimized Schnorr Threshold Signatures)

Key idea

FROST is not just “secret sharing + interpolation.” It is an interactive MPC protocol designed for Schnorr/Ed25519 signatures that:

• Distributes the key during DKG.
• Produces signatures in a way that minimizes communication.
• Ensures robustness against rogue key and nonce reuse attacks.

Key Generation (FROST DKG)

• Each participant samples a polynomial and commits to it.
• Shares are exchanged and verified (like Pedersen VSS).
• At the end, each participant has:
• A private share x_i.
• Knowledge of the collective public key X = g^x.

Security: no one ever constructs x explicitly.

Nonce Generation

• FROST requires deterministic, verifiable nonces.
• Each signer produces multiple nonces in advance and publishes commitments.
• For each signing session, a subset of nonces is used (to avoid reuse attacks).

Signing

• Each signer computes their partial: γ_i = r_i + k * x_i, just like classic TSS, but with carefully bound coefficients and commitments.
• An aggregator collects partial signatures, verifies them, and computes:s = Σ γ_i, σ = (R, s), Verification is identical to Schnorr.

Distinctions from “plain” TSS

• Round efficiency: FROST is designed to minimize signing rounds (two rounds per signature: nonce commitments and signature shares).
• Robustness: Handles dropped or malicious signers gracefully.
• Security proofs: FROST is formally proven secure against concurrent sessions, rogue-key attacks, and nonce misuse.
• Interoperability: The output signature is indistinguishable from a standard Schnorr/Ed25519 signature.

4. Why FROST is preferred in modern MPC wallets

No trusted dealer.

Get kartikkktomarrr’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Threshold flexibility.

Compact and indistinguishable signatures.

Protocol designed to run at scale (fast, resilient).

Strong formal security proofs.

MPC vs MuSig2

The terms are often blurred:

• MuSig2 is a multisignature scheme. It is not MPC, even though multiple parties participate.
• MPC/TSS explicitly ensures no single party ever has the private key. This requires distributed key generation and verifiable secret sharing.
• In MuSig2, the private keys are independent; in TSS, the shares are fragments of the same private key

Conclusion

MuSig2, Threshold Signatures, and MPC are often conflated, but they serve different purposes and offer distinct guarantees. MuSig2 is an efficient multisignature aggregation scheme: it compresses multiple signatures into one, but requires every participant to hold a complete private key and to be online for signing. Classic Threshold Signature Schemes, built using verifiable secret sharing and interpolation, allow t-of-n flexibility, but involve heavy communication and are less efficient in practice. Modern MPC protocols such as FROST combine the strengths of both: no trusted dealer, threshold signing, resilience against faults, and efficiency with only two rounds of signing. For this reason, MPC-based FROST protocols have become the preferred foundation for secure and scalable wallet infrastructures.

Common Mislabeling

Many repositories and systems in the ecosystem (including some labeled “TSS” for Solana) actually implement MuSig2. They require N-of-N participants and use each node’s full private key. True threshold MPC, with DKG and t-of-n flexibility, is more complex and stronger in security guarantees.

References

• The WazirX official blog post on their multisig issue.
• The original FROST paper.
• MuSig2 paper.

Further Reading and Code

For those interested in exploring a working implementation, I have built an open-source repository that demonstrates MPC with FROST in practice: mpc-frost (GitHub Repo)

This repo contains a Rust-based implementation of distributed key generation and threshold signing using FROST, showing how MPC differs from multisig at the code level.