ROAST (Robust Asynchronous Schnorr Threshold Signatures)

A wrapper protocol around FROST that guarantees signature completion even when some signers are unresponsive or malicious.

Key Takeaways

ROAST is a wrapper around FROST that guarantees a valid threshold signature can always be produced, even when some signers are offline, slow, or actively malicious.
The protocol works by running multiple FROST signing sessions in parallel through a coordinator: each disruptive signer can stall at most one session, so an honest quorum eventually completes a session containing only cooperative participants.
ROAST solves the liveness problem that vanilla FROST faces in adversarial or high-latency network environments, making it critical for federated systems like Bitcoin sidechains and statechain operators.

What Is ROAST?

ROAST (Robust Asynchronous Schnorr Threshold Signatures) is a protocol that wraps an existing threshold signing scheme to provide robustness guarantees in adversarial and asynchronous network conditions. It was introduced in a 2022 paper by Tim Ruffing, Viktoria Ronge, Elliott Jin, Jonas Schneider-Bensch, and Dominique Schröder, and was published at ACM CCS 2022. The primary application of ROAST is wrapping FROST to produce a practical, robust Schnorr threshold signature scheme for Bitcoin.

ROAST is not a new signature scheme: it does not modify how Schnorr signatures are computed or verified. Instead, it manages how signing sessions are coordinated so that a t-of-n quorum of honest signers can always produce a valid signature, regardless of network latency or the behavior of up to n minus t malicious participants.

Why FROST Alone Can Stall

FROST is a two-round threshold signing protocol. In the first round (preprocessing), each selected signer generates and shares a nonce commitment. In the second round (signing), each signer produces a partial signature share using their key share and the aggregated nonces. The coordinator collects these shares and combines them into a single valid Schnorr signature.

