# Security Deep Dive *** ## Overview CBTC's security model is built on three pillars: **FROST threshold signatures** on the Bitcoin side, a **decentralised Attestor Network** bridging both chains, and **Daml smart contracts** governing all operations on Canton. This page covers each in detail. *** ## FROST Threshold Signatures CBTC uses **FROST** (Flexible Round-Optimised Schnorr Threshold Signatures), a cryptographic protocol formalised in [Komlo & Goldberg, 2020](https://eprint.iacr.org/2020/852) and enabled on Bitcoin via the **Taproot** upgrade. ### How FROST Works FROST is a **two-round signing protocol:** 1. **Round One (Commitment):** The Coordinator selects the message to be signed and the set of participating Attestors. Each Attestor generates fresh nonces and public commitments, sent to the Coordinator. 2. **Round Two (Signature Share):** The Coordinator broadcasts all commitments. Each Attestor verifies them, computes an individual signature share, and sends it back. The Coordinator aggregates shares into a single valid Schnorr signature. ### Why FROST for CBTC * **Taproot-native:** FROST signatures are standard Schnorr signatures, compatible with any Taproot (P2TR) wallet. No special wallet support needed. * **Indistinguishable on-chain:** A FROST threshold signature looks identical to a single-signer Schnorr signature. No one can determine from the blockchain that a threshold scheme was used. * **Smaller and cheaper:** One aggregated signature regardless of threshold size, versus N signatures for traditional on-chain multisig. Lower transaction fees. * **No single point of failure:** The signing key is never reconstructed. Each Attestor holds only a share. ### Security Properties * **Unforgeability:** No coalition below the threshold can produce a valid signature, even with adaptive corruption (formally proven in the ePrint paper) * **Robustness against forgery attacks:** FROST mitigates certain Schnorr-specific threshold forgery vectors * **Forget-and-Forgive protection:** The resharing protocol includes acknowledgement steps preventing split-group attacks during key rotation **Full paper:** [FROST: Flexible Round-Optimized Schnorr Threshold Signatures (ePrint 2020/852)](https://eprint.iacr.org/2020/852) *** ## Attestor Network The Attestor Network is the decentralised security backbone of CBTC. ### Composition * **3 external node operators** (Finoa, Nethermind, DSRV) * **1 BitSafe-operated node** (4 total) * Each Attestor runs nodes on **both** the Bitcoin and Canton networks ### Responsibilities Attestor responsibilities are **almost entirely automated:** * Independent verification of Bitcoin transactions reaching 6 confirmations * Submission of `ConfirmDepositAction` (for mints) and `ArchiveWithdrawRequest` (for burns) to the Canton governance module * Participation in FROST threshold signing for Bitcoin withdrawal transactions * Monitoring deposit accounts and withdrawal requests The only manual process is **governance** - adding or removing Attestor nodes, which requires coordination between operators. ### Threshold Governance * For critical actions (minting, burning), each Attestor submits confirmation **independently** * Confirmations are recorded as Canton contracts * Once the number of valid confirmations meets the **predefined threshold**, the Coordinator executes the action * **No single party** - including BitSafe or the Coordinator - can unilaterally mint, burn, or move BTC ### Coordinator Role The Coordinator is a service (which can be an Attestor or a separate non-signing entity) that: * Executes periodic checks every **60-120 seconds** * Monitors deposit accounts for new Bitcoin transactions * Constructs Bitcoin transactions for withdrawals * Submits governance actions to Canton * Coordinates the FROST signing rounds **The Coordinator cannot act unilaterally.** It facilitates the process but requires threshold approval for every action. *** ## Dual-Network Security Model CBTC's security spans two networks simultaneously: | Layer | Network | Security Mechanism | | ------------------------------- | ---------- | ------------------------------------------ | | **Bitcoin custody** | Bitcoin L1 | FROST threshold signatures (Taproot) | | **Governance and coordination** | Canton | Daml contracts with threshold confirmation | | **Token operations** | Canton | CIP-56 compliant Daml contracts | The same Attestor network secures both layers, creating seamless security across both blockchains. *** ## Reliability and Safeguards ### Automatic Retry If a Bitcoin transaction fails to broadcast, the Coordinator detects the failure during subsequent checks and rebroadcasts using stored transaction data. ### Idempotent Operations Each withdrawal generates a unique transaction ID preventing double-spending, even with network-induced retries. ### Distributed Verification No single Attestor can block or manipulate operations. The threshold system ensures continued operation even with some nodes offline. *** ## Trust and Threat Model The CBTC system assumes an honest majority of the Attestor network Key trust assumptions: * A threshold of Attestors must be honest and online for the system to operate * The Coordinator facilitates but cannot act unilaterally * BitSafe operates one Attestor node but has no special privileges * Canton's privacy model ensures transaction details are visible only to involved parties ### What Cannot Happen * No single party (including BitSafe) can mint CBTC without genuine BTC deposits * No single party can withdraw BTC without threshold approval * No front-running or MEV - Canton has no public mempool *** ## Audit Reports CBTC smart contracts have been audited by **Quantstamp:** [**View Full Audit Report →**](https://certificate.quantstamp.com/full/cbtc/5d0d805e-8cf0-4a39-bf1a-0e94899b3c1c/index.html) *** ## Further Reading * [FROST Whitepaper (ePrint 2020/852)](https://eprint.iacr.org/2020/852) * [Canton Network Whitepaper](https://www.canton.network/whitepapers) * [Canton Token Standard Docs](https://docs.dev.sync.global/app_dev/token_standard/index.html#api-references) *** --- # 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://docs.bitsafe.finance/developers/security-deep-dive.md?ask= ``` 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.