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 and enabled on Bitcoin via the Taproot upgrade.

How FROST Works

FROST is a two-round signing protocol:

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.
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)

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