> 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-1/how-cbtc-works.md). # How CBTC works [CBTC overview](/cbtc-1/overview.md) ### The short version CBTC represents Bitcoin on Canton Network. A mint starts with Bitcoin sent to a deposit address. The system verifies the deposit and creates the corresponding CBTC for the intended Canton party. A redemption consumes CBTC and releases Bitcoin to an approved destination. Transfers between Canton parties use Canton contracts and do not move the underlying Bitcoin for each transfer. ### The system has two connected ledgers * **Bitcoin:** holds the Bitcoin that backs CBTC and records deposits and redemption transactions. * **Canton Network:** records CBTC holdings, transfers, account workflows, and the parties authorized to act. The integration layer links a Bitcoin event to its corresponding Canton workflow. It must prevent duplicate processing and preserve enough identifiers for reconciliation. ### Mint lifecycle 1. The Canton party obtains the required credential and current deposit-account rules. 2. The party creates a deposit account. 3. The approved service returns a Bitcoin deposit address associated with that account. 4. The depositor verifies the network and sends Bitcoin to the address. 5. The system detects the transaction and waits for the approved confirmation state. 6. Independent Attestor Network participants verify the eligible Bitcoin event. 7. The approved threshold authorizes the mint workflow. 8. CBTC is created for the intended Canton party. 9. The Bitcoin transaction, account, attestation, Canton update, and resulting holding are reconciled. ### Transfer lifecycle A Canton transfer does not redeem Bitcoin. The sender creates a transfer offer for a receiver. The receiver inspects and accepts the intended offer unless an approved preapproval flow applies. Canton archives or updates the relevant contracts and creates the receiver’s new holding state. ### Redemption lifecycle 1. The party validates a Bitcoin destination. 2. The party creates or selects a withdrawal account using current rules. 3. The application selects sufficient CBTC holdings. 4. The party submits the redemption. 5. The Canton contract flow consumes the applicable CBTC state. 6. The approved Bitcoin signing workflow creates and broadcasts the redemption transaction. 7. The application tracks completion on Bitcoin and Canton. 8. The records are reconciled to one request. ### Who does what | Role | Responsibility | Boundary | | ------------------ | ---------------------------------------------------------------------------- | --------------------------------------------------------- | | CBTC holder | Owns Canton holdings and initiates supported actions | Can act only with the party’s authorization | | BitSafe services | Coordinate account and integration workflows | Cannot be described as able to move reserves unilaterally | | Attestor Network | Verifies eligible Bitcoin events and participates in threshold authorization | No single operator is sufficient | | Canton participant | Hosts the party and submits or observes authorized Canton actions | Visibility follows Canton entitlements | | Bitcoin network | Records deposits and redemption transactions | Confirmation and fee behavior are external to Canton | ### Backing and verification CBTC is intended to remain backed 1:1 by Bitcoin. Public documentation should distinguish: * Bitcoin reserves visible on Bitcoin. * CBTC supply and contract state visible to entitled Canton parties. * Proof of Reserve evidence and its exact coverage. * Operational reconciliation performed by the system. ### Failure boundaries A workflow can pause because of Bitcoin confirmation delays, service availability, Canton connectivity, authentication, incompatible packages, insufficient approvals, or an ambiguous prior submission. Clients must query authoritative state before retrying. ### Related guides * [Mint CBTC](/cbtc-1/guides/mint-cbtc.md) * [Redeem CBTC](/cbtc-1/guides/redeem-cbtc.md) * [Transfer and receive CBTC](/cbtc-1/guides/transfer-and-receive-cbtc.md) * [CBTC architecture and trust boundaries](/cbtc-1/concepts-and-reference/architecture-and-trust-boundaries.md) ### Technical sources * [`cbtc-lib` repository](https://github.com/DLC-link/cbtc-lib) * [`canton-lib` repository](https://github.com/DLC-link/canton-lib) ### Next step 👉 **Choose an operation:** [Choose a CBTC path](/cbtc-1/choose-a-cbtc-path.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-1/how-cbtc-works.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.