Canton Enterprise Integrations: APIs, Connectors, and Risk Boundaries

Canton’s integration architecture separates reads from writes by following the Command Query Responsibility Segregation (CQRS) pattern. This is not an incidental design choice but a deliberate architectural decision that limits the blast radius of any single integration failure by ensuring that a compromise on one path cannot automatically propagate to the other.

On the write path, applications submit commands to the participant node through the gRPC Ledger API. Each command identifies the Daml contract to create or the choice to exercise, along with the required party authorization. The Ledger API authenticates callers with JWT tokens and enforces authorization at the party level. That means if a caller lacks the required party rights, the command is rejected before it reaches the Daml execution engine. For enterprise integrations that prefer HTTP over gRPC, Canton also exposes a JSON Ledger API that provides nearly equivalent functionality through standard HTTP endpoints. Both interfaces represent authenticated entry points into the ledger, and both require the same JWT-based authorization. The Interactive Submission Service, available since Canton 3.3 and enabled by default in current versions, separates command preparation from signing and execution. This two-step pattern allows institutions to manage signing keys externally, through HSMs, MPC custody providers, or dedicated key management infrastructure, rather than delegating signing authority to the participant node. Canton supports registering multiple submission signing keys with a configurable threshold, so external parties can require several independent signatures before a transaction is accepted - a control that maps directly onto institutional dual-authorization requirements. The security implication is that it moves the most sensitive cryptographic operation out of the node’s trust boundary and into infrastructure that the institution controls directly.
 

On the read path, Canton offers two mechanisms with distinct security profiles. The Ledger API’s Update Service streams transaction events in real time, delivering creates, exercises, and archives as they occur. For more complex or high-throughput query patterns, the Participant Query Store (PQS) mirrors ledger data into a PostgreSQL database, making it available through standard SQL queries over JDBC connections. PQS operates as a passive consumer of the ledger’s event stream and never writes back to the ledger. This one-way data flow represents a deliberate architectural security property rather than a mere implementation detail. As a result, a compromised PQS instance can expose the data it was authorized to mirror, but it cannot alter ledger state or submit new transactions.

The separation between these paths constrains what an attacker can achieve from any single integration surface. A read-path compromise reveals information but leaves the ledger intact. A write-path compromise allows unauthorized commands, but only within the authorization scope of the compromised party; and even then, Daml’s signatory and controller requirements embedded in contract templates act as a second enforcement layer that limits what any single party can do. In many respects, this architecture means that Canton integration failures degrade gracefully rather than catastrophically, provided each path is independently secured.

Despite these architectural controls, the integration boundary introduces risks that Canton’s protocol cannot resolve on its own. Each failure mode operates at a different layer, yet they all share one common characteristic. They exploit the gap between the strong guarantees enforced on-ledger and the realities of off-ledger implementation.

The most immediate and consequential risk is credential leakage. JWT tokens that authenticate access to the Ledger API are bearer tokens, meaning whoever holds one can use it without additional identity verification. A leaked token grants the attacker the full authorization scope of the associated party, including the ability to exercise choices and create contracts. In production environments, tokens flow through configuration files, environment variables, CI/CD pipelines, and secrets management systems, and any misconfiguration or infrastructure compromise that exposes a token creates an instant authorization breach. 

Canton’s own dependency stack is not immune to related risks. The Canton 3.4.11 release upgraded gRPC to version 1.77.0 to address CVE-2025-58057, a denial-of-service vulnerability in the Netty decompression layer; the earlier 3.4.10 release had already upgraded gRPC to 1.75.0 and Netty to 4.1.130.Final to address both CVE-2025-58057 and CVE-2025-55163. Notably, the gRPC maintainers themselves considered direct exploitability through gRPC dubious, since the flaw lives in Netty's codec layer, which is precisely why integration-layer dependencies require independent patching discipline rather than reliance on any single component's assurances. 

Data leakage through the read path represents the second major risk category. PQS mirrors authorized ledger data into PostgreSQL. Once that data resides in the database, standard attack vectors become relevant. SQL injection, privilege escalation, credential theft, and unencrypted connections all apply. While Canton’s on-ledger privacy ensures that PQS receives only the events the participant’s parties are entitled to see, off-ledger protection depends entirely on the database’s own security posture. An institution can maintain perfect sub-transaction privacy on the ledger and still suffer exfiltration of that same data from an unpatched PostgreSQL instance running with default credentials and exposed to an untrusted network segment.

