Security and trust index
Choose a product security path
This page routes readers to product-specific security evidence. It does not replace a product threat model, audit page, or release record.
CBTC
Bitcoin custody, Attestor verification, Canton authorization, package integrity, client integration, reserve evidence, and operational controls.
Decentralization Manager
Operator authentication, Canton rights, peer identity and transport, persistent state, DAR handling, governance controls, deployment boundaries, and recovery.
Evaluate security evidence
Review the complete control system, not one claim or report.
Architecture and trust boundaries. Identify protected assets, privileged actors, data flows, external dependencies, and the boundary between product controls and operator responsibilities.
Source and supported release. Match documentation, source code, packages, images, and configuration to an Engineering-approved release. A commit or repository review baseline is not automatically a supported production release.
Controls and configuration. Confirm authentication, authorization, key and secret handling, network exposure, package provenance, monitoring, backup, recovery, and change control for the deployed environment.
Independent review. Match every audit report to the reviewed commit, component scope, exclusions, findings, remediation status, and supported release.
Product-specific evidence. For CBTC, review custody and reserve evidence separately. For Decentralization Manager, review governance, peer, deployment, and operator controls separately.
Known limitations and incidents. Check current known issues, unsupported versions, unresolved findings approved for disclosure, and incident notices.
Integrator responsibilities. Verify the application configuration, credentials, party rights, package versions, inputs, retries, logs, and support process. Product controls cannot correct an authorized command with incorrect inputs.
Product evidence
CBTC
Decentralization Manager
Audits
Each audit entry states:
Product and reviewed component.
Report date and auditor.
Reviewed commit, package, image, or release.
Included and excluded components.
Findings and auditor suggestions.
Remediation status and the release that contains each approved fix.
Link to the approved immutable report.
An audit is evidence about reviewed components at a point in time. It is not a guarantee that every deployment, configuration, integration, or later release is secure.
Canton privacy
Canton uses configurable sub-transaction privacy. Entitled parties see the contract data required for their transactions.
This boundary does not make every connected system private. Bitcoin transactions remain visible on Bitcoin. Identity providers, participant infrastructure, application databases, logs, analytics, monitoring, support exports, and other external systems have separate access and retention controls. Operators and integrators must protect those systems according to their own requirements.
Report a vulnerability
Use one approved private security channel. Do not disclose an unpatched vulnerability through a public issue, discussion, pull request, community channel, or support thread.
Include:
Affected product, version, commit, package, or image.
Deployment form and environment.
Reproduction steps or a safe proof of concept.
Potential impact and affected assets.
Supporting logs or evidence with secrets and personal data removed.
Safe contact details and any disclosure constraints.
Use the private reporting route listed for the relevant product. That route provides the current contact, acknowledgement target, response expectations, and coordinated-disclosure process.
Next step
👉 Choose the relevant security review: CBTC security or Decentralization Manager security architecture.
Last updated