Signing Share

What Is a Signing Share?

A signing share is a scalar value that represents one participant's contribution to a collaborative signature. In a threshold signing scheme, no single party holds the complete private key. Instead, each participant holds a key share and uses it to produce a signing share for a given message. A coordinator then aggregates these signing shares into a single digital signature that is indistinguishable from one produced by a single signer.

The concept originates from Shamir-based threshold cryptography, where a secret is split into shares such that any subset of a minimum size can reconstruct the original. Signing shares apply this idea to signature generation: rather than reconstructing the private key (which would create a single point of compromise), each participant computes their portion of the signature independently. The math ensures that combining these portions produces a valid signature without ever assembling the key.

Signing shares are defined in RFC 9591, the IETF specification for the FROST protocol, published in June 2024. The specification formalizes how signing shares are generated, transmitted, verified, and aggregated.

How It Works

Signing share generation occurs during the second round of the FROST protocol. Before this step, each participant has completed Round 1 by generating and broadcasting cryptographic nonce commitments. Round 2 is where the actual signing shares are computed.

Step-by-Step Process

1. Commitment collection: each signer broadcasts a pair of nonce commitments (a hiding commitment and a binding commitment) to all other participants
2. Binding factor computation: each signer computes a binding factor for every participant, derived from a hash of the signer's identifier, the message, and all collected commitments
3. Group commitment: each signer computes the aggregate group nonce R by combining all participants' commitments, weighted by their binding factors
4. Challenge computation: the challenge c is derived as the hash of the group nonce R, the group public key, and the message (following the standard Schnorr challenge construction)
5. Lagrange coefficient: each signer computes their Lagrange interpolation coefficient for the specific set of signers participating in this session
6. Signing share: each signer combines their nonces, Lagrange coefficient, key share, and the challenge into a single scalar value
7. Aggregation: the coordinator collects all signing shares and sums them to produce the final signature scalar z, yielding the complete signature (R, z)

The Signing Share Equation

In FROST, each participant i computes their signing share z_i using the following formula:

z_i = d_i + (e_i * ρ_i) + (λ_i * s_i * c)

where:
  d_i = hiding nonce (secret, generated in Round 1)
  e_i = binding nonce (secret, generated in Round 1)
  ρ_i = binding factor (derived from hash of commitments)
  λ_i = Lagrange coefficient for signer i
  s_i = signer i's secret key share
  c   = challenge hash: H(R || group_pubkey || message)

The first two terms (d_i + e_i * ρ_i) contribute the signer's nonce portion. The third term (λ_i * s_i * c) contributes the key share portion, scaled by the Lagrange coefficient so that any valid threshold subset produces the same aggregate result.

The coordinator aggregates all signing shares by simple addition:

z = z_1 + z_2 + ... + z_t

Final signature: (R, z)

This is a standard Schnorr signature, verifiable
with the group public key using ordinary verification.

Verification of Individual Signing Shares

Before aggregation, the coordinator can verify each signing share independently. This is done by checking that z_i * G equals the signer's public nonce commitment plus λ_i * c times the signer's public key share. If any share fails verification, the coordinator identifies the misbehaving party and aborts the session. This property is called identifiable abort and is a key feature of FROST over earlier threshold schemes.

Signing Shares vs. MuSig2 Partial Signatures

Both FROST signing shares and MuSig2 partial signatures are scalar values that aggregate into a standard Schnorr signature. The differences reflect their distinct trust models:

In MuSig2, each signer uses their complete private key and a key aggregation coefficient (derived from all participants' public keys) to produce their partial signature. In FROST, each signer uses a secret key share and a Lagrange coefficient specific to the current signing set. The Lagrange coefficient ensures that any qualifying subset of t signers produces the same aggregate signature. For a deeper comparison, see the research article on MuSig2 multisignatures.

Why Signing Shares Matter

Signing shares are the mechanism that makes threshold custody practical. Without them, collaborative signing would require reconstructing the private key in one location, defeating the purpose of distributing trust. By keeping the key distributed and producing only signing shares, protocols achieve several properties simultaneously:

• No single point of compromise: the complete private key never exists on any single device, even during signing
• On-chain privacy: the aggregated signature is a standard Schnorr signature, indistinguishable from a single-signer transaction on the Taproot key path
• Fault tolerance: in a threshold scheme, some signers can be offline or compromised without blocking signature production
• Efficient verification: validators and nodes verify one signature, not multiple individual signatures

Use Cases

Institutional Custody

Custody providers distribute key shares across multiple hardware security modules in different geographic locations. When a withdrawal is authorized, each HSM produces a signing share independently. The signing shares are collected and aggregated into a single transaction signature. If one HSM is compromised or offline, the remaining devices can still sign as long as the threshold is met.

Bitcoin Layer 2 Protocols

Spark uses FROST threshold signing with signing shares to manage virtual UTXOs off-chain. Operators and users produce signing shares collaboratively to authorize transfers, exits, and state updates without broadcasting individual signatures on-chain. For a comprehensive explanation, see FROST Threshold Signatures Explained.

Distributed Key Generation Ceremonies

During a distributed key generation (DKG) ceremony, participants establish key shares without any single party ever knowing the full key. After DKG, every signing operation produces signing shares that aggregate into signatures under the group public key established during the ceremony.

Cooperative Signing Workflows

Organizations use cooperative signing workflows where multiple approvers must contribute signing shares before a transaction is broadcast. This supports compliance policies like dual authorization, quorum-based spending limits, and time-locked approvals.

Risks and Considerations

Nonce Reuse

If a signer reuses the same nonce pair across two different signing sessions, an attacker who observes both signing shares can extract the signer's secret key share algebraically. This is the same nonce reuse vulnerability that affects all Schnorr-based schemes. FROST mitigates this by binding nonces to the specific signing session through the binding factor, but implementations must still ensure nonces are never reused.

Threshold Corruption

The security of signing shares assumes that fewer than t participants are compromised. If an adversary controls t or more key shares, they can produce valid signing shares independently and forge signatures. The threshold t must be chosen carefully: too low and the scheme is easier to attack, too high and it becomes fragile if signers go offline.

Communication Security

Signing shares must be transmitted from each signer to the coordinator over authenticated channels. If an attacker intercepts and replaces a signing share in transit, the resulting aggregated signature will be invalid (detectable) or the attacker could mount a more sophisticated attack. RFC 9591 requires that signing shares be sent over authenticated channels, though it does not mandate a specific transport mechanism.

Coordinator Trust

The coordinator who aggregates signing shares sees all individual shares. While this does not allow the coordinator to extract key shares (the nonce blinding prevents this), a malicious coordinator could selectively exclude valid shares or substitute invalid ones. Identifiable abort and share verification mitigate this, but the coordinator role still represents a centralization point in the signing workflow.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.