FROST Signing Rounds in Spark: How Threshold Signatures Enable Instant Bitcoin Transfers

Every Spark transfer is, at its core, a FROST signing round. When ownership of Bitcoin moves from one user to another on Spark, no transaction hits the blockchain. Instead, the user and the Spark operators execute a two-round cryptographic protocol that rotates key shares, invalidates the previous owner's signing capability, and produces a standard Schnorr signature that looks identical to any single-key Taproot spend. This article examines the mechanics of those signing rounds: how nonce commitments flow, how partial signatures aggregate, and why the protocol achieves sub-second settlement without sacrificing self-custody.

Why Signing Round Performance Matters

In a statechain-based system like Spark, every state transition requires cooperative signing between the user and the operator set. Unlike Lightning, where payments route through pre-established payment channels and settle via HTLCs, Spark transfers are direct key rotations. The latency of a Spark transfer is therefore bounded by the time it takes to complete a FROST signing round, plus the overhead of coordinating the key share rotation across operators.

This makes the signing protocol the critical path. Every optimization to round count, nonce generation, or partial signature aggregation translates directly into faster transfers. The design choices in RFC 9591 (the FROST specification, published June 2024 by the IETF's Crypto Forum Research Group) were made with exactly this kind of application in mind: spreading trust across multiple parties while keeping signing fast enough for interactive use.

The Two-Round Signing Protocol

FROST signing consists of two communication rounds between a set of t-of-n signers, coordinated by a designated aggregator. In Spark's architecture, the user holds one key and the Spark Entity (a set of independent operators) collectively holds the other via threshold signing. The operator-side key is itself a FROST key, meaning multiple operators must participate to produce the operator's half of the signature.

Round 1: Nonce Commitment

Each participating signer generates a pair of cryptographic nonces: two random scalar values drawn from the secp256k1 curve's scalar field. The signer computes elliptic curve point commitments for each nonce and broadcasts these commitments to the coordinator. This round is message-independent: signers do not need to know what they will be signing when they generate nonces.

The coordinator collects commitments from a threshold number of signers and distributes the full commitment list back to all participants. At this point, each signer can verify that the set of commitments is consistent and that the coordinator has not tampered with any values.

Nonce reuse is catastrophic: If a signer ever reuses a nonce across two different signing sessions, an attacker can extract that signer's key share through simple algebra. This is not a theoretical concern: it is the same class of vulnerability that allowed the PlayStation 3 ECDSA key extraction in 2010. FROST implementations must generate fresh nonces for every signing session.

Round 2: Partial Signature Generation

Once each signer has the full set of nonce commitments, they compute a binding factor that ties the commitments to the specific message being signed. Each signer then computes a group nonce by combining all individual commitments (weighted by the binding factor) and produces a partial signature using their own key share, their nonces, the group nonce, the message hash, and a Lagrange interpolation coefficient that accounts for the specific subset of signers participating in this session.

These partial signatures are sent to the coordinator, who sums them into a single aggregate signature. The result is a standard 64-byte BIP-340 Schnorr signature that is indistinguishable from one produced by a single private key. An on-chain verifier cannot tell whether the signature came from one party or one hundred.

Verification

Before publishing the aggregate signature, the coordinator (and any participant) can verify it against the group public key using standard Schnorr verification. If any signer contributed a malformed partial signature, the aggregate will fail verification. FROST provides identifiable aborts: the coordinator can check each partial signature individually against its corresponding commitment to identify and exclude the misbehaving party, then restart the round with the remaining honest signers.

Nonce Preprocessing: From Two Rounds to One

The original FROST paper by Komlo and Goldberg describes an optimization that reduces interactive signing to a single round. Each signer pre-generates a batch of nonce pairs and publishes the commitments ahead of time. When a signing request arrives, the coordinator selects the next unused commitment from each participant's list, assigns them to the session, and proceeds directly to Round 2.

This approach is particularly relevant for Spark operators, who participate in many signing sessions. By maintaining a buffer of pre-computed nonce commitments, operators can respond to signing requests in a single message exchange. The tradeoff is storage and bookkeeping: each pre-computed nonce must be used exactly once, and the mapping between commitments and nonces must survive crashes without risking reuse.

Implementation note: RFC 9591 specifies only the two-round protocol and explicitly places single-round signing out of scope. Implementations that use nonce preprocessing must handle the additional state management and crash-recovery logic themselves, which is where most real-world bugs surface.

How Spark Uses FROST for Transfers

A Spark transfer is a key rotation: the process of changing which key share pair can authorize spending a UTXO without moving the UTXO itself. The signing round is not producing a Bitcoin transaction to broadcast. It is producing the cryptographic material that proves the new owner and the operator set jointly control the funds.

The Transfer Flow

1. Alice initiates a transfer to Bob through the Spark SDK. The SDK contacts the Spark Entity to begin a key rotation.
2. The Spark operators generate a new key share for Bob. The operators adjust (tweak) their own aggregate key share so that the combined public key remains the same, but the private key is now split between Bob and the operator set rather than Alice and the operator set.
3. Alice, Bob, and the operators execute a FROST signing round to produce a pre-signed exit transaction for Bob. This transaction lets Bob unilaterally withdraw to Bitcoin L1 if the operators ever become unavailable.
4. The operators delete Alice's old key share. After deletion, Alice's portion of the private key is cryptographically useless: she cannot combine it with the operators' new share to produce a valid signature.
5. The transfer is complete. Bob now holds a key share that, combined with the operators' share, authorizes spending the on-chain UTXO.

The critical observation is that steps 2 and 3 involve FROST signing rounds among the operator set. The operators must reach internal consensus on the key rotation and co-sign the exit transaction using their threshold key. The latency of the entire transfer is dominated by these signing rounds.

Why Key Deletion Makes This Work

The security of the statechain model depends on operators actually deleting old key shares after each transfer. This is an operational guarantee, not a cryptographic one: there is no way to prove that a private key has been destroyed. Spark mitigates this with its 1-of-n trust model. The operator set uses FROST so that no single operator holds the complete operator-side key. As long as at least one operator honestly deletes its share, the old key cannot be reconstructed. For a deeper treatment of this trust model, see the statechains deep dive.

Performance Characteristics

FROST's performance depends on three factors: the computational cost of elliptic curve operations, the number of communication rounds, and the size of the signing group. For Spark, the relevant configuration is a small threshold (currently a few operators) with the user as a separate co-signer.

Computational Cost

The dominant operations in a FROST signing round are elliptic curve scalar multiplications and additions on the secp256k1 curve. Each signer performs one multi-scalar multiplication to compute the group nonce, one scalar multiplication for their partial signature, and a handful of hash operations. On modern hardware, a single scalar multiplication on secp256k1 takes on the order of tens of microseconds. The Arch Network project, which uses FROST/ROAST for validator consensus, reported P99 threshold signing latency of 87 milliseconds with 75 validators: a figure that includes network coordination overhead, not just cryptographic computation.

For Spark's current operator set (a small number of operators), the cryptographic computation per signing round is negligible compared to network latency. The bottleneck is the time it takes for messages to travel between the user's device, the coordinator, and the operator nodes.

Network Latency

In the standard two-round protocol, a signing session requires two network round-trips between each signer and the coordinator. With nonce preprocessing, this drops to one. For geographically distributed operators, each round-trip might add 50 to 150 milliseconds depending on network conditions. Spark claims sub-second finality for transfers, which aligns with the expected latency of one to two FROST rounds plus the overhead of key share rotation and exit transaction construction.

Parallelism and Throughput

FROST supports concurrent signing sessions. Multiple transfers can proceed simultaneously, each using independent nonce commitments. The original FROST paper specifically addresses this: earlier Schnorr threshold constructions that limited concurrency needed at least three rounds, while FROST achieves two rounds (or one with preprocessing) without restricting the number of concurrent sessions.

For Spark operators, this means throughput scales with the number of concurrent sessions the infrastructure can handle, not with the signing protocol itself. Each session is independent: one slow or failed session does not block others. The limit is operational (server capacity, database writes for nonce tracking) rather than cryptographic.

FROST vs MuSig2: Why Spark Chose Threshold Signing

MuSig2 is a related Schnorr-based multi-signature protocol, standardized as BIP-327. Both FROST and MuSig2 produce standard 64-byte BIP-340 Schnorr signatures and both use two signing rounds. The key difference is the participation requirement: MuSig2 is an n-of-n scheme where every signer must participate, while FROST is t-of-n where any threshold subset suffices.

For Spark, the threshold property is essential. The operator set must be able to sign even if one operator is temporarily offline. With MuSig2, a single unresponsive operator would halt all transfers across the entire network. FROST's fault tolerance means the system degrades gracefully: transfers continue as long as a threshold of operators remains available.

The MuSig2 Liveness Problem

Consider a 5-of-5 MuSig2 configuration where all five operators must participate in every signing session. If one operator goes down for maintenance, experiences a network partition, or is subject to a denial of service, the entire system stops producing signatures. Funds are not at risk (the UTXO still exists on-chain), but no transfers can proceed until all operators recover.

FROST with a 3-of-5 threshold, by contrast, can continue operating with any three operators online. This distinction is particularly important for a system like Spark where operators are expected to be geographically distributed across jurisdictions, making synchronized uptime more difficult to guarantee.

ROAST: Robustness Under Adversarial Conditions

While FROST provides identifiable aborts (a misbehaving signer can be detected and excluded), it does not guarantee that honest signers will always succeed when adversarial participants actively disrupt sessions in asynchronous networks. ROAST (Robust Asynchronous Schnorr Threshold Signatures), published at ACM CCS 2022 by Ruffing, Ronge, Jin, Schneider-Bensch, and Schröder, addresses this gap.

ROAST wraps FROST (or any semi-interactive threshold signing scheme with identifiable aborts) in a coordination layer that runs multiple signing sessions in parallel. A disruptive signer can stall at most one session. The coordinator tracks which signers responded honestly in each session and reassigns them to new sessions, guaranteeing that a quorum of honest signers eventually completes a valid signature regardless of network delays or adversarial behavior.

For Spark operators, ROAST provides an additional layer of resilience. Even if an operator intermittently fails to respond (due to network issues, not malice), the system can route around the failure without manual intervention. The key insight is that ROAST does not change the underlying cryptography: the output is still a standard Schnorr signature produced by FROST. ROAST only changes the coordination strategy.

Distributed Key Generation: The Setup Phase

Before any FROST signing can happen, the operator set must run a distributed key generation (DKG) ceremony to create the shared key without any single party ever knowing the complete private key. FROST's DKG builds on Pedersen's verifiable secret sharing, where each participant generates a random polynomial of degree t-1, evaluates it at each other participant's index, and distributes the resulting shares. Feldman's verification scheme lets each recipient verify their share against public commitments without revealing any secrets.

The DKG is a one-time setup cost per key. Once the key shares are distributed, the operators can sign an unlimited number of messages without repeating the ceremony. For Spark, a DKG runs when a new operator joins the set or when the key shares are refreshed for security (proactive secret sharing). The ChillDKG proposal (by Ruffing and Nick, posted to the Bitcoin-Dev mailing list in July 2024) aims to standardize a simplified DKG specifically for FROST on Bitcoin, with backup recovery from a device seed plus public data shared across participants.

DKG vs signing performance: The DKG ceremony is more expensive than individual signing rounds (it involves multiple rounds of communication and polynomial evaluation). But because it runs once per key rather than once per transfer, its cost is amortized across all subsequent signing sessions. For a deeper treatment of DKG mechanics, see the FROST threshold signatures article.

Security Properties of the Signing Round

FROST's security proof, given in the original Komlo and Goldberg paper, demonstrates unforgeability under chosen-message attacks in the random oracle model, assuming the discrete logarithm problem is hard on the underlying curve and the adversary controls fewer than t participants. Several properties are worth highlighting for developers building on Spark.

Binding Commitments

The binding factor computed in Round 2 ties each signer's nonce commitment to the full set of commitments and the message being signed. This prevents a class of attack where a malicious coordinator substitutes commitments between Rounds 1 and 2 to manipulate the group nonce in a way that leaks honest signers' key shares. Without binding, a rogue coordinator could run parallel sessions with different commitment sets and extract key shares through algebraic relationships between the resulting partial signatures.

Identifiable Aborts

If a partial signature fails verification, the coordinator can identify the faulty signer by checking each partial signature against its corresponding commitment. This is stronger than simply detecting that something went wrong: it allows the honest participants to exclude the bad actor and retry with the remaining signers (assuming enough honest signers remain to meet the threshold). For Spark, this means a single misbehaving operator cannot disrupt the network indefinitely.

Forward Security

In Spark's statechain model, each transfer produces new key shares and destroys old ones. This gives the system a form of perfect forward security: even if an operator is compromised after a transfer, the attacker gains no ability to reverse or forge the previous transfer. The old key shares are gone, and the new signing sessions use entirely independent nonces and key material.

Implementation Landscape

Several production-quality FROST implementations exist, targeting different curves and use cases.

A critical implementation detail for Bitcoin developers: the standard frost-secp256k1 Rust crate is not compatible with BIP-340 Taproot signatures. The frost-secp256k1-tr crate must be used instead. This is because BIP-340 uses x-only public keys and a specific tagged hash scheme that differs from the generic Schnorr construction. Choosing the wrong crate will produce signatures that verify in tests but fail on the Bitcoin network.

What Developers Need to Know

For developers building on Spark, the Spark SDK abstracts the FROST protocol behind a high-level interface. The SparkWallet class exposes methods like transfer() and getBalance() that internally handle the signing round coordination, nonce management, and key rotation. Developers do not need to implement FROST themselves.

However, understanding the protocol helps developers make better architectural decisions:

• Transfer latency is network-bound, not compute-bound. Deploying application servers closer to Spark operators reduces round-trip time.
• Each transfer involves multiple signing rounds (key rotation plus exit transaction signing). Batching transfers when possible reduces total round-trip overhead.
• The SparkSigner interface supports custom key management backends: hardware wallets, HSMs, or MPC solutions can plug into the signing flow without modifying the transfer logic.
• Nonce management is handled by the SDK. Developers should not cache or persist nonce state outside the SDK's own storage, as this risks nonce reuse.

The Spark documentation provides integration guides, signing specifications, and SDK references for building wallets and payment applications. For a practical walkthrough, see the SDK integration guide.

Signing Rounds in Context

FROST signing rounds are not unique to Spark. The same protocol is being adopted across the Bitcoin ecosystem wherever distributed key management is needed: custody solutions using threshold wallets, federated sidechains coordinating peg-outs, and protocols like MPC custody systems that are migrating from ECDSA-based threshold schemes to Schnorr-based ones for lower round complexity and smaller signatures.

What makes Spark's use distinctive is that FROST is on the critical path of every user-facing operation. In a custody solution, signing happens occasionally (when funds move). In Spark, signing happens on every transfer, making protocol-level optimizations like nonce preprocessing and ROAST-style coordination directly visible in the user experience. The sub-second settlement that Spark achieves is a direct consequence of FROST's two-round design combined with a small, well-connected operator set.

Open Questions and Future Work

Several areas of active research could further improve signing round performance and security in Spark and similar systems:

• Accountable FROST would allow public verification of which signers participated in a given signature, useful for audit trails without sacrificing on-chain privacy.
• Weighted thresholds would let different operators have different signing weights, reflecting varying levels of trust or stake.
• Integration with PTLCs (point time-locked contracts) via adaptor signatures could enable atomic cross-protocol swaps with tighter integration than the current Lightning bridge.
• Post-quantum considerations: Schnorr signatures (and by extension FROST) are vulnerable to quantum computers via Shor's algorithm. Research into lattice-based threshold signatures is ongoing but not yet practical for Bitcoin.

Conclusion

FROST signing rounds are the engine that makes Spark work. Every transfer, every key rotation, every pre-signed exit transaction flows through the same two-round protocol: generate nonces, commit, compute partial signatures, aggregate. The protocol is simple in structure but careful in design, with binding factors preventing commitment manipulation, identifiable aborts enabling fault tolerance, and nonce preprocessing reducing latency for high-throughput operators.

For developers building Bitcoin applications that need instant, self-custodial transfers, understanding the signing round is understanding the fundamental operation that makes Spark possible. The Spark SDK and documentation provide the tools to build on this foundation without implementing the cryptography from scratch.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.