The vulnerability lies in what happens between rounds. A malicious signer can participate honestly in Round 1 (sharing a valid nonce commitment) but then refuse to respond in Round 2. This is particularly damaging because the other signers have already committed their nonces to a session that now cannot complete. Since nonces must not be reused across sessions (reuse would leak the signer's private key share), those nonces are wasted. The coordinator must start an entirely new session with fresh nonces and a different signer set.

A single disruptive signer can repeat this attack indefinitely, stalling every signing attempt. In a 7-of-13 configuration, for example, if even one malicious signer is included in each selected group of 7, they can prevent any signature from ever being produced. FROST provides identifiable aborts (the coordinator can detect which signer failed), but detection alone does not guarantee progress.

How ROAST Works

ROAST solves this by running multiple FROST sessions concurrently through a coordinator. The core insight is simple: if each disruptive signer can block at most one session at a time, and there are at most n minus t disruptive signers, then starting enough sessions guarantees that at least one session will contain only honest, responsive signers.

The Coordinator Algorithm

The coordinator maintains a list of "responsive" signers: those who have responded to a previous request and are currently available for a new session. When the list reaches the threshold t, the coordinator initiates a new FROST session with those t signers:

The coordinator starts with all n signers marked as responsive and initiates the first FROST session with any t of them
Each selected signer receives the session request and replies with their nonce commitment (Round 1) followed by their signature share (Round 2)
When a signer responds, the coordinator processes their reply. If the response is valid, the signer is added back to the responsive list. If the signer sent an invalid share, the coordinator identifies and excludes them (identifiable abort)
Whenever the responsive list reaches t signers, the coordinator immediately starts a new parallel FROST session with those signers, removing them from the responsive list
The first session to collect t valid signature shares completes: the coordinator combines them into the final Schnorr signature and terminates all remaining sessions

Why This Guarantees Liveness

The guarantee follows from a counting argument. There are at most n minus t malicious signers. Each malicious signer can stall at most one session at a time (by not responding in Round 2). So at most n minus t sessions can be stalled simultaneously. Since there are at least t honest signers who always respond, the coordinator will eventually accumulate t responsive signers for a session that contains no malicious participants. That session completes successfully.

This holds regardless of network latency. Even if honest signers' messages are delayed arbitrarily, the coordinator simply waits. It never times out or gives up. The protocol makes progress whenever messages are eventually delivered, which is the definition of an asynchronous network model.

Requirements on the Underlying Scheme

ROAST is not specific to FROST. It can wrap any threshold signing scheme that satisfies three properties:

Semi-interactive: the scheme has one preprocessing round and one signing round (two rounds total)
Identifiable aborts: if a signing session fails, the coordinator can identify at least one misbehaving signer responsible for the failure
Unforgeable under concurrent sessions: running multiple signing sessions simultaneously does not compromise the security of the threshold signature scheme

FROST satisfies all three, making the combination of ROAST and FROST a practical and provably secure Schnorr threshold signing protocol.

ROAST vs. Simple Retry

A naive approach to handling FROST failures is to simply retry with a different signer set after detecting a failure. This sequential retry strategy has a critical weakness: a malicious signer can participate in Round 1, wait until the very end of Round 2's timeout, and then refuse to sign. Each failed attempt wastes an entire timeout period, and the attacker can keep being selected for new sessions.

ROAST improves on this in two ways. First, sessions run in parallel rather than sequentially, so a stalled session does not block progress elsewhere. Second, a signer who is currently participating in a session is removed from the responsive pool and cannot be assigned to another session until they respond. This means each malicious signer can only tie up one session at a time, bounding the total disruption.

Approach	Sessions	Worst-Case Delay	Liveness Guarantee
Sequential retry	One at a time	Unbounded (attacker stalls each)	None
ROAST	Parallel	Bounded by honest signer response time	Guaranteed with t honest signers

Use Cases

Federated Sidechains

Blockstream's Liquid Network uses a federation of functionaries to manage a multisig wallet securing the sidechain's Bitcoin peg. ROAST was developed in the context of upgrading this federation from script-based multisig to threshold signatures. With ROAST, the federation could potentially scale to hundreds of signers while maintaining the guarantee that honest quorums always produce valid signatures, even if some functionaries go offline or act maliciously.

Statechain Operators

In statechain-based protocols, a statechain entity co-signs transactions with users to enable off-chain Bitcoin transfers. When the statechain entity is operated by a federation of nodes using FROST threshold signing, ROAST ensures that the entity remains available to process transfers even if individual operator nodes fail. This is directly relevant to systems like Spark, where the operator collective must remain responsive to co-sign user transactions.

Distributed Key Management

Any organization using distributed key generation and threshold signing for custody (corporate treasuries, DAOs, institutional custodians) benefits from ROAST when signer availability cannot be guaranteed. Hardware failures, network outages, and even insider threats are handled gracefully as long as a threshold of honest signers remains reachable.

Cross-Chain Bridges

Bridge protocols that use threshold signatures to authorize cross-chain asset transfers face the same liveness challenge. A bridge committee using FROST alone risks being unable to process withdrawals if a committee member goes offline at the wrong time. ROAST eliminates this risk for bridges built on Schnorr-compatible chains.

Performance Characteristics

The ROAST paper includes benchmarks of a 67-of-100 configuration with the coordinator and signers distributed across different continents. Even with 33 malicious signers (the maximum allowed), the 67 honest signers produced a valid signature within seconds. The overhead compared to a single successful FROST session is modest: the coordinator manages multiple session states, and some nonces are wasted on failed sessions, but no expensive cryptographic operations are added beyond what FROST already requires.

The trade-off is that ROAST may start sessions that turn out to be redundant (because another session completes first). These redundant sessions consume signer bandwidth and nonce material. In practice, this cost is negligible compared to the liveness guarantee it provides.

Coordinator Role

The coordinator in ROAST is semi-trusted. It cannot forge signatures or compromise the security of the threshold scheme: even a malicious coordinator cannot produce a valid signature without t legitimate key shares. However, the coordinator is trusted for liveness: a malicious coordinator could refuse to start new sessions or forward messages, stalling the protocol. In practice, the coordinator role can be rotated or replicated to mitigate this risk.

Risks and Considerations

Research Maturity

While the ROAST paper has been peer-reviewed and published at ACM CCS 2022, production implementations remain limited. Most available code (such as proof-of-concept repositories) carries warnings against production use. Organizations considering ROAST should evaluate the maturity of implementations carefully and conduct independent audits before deployment.

Nonce Waste

Failed sessions consume nonces that cannot be reused. In adversarial conditions with many malicious signers, the honest signers may need to generate substantially more nonces than in a cooperative scenario. For most threshold configurations this overhead is acceptable, but it grows with the number of malicious participants.

Coordinator Centralization

ROAST assumes a single coordinator managing all sessions. While the coordinator cannot compromise signature security, a permanently offline coordinator halts signing entirely. Decentralizing the coordinator role or implementing failover adds complexity not addressed by the base ROAST protocol.

Complexity Budget

Adding ROAST on top of FROST increases the total system complexity. The coordinator must track multiple concurrent sessions, manage the responsive signer list, handle identifiable abort logic, and terminate redundant sessions upon completion. This additional state management introduces potential implementation bugs, particularly around edge cases like simultaneous session completions.