DKG Ceremony (Distributed Key Generation)

What Is a DKG Ceremony?

A DKG ceremony (distributed key generation ceremony) is a specific, interactive protocol run among a group of participants to collaboratively create a shared public/private key pair. Unlike a standard key ceremony where one entity generates a key and distributes shares, a DKG ceremony ensures the full private key never exists in any single location at any point during the process. Each participant contributes randomness, and the protocol combines these contributions into a group key whose private component is split into shares from the start.

The word "ceremony" is deliberate: this is not a passive computation but a coordinated event that requires all participants to be online and actively communicating. The ceremony typically runs once during system initialization (or when the participant set changes) and must complete successfully before any threshold signing can occur. Once finished, the resulting key shares are used for ongoing threshold signing without repeating the ceremony.

For a deeper look at the mathematical foundations of distributed key generation as a cryptographic primitive, see the companion glossary entry. This article focuses on the ceremony itself: its phases, security properties, failure modes, and operational considerations.

How It Works

A DKG ceremony based on the Pedersen protocol with Feldman Verifiable Secret Sharing (VSS) runs in three main phases. The number of participants is n, and the signing threshold is t: any t participants will later be able to produce a valid signature together. Each participant acts as both a dealer (contributing randomness) and a recipient (receiving shares from others).

Phase 1: Commitment

Every participant generates a random polynomial of degree t-1. The constant term of this polynomial is the participant's secret contribution to the eventual group key. For each coefficient, the participant computes an elliptic curve commitment by multiplying it by the generator point G.

// Participant i generates polynomial of degree t-1
f_i(x) = a_{i,0} + a_{i,1}·x + ... + a_{i,t-1}·x^(t-1)

// Publish commitments for each coefficient
C_{i,j} = a_{i,j} · G   for j = 0, 1, ..., t-1

// Provide a Schnorr proof of knowledge of the secret a_{i,0}
proof_i = SchnorrProve(a_{i,0})

Each participant broadcasts their commitments and proof of knowledge to all others. The Schnorr proof is critical: it prevents rogue-key attacks where a malicious participant could craft their contribution as a function of others' published values to manipulate the final group key. This proof requirement was added by the FROST protocol and is not present in the original Pedersen DKG.

No participant reveals their actual polynomial coefficients during this phase. The commitments are binding (the participant cannot change their polynomial later) but hiding (the commitments do not reveal the secret values).

Phase 2: Share Distribution

After all commitments are received and all proofs verified, each participant evaluates their polynomial at every other participant's index and sends the resulting value as a private share over an encrypted channel:

// Participant i computes a share for participant j
share_{i→j} = f_i(j)

// Sent privately over authenticated, encrypted channel
// (e.g., X25519 + AES-GCM or Noise protocol)

This phase produces n(n-1) private messages: every participant sends a unique share to every other participant. The shares must travel over secure channels because intercepting t or more shares destined for the same recipient from different senders would allow reconstruction of that recipient's final signing share.

Phase 3: Verification and Finalization

Each recipient verifies every share they received using Feldman's VSS check. This check confirms that the share is consistent with the sender's published commitments without revealing any other shares:

// Recipient j verifies share from sender k
// Check: share_{k→j} · G == Σ (j^m · C_{k,m})  for m = 0..t-1

// If check passes: accept the share
// If check fails: broadcast a complaint against k

If a complaint is raised, the accused participant must reveal the correct share publicly. If the revealed share matches the commitments, the complaint is dismissed. If the accused cannot produce a valid share (or fails to respond), they are excluded from the ceremony. The protocol continues with the remaining participants.

After all valid shares are confirmed, each participant computes their final signing share by summing all accepted shares (including their own contribution at their index). The group public key is the sum of all valid participants' constant-term commitments:

// Participant j's final signing share
s_j = Σ f_k(j)   for all valid participants k

// Group public key (same for all participants)
PK = Σ C_{k,0}   for all valid participants k

The group private key (the sum of all secret contributions) is never computed or stored anywhere. It exists only as an implicit mathematical relationship distributed across the participants' shares.

DKG Ceremony vs. Trusted Dealer

The alternative to running a DKG ceremony is a trusted dealer setup, where one entity generates the full private key, splits it using Shamir's Secret Sharing, distributes the shares, and then must destroy the original key.

A trusted dealer approach is simpler and works when participants already trust one entity: for example, a company splitting its own backup key internally. A DKG ceremony is necessary when no single party should be trusted with the full key, such as in decentralized protocols, cross-organizational custody, or blockchain infrastructure. IETF RFC 9591 (which standardizes FROST signing) includes only a trusted-dealer appendix for reference and intentionally leaves DKG out of its scope, acknowledging it as a separate protocol concern.

