> For the complete documentation index, see [llms.txt](https://docs.bitsafe.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bitsafe.finance/cbtc/concepts-and-reference/attestor-network-and-frost.md). # Attestor Network and FROST [CBTC architecture and trust boundaries](/cbtc/concepts-and-reference/architecture-and-trust-boundaries.md) ### Attestor Network The Attestor Network is the set of independent institutional operators that verify eligible Bitcoin events and participate in threshold authorization for CBTC custody workflows. Operator membership and signing policy can change, so check the maintained security reference for current operating details. ### What FROST does FROST is a threshold Schnorr signing protocol. Signing authority is distributed across key shares. A configured threshold of participants cooperates to produce one valid signature without reconstructing the complete private key in one place. A threshold signature appears as a standard Schnorr signature to Bitcoin verifiers. The security benefit comes from how the signing capability is distributed and operated, not from a special transaction type. ### What FROST does not do FROST does not by itself: * Verify that a deposit or redemption request is valid. * Decide which Bitcoin transaction should be signed. * Protect a compromised operator application from approving bad input. * Guarantee service availability. * Replace monitoring, policy, access control, or incident response. ### Workflow boundary 1. The system identifies an eligible Bitcoin or redemption event. 2. Operators independently receive the approved signing context. 3. Each participant applies the current verification and authorization policy. 4. The required threshold contributes valid signing material. 5. The protocol produces a Bitcoin-valid signature. 6. The signed transaction or authorization result proceeds through the workflow. ### Key lifecycle The key lifecycle includes generation, share distribution, storage, backup, rotation, participant replacement, lost-share response, and decommissioning. Rotation and membership changes follow coordinated production procedures and may require a maintenance window. ### Availability and failure The network can continue only while enough eligible participants and required services are available under the active policy. One unavailable operator does not necessarily stop the network. Check the current service reference for applicable availability targets. ### Operator trust boundary Each operator must protect its infrastructure, credentials, key share, software supply chain, and verification process. Independent operation reduces unilateral control. It does not remove the need to evaluate correlated failures or common software dependencies. ### Related pages * [CBTC architecture and trust boundaries](/cbtc/concepts-and-reference/architecture-and-trust-boundaries.md) * [CBTC Proof of Reserve](/cbtc/concepts-and-reference/proof-of-reserve.md) * [CBTC security](/cbtc/concepts-and-reference/security.md) ### Next step 👉 **Review the complete control model:** [CBTC security](/cbtc/concepts-and-reference/security.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.bitsafe.finance/cbtc/concepts-and-reference/attestor-network-and-frost.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.