

Canton is designed to enable interoperable, institutional-grade finance. Still, privacy remains a critical concern for businesses using it for tokenized assets, payments, and cross-border workflows.
Without the right operating model, even powerful privacy features can still lead to sensitive data leakage and compliance risk.
Canton offers “programmable privacy”: applications decide who can see what, rather than broadcasting every transaction to the whole network. In practice, this means transaction data is visible only to directly involved parties and any explicitly authorized observers, such as regulators or specific operational teams.
For example, two institutions transacting in a stablecoin on Canton can keep their activity visible only to themselves and designated observers, with no leakage to the wider network.
However, privacy is not automatic: poorly designed Daml contracts or misconfigured observer rights can still expose trading positions, counterparties, or flows to unintended parties.
In traditional, fragmented ledger or database setups, it is easy to over-share data—for example, by providing counterparties or service providers with full transaction histories rather than the minimum required information.
There are two distinct layers of privacy to get right on Canton.
Canton’s selective disclosure model addresses much of this, but only if governance and access controls are carefully designed. Institutions need to ensure that only the relevant parties can view transaction details, including, where necessary, designated auditors and regulators.
Designing this correctly requires a precise mapping from business roles (trader, operations, risk, external partner) to technical permissions, and consistent enforcement across all Canton-based applications.
For regulated scenarios such as cross-border payments, syndicated loans, or multi-bank consortia, Canton’s privacy model is viable and powerful when combined with robust key management and access control.
Keys often need to be shared logically across entities (for example, different signatories in a corporate hierarchy and departmental structure), so that they can authorise actions as a group without any one individual ever holding or re‑using a single shared private key like a password.
MPC lets each party hold only a fragment of a single private key and collaboratively produce signatures, achieving a similar “many must approve” effect to multi‑sig while ensuring the whole key is never reconstructed in any one location.
This complements Daml’s contract‑level privacy: Daml defines who can see and act on a given business workflow, while MPC ensures the underlying signing power is distributed so no single actor can bypass those policies.
The challenge for most teams is not understanding that privacy is important, but implementing it quickly without writing and maintaining extensive custom security code. Ideally, institutions should be able to define roles, data-access policies, and approval flows once, and then apply those consistently across subnets, asset types, and use cases.
A practical approach is to adopt a standardized privacy and key-management layer that sits alongside Canton applications.
This layer handles encryption, key sharing, access control, and audit logging, while Canton and Daml continue to manage the business logic and transaction workflows. This separation lets business teams evolve products without constantly revisiting low-level cryptography and infrastructure.
Blockdaemon’s solutions are designed to operationalize Canton’s privacy model for institutional users.
Blockdaemon Wallet and Vault solutions use MPC-based key management and role-based access control to define who can initiate, approve, or see specific transactions, ensuring only the right participants and observers have visibility into sensitive data.
In the previous blogs, Acme Bank acted as our global custodian. Now, let’s say Sam, a corporate accountant at Acme, needs to pay a vendor 5,000 USD equivalent in Canton.
Role-Based Access Control (RBAC): Sam logs into the Blockdaemon Vault/Wallet interface. Blockdaemon's wallet checks Sam’s pre-defined permissions (their "role").
Low-Level Term: The system's MPC Policy Authority (MPA) verifies Sam’s User ID and associated policy rules. The policy, which is cryptographically enforced, dictates that transactions above a certain threshold (e.g., 10,000 USD) require multiple approvers.
For multi-party and consortium scenarios, Blockdaemon supports encrypted key shares across participating nodes, ensuring no single institution holds all the power or information.
This enables atomic, cross-border and multi-asset transactions to run with strong privacy guarantees while remaining auditable and compliant. Teams can typically implement these privacy controls in hours rather than embarking on long custom development projects.
Check out the other blogs in this series: