# Arch’s Signature Scheme Model (FROST + ROAST)

Various signature schemes have been proposed to add to Bitcoin the same type of smart contract functionalities seen on blockchains like Ethereum and Solana, each with various pros and cons. Scripted multisigs — including P2MS (Pay-to-Multisig) and Tapscript multisigs — offer high security. However, they offer little privacy because all data is stored publicly on-chain, which also leads to them having high transaction fees and network bloat as a result. Scriptless multisigs, such as MuSig, are able to make transactions secure while putting less data on-chain. However, these protocols rely on all signers being honest and cooperative during the signing process. If even one participant behaves maliciously or provides incorrect data, the protocol fails to produce a valid signature, leading to potential delays or failures in completing execution of a transaction. In most cases, this makes them unsuitable for real-world application.

Some Bitcoin L2s, including Stacks and Botanix have tried to address this problem by using the FROST (Flexible Round-Optimized Schnorr Threshold) signature scheme. Unlike MuSig, this protocol allows transactions to go through so long as they can get a threshold of signers to participate and be responsive. This model offers significant security while also reducing gas fees and higher execution rates. However, its major weakness is that it can’t guarantee robustness. Networks must be able to guarantee that they’ll have a signature signed within a certain time range, but networks that rely on FROST alone can be prone to failure, leading to temporary disruptions or pauses in network activity.

Arch is unique in that it uses FROST, but adds on top of it a communication protocol called ROAST (Robust Asynchronous Schnorr Threshold Signatures). In a typical FROST transaction, a subset of signers is chosen, and the entire transaction fails if one node doesn’t behave correctly. ROAST coordinates with the various nodes to make such failure significantly less likely. This allows Arch to guarantee robustness by ensuring that a signature can be signed so long as just 51% of the network is honest and cooperative. 

***This multisig structure makes it possible to implement the rest of the Arch platform architecture and enable programmability on the Bitcoin base layer.***

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://arch-network.gitbook.io/arch-documentation/fundamentals/introducing-arch/archs-signature-scheme-model-frost-+-roast.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.