> 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/glossary/glossary.md).

# Glossary

{% hint style="info" %}
**Scope:** shared terms used across CBTC and Decentralization Manager documentation. These definitions explain concepts. Product pages remain authoritative for supported versions, actor sets, thresholds, contract names, lifecycle states, endpoints, and operational policy.
{% endhint %}

{% hint style="info" %}
**Review boundary:** exact production behavior and security claims require Engineering and Security approval before publication.
{% endhint %}

### A

**Attestor:** An independent institutional operator that verifies eligible Bitcoin events and participates in authorized CBTC workflows.

**Attestor Network:** The set of Attestors involved in CBTC event verification and threshold authorization. Public documentation uses non-specific threshold framing unless a release-specific source approves more detail.

### B

**Burn:** A Canton-side operation that reduces CBTC supply as part of redemption. A burn does not, by itself, prove that Bitcoin has reached the destination address.

### C

**Canton Improvement Proposal (CIP):** A proposal used to define or change Canton ecosystem standards. Use **CIP**, not SIP.

**Canton Network:** The open institutional network on which CBTC and Decentralization Manager operate. Canton supports configurable sub-transaction privacy.

**CBTC:** BitSafe’s 1:1 Bitcoin-backed token on Canton Network.

**Contract ID:** The identifier of a specific Canton contract instance. Contract IDs can change when workflows archive and create contracts, so applications must discover current values instead of hard-coding them.

**Coordinator:** A context-specific workflow role that advances or coordinates a process. In Decentralization Manager, the coordinator is not a permanently privileged owner. In CBTC workflows, the term can refer to a service that coordinates eligible Attestor actions. Product documentation defines the exact authority in each system.

### D

**Daml:** The smart contract language used to define applications and workflows on Canton.

**DAR:** A Daml archive package installed on a Canton participant. A DAR can contain application packages and dependencies.

**Decentralization Manager:** BitSafe’s open-source framework for running Canton applications across independent nodes.

**Decentralized Party:** A Canton party designed to operate across multiple participant nodes. A control model can distribute governance or distribute hosting while one owner retains control. Supported models are release-specific.

**Deposit account:** A Canton contract used in an approved CBTC mint workflow to represent deposit-specific state and link that state to Bitcoin address rules.

### F

**FROST:** Flexible Round-Optimized Schnorr Threshold Signatures. FROST lets a threshold of key-share holders produce a Schnorr signature without reconstructing the full private key in one place.

### G

**Generalized Governance Core:** The Decentralization Manager foundation that provides proposal, confirmation, execution, and audit patterns for modules and custom Daml applications.

### H

**Holding:** An active Canton contract that represents an amount of CBTC owned by a party.

### I

**Instrument ID:** The identifier for a token instrument in a specific Canton environment. Applications must discover the approved CBTC instrument ID for the target environment.

### M

**Member:** A governance participant in a Decentralized Party that can exercise the rights assigned by that party’s governance model.

**Mint:** The process that creates CBTC on Canton after the approved Bitcoin deposit and authorization conditions are met.

**Minter credential:** A Canton credential contract used by supported CBTC workflows to authorize specified account-creation or issuance actions. The release-specific reference defines its exact rights.

**Module:** Application logic that runs with Decentralization Manager and inherits its governance lifecycle. Examples include the Token Management Module and Custody Module.

### N

**Noise identity:** The persistent cryptographic identity a Decentralization Manager instance uses when it connects to peers.

### O

**Owner:** The technical controller of a party or account. Ownership does not always mean that one actor can authorize every governed action.

### P

**Participant:** Canton infrastructure that hosts parties, submits transactions, and connects to a synchronizer.

**Party:** A Canton identity that can own contracts and exercise rights defined by those contracts.

**Peer:** Another Decentralization Manager instance connected through the authenticated peer network.

**Proof of Reserve:** Evidence used to compare approved Bitcoin reserve data with the applicable CBTC supply scope. Proof of Reserve does not, by itself, prove every property of custody, governance, or software security.

**Propose-confirm-execute:** A governance pattern in which a member proposes an action, the required members confirm it, and the system executes it after the approval rule is satisfied.

### R

**Redeem:** The process that removes CBTC from circulation and requests delivery of the corresponding Bitcoin to an approved destination address.

### S

**Sub-transaction privacy:** Canton’s configurable model for limiting transaction visibility to parties entitled to the relevant data.

**Synchronizer:** Canton infrastructure that coordinates transaction processing among connected participants.

### T

**Taproot (P2TR):** A Bitcoin output and address type used by current CBTC technical sources for Bitcoin-side deposit and custody workflows.

**Threshold authorization:** A rule requiring a minimum subset of eligible participants to approve an action. It is often written as M-of-N. The applicable threshold is release-specific.

**Token Standard:** Canton interfaces and conventions for token identifiers, holdings, and transfer workflows. The product compatibility reference defines the supported version.

**Transfer instruction:** A Canton token workflow contract used to request and track a transfer between parties.

**Transfer offer:** A Canton contract that offers CBTC from a sender to an intended receiver for acceptance.

### U

**UTXO:** Unspent transaction output. On Bitcoin, a UTXO is a spendable output from a previous transaction.

**UTXO management:** In the CBTC library, operations that split or consolidate Canton holding contracts for operational purposes. This is distinct from managing Bitcoin UTXOs.

### W

**Withdrawal account:** A Canton contract that records redemption-specific state, including the approved Bitcoin destination information required by the workflow.

**Withdrawal request:** A Canton contract created during redemption processing to track the requested Bitcoin-side withdrawal.

### Go deeper

* [How CBTC works](/cbtc-1/how-cbtc-works.md)
* [CBTC token standard and contract model](/cbtc-1/concepts-and-reference/token-standard-and-contract-model.md)
* [Decentralization Manager architecture overview](/decentralization-manager/concepts-and-development/architecture-overview.md)
* [Decentralized Party and Canton topology](/decentralization-manager/concepts-and-development/decentralized-party-and-canton-topology.md)
* [Decentralization Manager governance lifecycle](/decentralization-manager/concepts-and-development/governance-lifecycle.md)
* [Security and trust index](https://docs.bitsafe.finance/security-and-trust/)

### Next step

👉 **Return to the product paths:** [BitSafe documentation home](/home.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/glossary/glossary.md?ask=<question>&goal=<endgoal>
```

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