The third risk appears in the signal-and-response pattern that Canton uses for external data integration. Because Daml contracts cannot call external APIs during execution (this is a deliberate constraint that preserves deterministic execution), external data must enter the ledger through a specific workflow. Contracts emit events that signal the need for external information, off-ledger automation retrieves the data, and the results are submitted back as new transactions under the authority of the automation party. As we explained in our earlier article on communicating with a Daml/Canton ledger, this pattern preserves determinism and makes every external dependency visible in the ledger’s event log. Nevertheless, it also creates a concentrated trust dependency on the off-ledger automation layer. If that automation component is compromised, an attacker can inject fabricated data under the automation party’s authority. The ledger will process it as a valid submission.

In practice, this means a collateral management workflow that depends on an external price feed could receive manipulated asset valuations. This could trigger incorrect margin calls or release collateral based on fabricated prices. The ledger faithfully executes the contract logic against whatever data arrives through authorized channels. It has no built-in mechanism to verify whether the incoming data reflects reality.

The fourth risk concerns retry logic and idempotency on the write path. The gRPC Ledger API uses at-least-once delivery semantics for command submissions, meaning that if an application submits a command and does not receive confirmation due to network interruption, timeout, or process restart, it must decide whether to retry. Without proper use of the Ledger API’s command deduplication features, such as unique command IDs and appropriate deduplication windows, retries can produce duplicate transactions. In financial workflows, this translates directly into double settlements, duplicate payments, or double-counted positions. The risk is operational rather than cryptographic, but the financial impact of a duplicated high-value settlement can be immediate and substantial.

Effective protection requires a defense-in-depth approach that extends Canton’s on-ledger guarantees into the off-ledger environment, with continuous monitoring layered on top of preventive controls.

JWT tokens for Ledger API access should be short-lived, scoped to the minimum required party rights, and rotated automatically through dedicated secrets management systems such as HashiCorp Vault or AWS Secrets Manager rather than stored in configuration files or environment variables. Token refresh mechanisms must operate without requiring service restarts. In addition, monitor token usage patterns for anomalies. These include unusual submission rates, requests from unexpected IP ranges, or authorization attempts outside normal operational windows. Any of these could indicate credential compromise. For the Interactive Submission Service, where signing keys are managed externally, apply the same discipline to key material. Use HSM-backed storage, enforce strict access controls, and maintain rotation policies that do not interrupt workflows.

PQS PostgreSQL instances deserve treatment as high-sensitivity data stores, because that is exactly what they are. TLS should be enforced on all connections, role-based access control should limit which application components can query which tables, and audit logging should capture query patterns at the database level. PQS should run in an isolated network segment with no direct exposure to untrusted networks. Patches should be applied promptly, and monitoring should flag unusual query volumes or access patterns that could indicate data exfiltration. 

The fact that PQS only mirrors what the participant node’s parties are entitled to see does not eliminate the need for database-level security but simply bounds the worst-case exposure. Current PQS versions (3.4.3 and later) add selective ledger redaction and custom indexing, which let institutions further narrow what sensitive contract data is materialized into the mirror in the first place - a control worth applying before relying solely on database-level hardening.

The off-ledger automation components that feed external data into Canton contracts through the signal-and-response pattern carry the same risk profile as the contract templates themselves, and should be treated with equivalent rigor. Code review, CI/CD security gates, and isolated execution environments with minimal permissions are baseline requirements. Every external API call and the data it returns should be logged, creating an audit trail that can be cross-referenced with the ledger’s event log to detect discrepancies. Where feasible, critical inputs like pricing data, reference rates, and identity verifications should require confirmation from multiple independent data sources before submission to the ledger. A single-source feed for a critical input is a single point of failure in disguise.

Command deduplication on the write path is non-negotiable for any financial workflow. Set unique command IDs and appropriate deduplication windows for every submission, and design application logic to handle duplicate rejections gracefully rather than escalating retries. For high-value transactions, add a reconciliation layer that matches submitted commands against confirmed ledger events and flags discrepancies for manual review. The cost of implementing reconciliation is trivial compared to the cost of detecting a duplicated settlement after the fact.

