What Is NestedMuSig2?

Bitcoin developers already live with a practical constraint: keys represent policies, not just people. A taproot key path spend often encodes a multi-party control policy such as a 2-of-3 wallet, a corporate approval flow, or a service architecture where one cosigner is an HSM cluster. MuSig2 helps by turning many signers into one aggregate Schnorr public key and one Schnorr signature, so on-chain data is compact and private. NestedMuSig2 still outputs BIP-340 Schnorr signatures and remains compatible with existing MuSig2 (BIP-327) infrastructure.

NestedMuSig2 starts where plain MuSig2 gets awkward. In real systems, one participant in a signing session is often not a single device. It can be a team, a quorum, or another service that internally coordinates multiple keys. If you try to nest MuSig2 naively, by treating that subgroup output as just another signer without carefully accounting for nonce binding and coefficient cascades, you break the security reduction, specifically the reduction to the AOMDL problem in the random oracle model. In the naive approach, binding terms and key coefficients do not compose multiplicatively across levels, which is exactly what the cascade construction fixes.

The paper solves this by introducing a cosigner tree and two key adjustments. First, Round 1 uses explicit nonce binding at every aggregation layer. Second, Round 2 computes each leaf signer’s partial signature with cascaded key coefficients and binding values from its full path to the root. The resulting signature still has the standard Schnorr form.

At the core, the final verification equation remains:

g^s = R \cdot \tilde{X}^c

Here X̃ is the root aggregate key and c = H_sig(X̃, R, m). The verifier only sees (X̃, m, σ) with σ = (R, s). There is no marker that says this came from a nested signing structure.

That indistinguishability property is the point. You can compose sophisticated internal control structures while presenting a normal Schnorr interface externally, with the same verification logic and similar privacy profile as flat MuSig2.

NestedMuSig2 uses four hash functions, all modeled as random oracles that map to scalars in

\mathbb{Z}_p

H_{\text{agg}}

derives key aggregation coefficients,

H_{\text{non}}

binds nonce vectors at non-root levels, and

H_{\text{non\_bar}}

binds the root nonce vector together with the message.

H_{\text{sig}}

produces the final Schnorr challenge.

The rest of this guide walks through the protocol step by step: tree structure, key aggregation, Round 1 nonce flow, Round 2 cascading coefficients, and final verification. Keep the playground open while reading. It lets you build trees, inspect intermediate values at each node, and see exactly how local computations collapse into one standard signature.