DA-04 · LESSON 02

FROST signing rounds

KEY DEFINITIONS

Terms used in this lesson

FROST: Flexible Round-Optimized Schnorr Threshold signing: a protocol in which a required subset produces one group signature.
Guardian: A Ducat policy-checking signer that can authorize or reject defined protocol transactions.
BIP340: The Bitcoin Improvement Proposal specifying Schnorr signatures for the secp256k1 curve.
Schnorr signature: Bitcoin’s Taproot signature scheme, whose algebra supports compact verification and advanced multi-party signing.

Guardians exchange nonce commitments and signature shares so a threshold subset produces one BIP340-compatible group signature.

45 min Difficulty 4/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · ducat vaultA Ducat action moves one Bitcoin-anchored vault state to a successorSelect any state to inspect its exact role.

RELATIONSHIP MAPInputs, rule, and outputs

01
PREDECESSORCurrent vault outpoint
The current Bitcoin output anchors collateral and identifies the state being spent.
02
REQUESTFROST signing rounds
The FROST signing rounds workflow proposes one exact action and successor state.
03
POLICYProfile, oracle, signatures
Applicable policy, price evidence, authorization, and transaction shape are checked.
04
BITCOIN SPENDScript-valid transaction
Bitcoin miners and nodes can include only a transaction that satisfies Bitcoin rules.
05
SUCCESSORNew outpoint and state
Ducat validators reconstruct debt, collateral, token, and account changes from the confirmed transaction.

Rule shown: Bitcoin checks the spend; Ducat components independently reconstruct and validate the additional protocol state.

STAGE 1 OF 5PREDECESSOR: Current vault outpoint

The current Bitcoin output anchors collateral and identifies the state being spent.

Governing relationship: Bitcoin checks the spend; Ducat components independently reconstruct and validate the additional protocol state. Complete path: 1. PREDECESSOR, Current vault outpoint. The current Bitcoin output anchors collateral and identifies the state being spent. 2. REQUEST, FROST signing rounds. The FROST signing rounds workflow proposes one exact action and successor state. 3. POLICY, Profile, oracle, signatures. Applicable policy, price evidence, authorization, and transaction shape are checked. 4. BITCOIN SPEND, Script-valid transaction. Bitcoin miners and nodes can include only a transaction that satisfies Bitcoin rules. 5. SUCCESSOR, New outpoint and state. Ducat validators reconstruct debt, collateral, token, and account changes from the confirmed transaction.

1. State transitionWhat exists, what changes, and what results

BEFORE

Guardians B and D approve transaction hash Q under group public key H while A and C are offline. This example uses symbolic equations; required practice supplies a different…

MECHANISM

Each participating Guardian should first decide that the exact Ducat transaction and policy context are valid. Threshold cryptography does not replace policy validation.

AFTER

Bitcoin sees one signature. Off-chain policy and transcript verification prevent a coordinator from converting threshold availability into authority over an unapproved transa…

Text equivalent: Starting from Guardians B and D approve transaction hash Q under group public key H while A and C are offline. This example uses symbolic equations; required practice supplies a different modulo-101 numeric vector. Production FROST u… The mechanism begins when Each participating Guardian should first decide that the exact Ducat transaction and policy context are valid. Threshold cryptography does not replace policy validation. The resulting lesson is Bitcoin sees one signature. Off-chain policy and transcript verification prevent a coordinator from converting threshold availability into authority over an unapproved transaction; the numeric practice remains explicitl…

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Validate the request independently

Each participating Guardian should first decide that the exact Ducat transaction and policy context are valid. Threshold cryptography does not replace policy validation.

Complete path: 1. Validate the request independently: Each participating Guardian should first decide that the exact Ducat transaction and policy context are valid. Threshold cryptography does not replace policy validation. 2. Round one: commit nonces: Each signer creates fresh secret nonces and shares public nonce commitments. Binding the round prevents nonce substitution and replay. 3. Round two: create signature shares: After receiving the signing package, each Guardian recomputes the message and participant set. In the displayed formula z_i = r_i + lambda_i times s_i times c, z_i is participant i's signature share, r_i is its package-bound nonce contribution, lambda_i is its participant coefficient, s_i is its secret key share, and c is the BIP340 challenge. 4. Verify and aggregate: Shares are checked and combined into one BIP340-compatible Schnorr signature that Bitcoin verifies against the group public key.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

Every honest Guardian first approves the exact transaction and policy, then binds a fresh nonce commitment and signature share to one message, ordered signing subset, commitment list, group key, and challenge; every share verifies before aggregation.

CHANGED CONDITION

Message or participant substitution, a reused or duplicate nonce commitment, malformed scalar or point, insufficient quorum, or one invalid share aborts aggregation. Aborted secret nonce state must never be reused.

Important distinction: The coordinator reconstructs the private key from the signature shares. It aggregates signature shares, not secret-key shares. A correctly implemented FROST round never reconstructs the group private key.

Text equivalent: The accepted path is enforced by Every honest Guardian first approves the exact transaction and policy, then binds a fresh nonce commitment and signature share to one message, ordered signing subset, commitment list, group key, and challenge; every share verifies before aggregation. If the required condition changes, Message or participant substitution, a reused or duplicate nonce commitment, malformed scalar or point, insufficient quorum, or one invalid share aborts aggregation. Aborted secret nonce state must never be reused.

Loading lesson visuals...

Learn the idea

FROST lets a threshold subset of Guardians produce one Schnorr signature under a shared group public key. No participant needs to reconstruct the complete private key during signing. A binding factor is a hash-derived number tying one signer's public nonce commitment to the exact message, participant set, and commitment list. An aggregate nonce combines those bound commitments. A participant coefficient weights one participant's long-term key share for the selected signing subset. The BIP340 challenge is the hash-derived value binding the aggregate nonce, group public key, and transaction message.

GUIDED EXPLANATION1/4 ideas inspected

Validate the request independently

Each participating Guardian should first decide that the exact Ducat transaction and policy context are valid. Threshold cryptography does not replace policy validation.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“The coordinator reconstructs the private key from the signature shares.”

It aggregates signature shares, not secret-key shares. A correctly implemented FROST round never reconstructs the group private key.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.