Why DKG Ceremonies Matter for FROST

FROST (Flexible Round-Optimized Schnorr Threshold Signatures) is a threshold signing protocol that produces standard Schnorr signatures from distributed key shares. The DKG ceremony is the setup phase that creates those shares. Without a correctly executed DKG ceremony, FROST signing cannot begin.

FROST's DKG adds a Schnorr proof-of-knowledge requirement in Phase 1 that is not present in the original Pedersen DKG. This proof ensures each participant actually knows the secret behind their commitment, preventing a class of attacks where a malicious participant could manipulate the group public key by choosing their commitment as a function of others' commitments. For a detailed walkthrough of how signing works after the ceremony completes, see the FROST threshold signatures deep dive.

After the ceremony, any t-of-n participants can cooperate in a two-round signing protocol to produce a signature that is indistinguishable on-chain from a single-signer Taproot spend. External verifiers see a standard 64-byte Schnorr signature and cannot determine how many parties were involved.

Use Cases

Bitcoin Layer 2 Protocols

Spark uses a FROST DKG ceremony so that its set of independent Signing Operators (SOs) collectively holds one side of a 2-of-2 signing arrangement for each virtual UTXO. The user holds the other key share. Because the operator key is generated via a DKG ceremony, no single operator can sign unilaterally. This creates a 1-of-n trust model from the user's perspective: only one honest operator is needed to prevent theft. Learn more about Spark's architecture in the Spark Layer 2 overview.

MPC Wallets and Institutional Custody

MPC wallets use DKG ceremonies during initial wallet creation to distribute key material across multiple devices, servers, or organizations. The ceremony ensures that the wallet's private key never exists in one place, even during setup. Institutional custodians run DKG ceremonies across hardware security modules in different geographic locations, so no single facility can be compromised or coerced to produce a signature alone.

Federated Systems

Protocols like Fedimint run a Pedersen DKG ceremony over BLS12-381 when a new federation is created. The ceremony produces threshold keys that allow federation guardians to jointly manage funds. Once the ceremony completes, the federation can process transactions as long as the threshold of guardians remains online.

Randomness Beacons

Decentralized randomness services like drand use DKG ceremonies to create threshold BLS keys across a distributed set of operators. These operators then produce verifiable random values through threshold signing. The DKG ceremony ensures that no single operator can predict or manipulate the random output.

Risks and Considerations

Liveness During the Ceremony

All participants must remain online and responsive throughout the entire ceremony. If a participant drops offline during Phase 2 (after receiving others' commitments but before sending shares), the ceremony may need to restart with the absent party excluded. This is a one-time coordination cost: once the ceremony finishes, ongoing signing only requires t-of-n participants.

Malicious Participant Behavior

A malicious participant can attempt several attacks during a DKG ceremony:

• Sending inconsistent shares: detected by the Feldman VSS check in Phase 3, resulting in exclusion
• Withholding shares: detected by timeout, resulting in exclusion
• Biasing the group key: Gennaro et al. showed that a malicious participant in Pedersen DKG can bias the distribution of the group public key. However, this bias does not weaken threshold Schnorr signatures in practice
• Rogue-key attacks: prevented by the Schnorr proof-of-knowledge requirement in FROST DKG

As long as fewer than t participants collude, the ceremony produces secure key shares. A single honest participant is sufficient to ensure the group key is not compromised.

Secure Communication Channels

Phase 2 transmits secret shares that must travel over encrypted, authenticated channels. If an attacker intercepts shares from t or more senders destined for the same recipient, they can reconstruct that recipient's final signing share. Production deployments typically use Noise protocol or X25519 key exchange with AES-GCM for share transmission. End-to-end encryption between participants is not optional: it is a hard security requirement.

Scalability Constraints

The communication complexity of a DKG ceremony scales quadratically with the number of participants. Phase 2 alone requires n(n-1) private messages. This makes ceremonies with hundreds of participants impractical without protocol modifications. Most production deployments use modest participant counts (typically 3 to 20). For larger groups, protocols like the asynchronous DKG by Das et al. trade additional rounds for better fault tolerance, but these remain an active area of research.

No Replay or Reuse

A DKG ceremony produces key shares tied to a specific group of participants and a specific threshold. If the participant set changes (adding or removing an operator), a new ceremony or a share-refresh protocol must be run. FROST supports proactive share refresh, which updates shares without changing the group public key, but this is itself a multi-round interactive protocol.

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.