Support and developer resources
Get help
Use this page to choose the correct support route and collect the evidence needed for triage. Product task guides remain the source for prerequisites, expected outcomes, and product-specific troubleshooting.
Before you contact support
Collect only the information that applies to the issue:
Product and operation.
Environment and UTC time of the event.
Application, library, and package release set.
Canton participant and party identifiers, with confidential values redacted where required.
Sanitized request or command reference.
Relevant contract, update, or workflow identifiers.
Bitcoin transaction identifier for a mint or redemption issue, when available.
Expected result and observed result.
Reproduction steps that do not expose production secrets.
Sanitized logs from the affected time window.
Do not retry an ambiguous state-changing operation only to create more evidence. Check the product state first, then follow the operation guide’s recovery instructions.
Route the issue
Security vulnerability
Approved private security channel
Affected product and release, impact, reproduction steps, and safe contact details. Do not disclose an unpatched vulnerability in a public issue.
Product integration or production operation
Approved BitSafe support route
Environment, release set, operation, sanitized identifiers, expected result, observed result, and redacted logs.
Source-code defect or documentation defect
Relevant repository issue, only when no sensitive data is involved
Repository release or commit, minimal reproduction, expected behavior, observed behavior, and sanitized output.
Canton platform behavior
Digital Asset or approved Canton support path
Canton release, participant context, affected API or workflow, sanitized error, and evidence that the issue is outside the BitSafe component boundary.
Evidence by product
CBTC
Include the affected operation, the pinned cbtc-lib and canton-lib releases, Canton participant version, installed CBTC and dependency DAR set, authenticated party, relevant contract or update identifiers, and Bitcoin transaction identifier where applicable.
Use CBTC errors, retries, and troubleshooting before escalation. Check CBTC compatibility and release notes for the repository baseline, compatibility information, and current support status.
Decentralization Manager
Include the application tag and commit, image tag and digest where applicable, Canton version, deployment type, identity provider, database and package state, affected peers, workflow identifier, and sanitized logs.
Use Decentralization Manager compatibility, releases, and troubleshooting to check compatibility and collect the diagnostic set.
Developer resources
CBTC Rust library, examples, tagged releases, and DAR guidance.
Shared Canton Ledger API, registry, authentication, and integration utilities.
Source, operator guidance, architecture, deployment, security policy, and tagged releases.
Canton platform concepts, participant administration, APIs, and Daml guidance.
Use immutable release tags or approved commits when evaluating code and examples. Do not treat a mutable main branch as a supported production dependency.
Product release sources
This shared page does not own release notes or compatibility details. Use the product compatibility pages as the canonical source for supported component combinations, migrations, known issues, deprecations, and support status:
Repository releases provide source history and exhaustive implementation details. A repository tag does not by itself prove that an environment supports that release. Confirm the complete approved compatibility row before installation or upgrade.
What support can and cannot determine
Support evidence can help identify configuration, compatibility, authorization, connectivity, workflow-state, and source-code issues. It cannot replace an institution’s own security, legal, compliance, operational-risk, or production-change review.
Next step
👉 Continue with the right product path: BitSafe documentation home.
Last updated