Network architecture must enforce strict separation between participant nodes, PQS instances, and application backends. Mutual TLS should be required for all internal communication. API gateways with rate limiting and input validation protect the Ledger API from abuse, while monitoring must cover east-west traffic between components, not just north-south traffic from external sources. Deploy all integration components through infrastructure-as-code to guarantee reproducible and auditable deployments. Finally, enforce least-privilege principles across the entire stack, not only at the Ledger API level but also for PQS database roles, automation service accounts, and downstream system access.

In the event of a suspected breach, predefined response playbooks should cover immediate token revocation, PQS isolation, participant-level party rights adjustment, and forensic correlation between ledger events, automation logs, and downstream system activity. These operational controls ensure that integration risks, when they materialize, are contained quickly rather than allowed to propagate across institutional boundaries.

Several integration risks sit entirely outside the Ledger API’s scope. They require operational discipline that no protocol can provide on its own. Application logs that capture Ledger API requests or PQS query results frequently contain sensitive contract data. When these logs are forwarded to centralized logging systems such as ELK stacks, Splunk, or cloud-native services, the privacy boundaries that Canton enforces on-ledger can easily be broken by the logging pipeline itself. This exposure often goes unnoticed until a compliance audit reveals it. Production logging configurations should therefore redact or completely exclude contract payloads. Log storage must also follow the same strict access controls and retention policies applied to the ledger data itself.

Downstream systems that consume data from PQS or the Ledger API inherit the information but not Canton’s privacy model. A reporting tool ingesting PQS data can easily expose that information to users who would never qualify as observers on the ledger itself. Similarly, a compliance platform receiving transaction events may store them in ways that violate data minimization principles. Each downstream system must therefore be evaluated against the same privacy and access control standards applied to the ledger. The integration layer should actively enforce that only authorized data reaches each consumer.

Upgrade coordination across the integration stack introduces temporal risk that is easy to underestimate. When a Daml package upgrade modifies contract templates, every component that deserializes contract data must be updated in lockstep. This temporal risk is amplified during protocol-level migrations: synchronizer upgrades (such as the ongoing migration of the Global Synchronizer from CometBFT toward Canton-native BFT consensus) and Daml-LF changes like the contract-key model introduced in Canton 3.5 can alter serialization and validation semantics. External submissions prepared before a protocol upgrade may need to be re-prepared and re-signed afterward, which integration components must handle explicitly. This includes PQS configurations, application backends, reporting pipelines, and analytics dashboards. A version mismatch between the ledger’s contract schema and an integration component’s expected schema can produce silent data loss, deserialization failures, or incorrect interpretation of contract state. For this reason, every upgrade must include full-stack integration testing along with rollback procedures for each component. The entire upgrade process should first be validated in staging environments that accurately mirror production topology.

Canton’s protocol guarantees are only as strong as the weakest integration point. An institution can run a perfectly hardened participant node with rigorous key management and thoroughly audited Daml contracts and still suffer a breach. The cause is often an unpatched PQS database, an exposed JWT token in a CI/CD pipeline, or an automation component that accepts fabricated data from a compromised external API. 

This reality reflects the inherent challenge of embedding any distributed ledger into complex enterprise architectures rather than a limitation of Canton itself. What sets Canton apart is that its design makes the security boundaries explicit. The CQRS separation between reads and writes, the deterministic rejection of unauthorized commands, the one-way data flow through PQS, and the visibility controls that strictly limit what each participant can mirror all create clear perimeters. These perimeters can be monitored, tested, and hardened effectively. 

For institutions building on Canton, integration security must receive the same level of attention and discipline as contract template design and participant node configuration. This is increasingly material as the network moves into production-scale institutional deployments - DTCC’s tokenized Treasury pilot, the Kinexys (J.P. Morgan) JPMD integration, and Broadridge’s repo platform - and as the forthcoming Zenith EVM execution layer expands the integration surface to cross-VM workflows, each with its own connector and trust-boundary considerations. The ledger protects what happens inside the protocol. Everything beyond that boundary demands deliberate, continuous, and rigorous attention.

Securing Canton’s integration layer requires expertise that spans both distributed ledger architecture and enterprise security. At Halborn, we provide blockchain security audits, penetration testing, and security consulting for Daml and Canton implementations. Whether you are hardening Ledger API configurations, auditing PQS deployments, validating automation layers, or securing the full integration stack that connects Canton to your existing infrastructure, our team can help ensure your integration boundaries hold under adversarial conditions. Contact us to discuss your distributed ledger security needs.