This NIP defines a protocol for creating and operating FROST threshold signature quorums over Nostr keys. A quorum is a group of n participants who collectively control a shared Nostr keypair via a (t,n) threshold signing scheme, where any t members can produce a valid signature but no fewer. The quorum's private key is never known to any single party.
## Participant Indexing
Each member is assigned a positive integer index. Indices are derived deterministically by sorting member pubkeys lexicographically as lowercase hex strings and assigning 1-based positions. This ordering must be consistent across all participants and all rounds of a session.
When a new member set is established (rotation), indices are re-derived from the new member list.
## Event Kinds
All events in this protocol are sent as the `content` payload of a NIP-59 gift wrap (kind 1059). The `content` is encrypted to the recipient's pubkey and the wrap is sent to the recipients inbox relays (kind 10050) per NIP 17.
## Quorum Creation
Creates a new quorum and derives its shared Nostr keypair. The private key is never known to any party.
### Phase 0 — Invitation (kind 7050)
The initiator sends each proposed member a gift-wrapped event:
```json
{
"kind":7050,
"content":"<optional human-readable message>",
"tags":[
["session_id","<32-byte random hex>"],
["threshold","<signing threshold>"],
["member","<pk_1>"],
["member","<pk_n>"],
],
}
```
`session_id` is chosen by the initiator and identifies all subsequent events for this DKG session. The quorum's keypair does not yet exist; no key material is present in the invite.
Participation in Round 1 signals acceptance. A member may send a decline event, but is not required to.
### Round 1 — Commitments (kind 7051)
Each accepting participant Pᵢ:
1. Samples a random polynomial `fᵢ(x)` of degree `t−1` over the secp256k1 scalar field, with random coefficients `aᵢ₀, aᵢ₁, …, aᵢ,ₜ₋₁`
5.**BIP-340 normalization**: if `Y` has odd y-coordinate, negate `xⱼ` and `Yⱼ` and use the even-y form of `Y` as the quorum pubkey. This negation must be applied consistently across all subsequent operations.
6. Stores `(xⱼ, Y, Yⱼ, members, threshold, session_id, Round-1 commitments)` durably in IndexedDB. The Round-1 commitments are retained because they are needed to verify resharing participants' shards in Protocol 2.
7. Publishes a DKG confirmation event (kind 7053).
`transcript_hash` enables equivocation detection: a malicious participant may send different Round-1 commitments to different members. If any two confirmations carry the same `session_id` but different `transcript_hash` or `quorum_pubkey`, all participants must abort.
The quorum is considered live once `t` confirmations with matching `transcript_hash` and `quorum_pubkey` have been observed.
---
## Protocol 2: Key Redistribution (Rotation)
Redistributes the existing quorum key to a new member set and/or threshold without reconstructing the private key. The quorum's Nostr pubkey `Y` is preserved, so the quorum's identity, profile, and event history are unaffected.
**Prerequisite**: A contributing set `S` of at least `t` current members must participate.
### Phase 0 — Resharing Proposal (kind 7054)
The initiator (a current member) sends to all current and prospective new members:
```json
{
"kind":7054,
"content":"<optional human-readable message>",
"tags":[
["session_id","<32-byte hex>"],
["quorum","<Y x-only hex>"],
["threshold","<t'>"],
["old_member","<pk_1>"],
["old_member","<pk_n>"],
["member","<pk_1'>"],
["member","<pk_n'>"]
]
}
```
New member indices are derived by sorting `new_members` lexicographically (1-based), independently of the old index assignment.
Old members signal participation by contributing in Round 1. The contributing set `S`**must be fixed before shares are combined**, because each old member's Lagrange coefficient depends on the full set `S`. Implementations should establish `S` via a timeout or an explicit "I'm participating" acknowledgment step before proceeding to Round 2.
### Round 1 — Old Member Commitments (kind 7055)
Each participating old member Pᵢ (with index `i` from the original DKG and shard `xᵢ`):
1. Computes Lagrange coefficient over contributing set `S` at point 0:
`λᵢ = Πⱼ∈S, j≠i (-j) / (i - j) (mod q)`
2. Samples a new random polynomial `hᵢ(x)` of degree `t'−1` with constant term `hᵢ(0) = λᵢ · xᵢ`
3. Computes commitments: `Dᵢ = [λᵢ·xᵢ·G, …]` (same structure as Round-1 commitments in Protocol 1)
4. The first commitment `Dᵢ[0]` must equal `λᵢ · Yᵢ`, where `Yᵢ` is Pᵢ's verification share from the original DKG (publicly computable from stored Round-1 commitments). This proves Pᵢ is resharing their actual shard.
5. Computes Schnorr PoK of `λᵢ · xᵢ` (same construction as Protocol 1 Round 1, using `"frost/resharing/round1"` as domain tag)
6. Sends to all new members (m gift wraps, identical payload):
```json
{
"kind":7055,
"content":"",
"tags":[
["session_id","<32-byte hex>"],
["quorum","<Y x-only hex>"],
["commit","<λᵢ·xᵢ·G hex>"],
["commit","<bᵢ₁·G hex>"],
["proof","<R hex>","<s hex>"]
]
}
```
New members verify before proceeding: `Σᵢ∈S Dᵢ[0] == Y`. Abort if this check fails.
### Round 2 — Share Distribution (kind 7056)
Each participating old member Pᵢ evaluates `hᵢ(j)` at each new member Qⱼ's index `j` and sends encrypted to Qⱼ only:
```json
{
"kind":7056,
"content":"",
"tags":[
["session_id","<32-byte hex>"],
["quorum","<Y x-only hex>"],
["share","<hᵢ(j) hex scalar>"]
]
}
```
### Finalization
Each new member Qⱼ, after receiving shares from all members of `S`:
1. Verifies each received share against Dᵢ commitments:
4. BIP-340 normalization: `Y` is unchanged, so the same even-y convention applies. If `xᵢ` was negated during the original DKG finalization, `hᵢ(0) = λᵢ · xᵢ` already incorporates that negation. Qⱼ verifies against the same `Y` and does not re-negate.
5. Replaces stored quorum state with `(x'ⱼ, Y, Y'ⱼ, new_members, new_threshold, session_id, Round-1 commitments from this session)`.
Once `t'` new members have published matching confirmations, the rotation is considered complete. The quorum then publishes a signed `kind 0` metadata event under `Y` recording the new member list. This event is the on-chain rotation record and is used to gate NIP-17 chat display by membership at time of message.
---
## Protocol 3: Collaborative Signing (FROST)
Any quorum member may initiate a signing session. At least t members must participate to produce a valid signature.
The coordinator verifies the signature against `Y` and `msg` using standard BIP-340 verification before publishing the event. The resulting signature is a valid BIP-340 Schnorr signature, indistinguishable from a single-key signature.
---
## Storage
Quorum state must be stored durably in IndexedDB per-quorum:
| Field | Description |
|-------|-------------|
| `quorum_pubkey` | `Y` as x-only hex — the quorum's Nostr pubkey |
| `shard` | `xⱼ` — this member's secret share (encrypted at rest) |
| `verification_share` | `Yⱼ` — public verification share for this member |
| `members` | Current member pubkeys and indices |
| `threshold` | Current signing threshold `t` |
| `dkg_commitments` | All participants' Round-1 commitments from the most recent DKG or resharing session |
| `rotation_records` | All signed rotation `kind 0` events in order |
`dkg_commitments` are retained permanently because they are required to verify shard authenticity during resharing (step 4 of Protocol 2 Round 1).
`rotation_records` are used to determine which members were active at a given time, which gates NIP-17 chat message display.
---
## Security Notes
**Equivocation**: A malicious participant can send different Round-1 commitments to different members, causing different members to derive different group keys. The `transcript_hash` in confirmation events provides detection. Implementations must abort if any two confirmations for the same session have different hashes.
**Abort and restart**: If any participant fails to complete their round within a timeout, the session must be fully aborted. Partial state (nonces, sub-shares) must be discarded. A new session with a new `session_id` must be started from Phase 0.
**Nonce reuse in signing**: Reusing `(dᵢ, eᵢ)` across two signing sessions leaks the shard `xᵢ`. Implementations must use fresh randomness for every session and must not persist signing nonces.
**Contributing set integrity**: In Protocol 2, the Lagrange coefficients and the integrity check `Σ Dᵢ[0] == Y` are only meaningful over the same set `S`. The set must be fixed and agreed upon before shares are combined. Any late-joining or aborting member after `S` is finalized requires a full session restart.
**BIP-340 y-coordinate normalization**: Nostr uses x-only public keys. Both the group key `Y` (finalized in DKG) and the signing nonce `R` (per signing session) require even-y normalization, which affects the sign of `xⱼ` and `(dᵢ, eᵢ)` respectively. These negations are independent and must both be applied correctly.
@@ -16,29 +16,11 @@ Rotating membership is a special case of signing an event; this option opens a f
The sign event button opens a modal/drawer which asks the user to choose which event kind: public note (kind 1), relay selections (kind 10002), profile (kind 0).
Use solidjs/tailwind/preline and applesauce for nostr functionality. Use toast for error messages, not inline errors.
Use solidjs/tailwind/preline and applesauce for nostr functionality. Use `@noble/curves` for FROST cryptographic primitives (DKG, Feldman VSS, threshold signing) and `@noble/hashes` for hash functions. Use toast for error messages, not inline errors.
# Protocol
A quorum is a standard FROST multisig over a nostr key.
## Creating a quorum
When creating a quorum, the initiating user creates a `kind 7050` payload with the following fields:
- members: a list of quorum member hex nostr pubkeys
- threshold: proposed threshold for signing
- message: a message for all invitees
- events: a list of events to sign
- [key material]
This is wrapped and sent to all members using kind 1059 (NIP 59) with t=encrypt(quorum pubkey, recipient).
## Rotating keys
## Collaborative signing
When signing collaboratively, a round-robin-style FROST multisig signing round takes place in which the initiator sends a .
See [PROTOCOL.md](PROTOCOL.md) for the full protocol specification.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Jon Staab