Digital Asset develops Canton infrastructure and Daml application technology for coordinated financial workflows. Separately governed institutions use those components to maintain shared records while controlling access to confidential data. The supplier’s role is distinct from the issuer, custodian or settlement institution attached to a particular asset.[1][2]
The practical purchase decision is architectural: who operates the validator, who can submit legally significant actions, which synchronizer carries messages, how client records remain private and which contracts constitute real enforceable securities or money. Network interoperability does not answer those legal or operational questions on its own.[3][4]
Services and customers
Sections ↑Digital Asset components and responsibilities
| Component | Function | Control boundary |
|---|---|---|
| Daml | Contract templates express asset states, parties and authorised transitions. | Business logic must match documentation and legal terms.Source 2 |
| Validator node | Hosts parties and processes the ledger data relevant to them. | Operator handles resilience, access and package approvals.Source 3 |
| Synchronizer | Coordinates transaction ordering/confirmation among connected nodes. | Topology, admission rules and participant connectivity matter.Source 2 |
| Composability modules | Utilities for tokenization and credentials are documented. | Product modules do not replace issuer eligibility and custody checks.Source 2 |
Canton’s privacy model keeps validators focused on the contracts of the parties they host, rather than broadcasting every confidential position to every participant. This differs from simply placing a financial ledger on a public chain. It still leaves visibility decisions, business rights and retention obligations with the organisations deploying each application.[3][5]
The company also describes application-building and connection services for banks and market operators seeking digital asset mobility. An application advertised as Canton-compatible may still require explicit onboarding to a particular synchronizer and validation of the relevant Daml packages.[1][2]
Platforms, connectivity and integrations
Sections ↑Operating topology and technical access
| Interface | Documented role | What to test |
|---|---|---|
| Ledger API | A validator offers programmatic access to ledger actions and events. | Authentication, actAs/readAs and idempotency.Source 2 |
| Validator-to-synchronizer | Validators connect through approved network interfaces. | Availability, traffic rights, topology updates and handover.Source 4 |
| Parties and permissions | Submission, confirmation and observation roles are distinguished. | Legal authority for each operator signing workflow.Source 5 |
| Package vetting | Operators approve packages they are willing to run. | Upgrade controls, resource risk and rollback procedures.Source 4 |
Party authority in the version 3.5 documentation
| Role | Authority and dependency |
|---|---|
| Submitting node | Can sign and submit for a local party; also has confirmation and observation rights.Source 5 |
| Confirming node | Confirms transactions using its own key; the configured threshold determines how many confirmations are required.Source 5 |
| Observing node | Records relevant transactions and provides read access, without submission or confirmation rights.Source 5 |
| External party | Controls its own submission keys and namespace, and signs transactions explicitly; still needs at least one confirming node.Source 5 |
Traffic is a capacity budget, not simply a fee per completed financial trade. The version 3.5 specification charges sequenced messages according to payload size, recipients and configured overhead. Base capacity accumulates over synchronizer time; additional capacity can be purchased. A message rejected after traffic has been deducted can still consume capacity. Operators therefore need to budget unsuccessful submissions and protocol traffic as well as successful business transactions.[6]
Pricing, fees and commercial terms
Sections ↑Commercial cost layers
| Layer | Public evidence | Likely contract boundary |
|---|---|---|
| Developer tools | Documentation and technical examples are openly accessible. | Internal engineering and approved licences still need review.Source 2 |
| Node operations | Validator and synchronizer deployment is configurable. | Hosting, monitoring, security and enterprise support.Source 7 |
| Network capacity | Traffic management includes purchased additional capacity. | Network rules and capacity economics vary by venue.Source 6 |
| Business applications | Tokenization and workflow software requires scope definition. | Issuer, operator and integrator commercial agreements.Source 1 |
A proof-of-concept assembled from tutorials is not a quote for production Canton participation. It may use in-memory storage, simplified keys or local synchronizer connections that are unsuitable for regulated operations. The full cost includes environment separation, disaster recovery, operational staff, penetration testing, permitted third-party components and transaction-capacity economics.[2][7]
Production pricing depends on the role: operating a validator, buying hosted infrastructure, running a synchronizer or using another firm’s application. The traffic specification defines resource accounting rather than a universal currency-denominated enterprise tariff.[6][1]
Implementation and operating requirements
Sections ↑Before production, an institution needs to determine its desired party identities, hosting permissions, consent to run code packages, synchronizer topology and the retention of cryptographic keys. The technical documentation describes these as operational steps, not just a one-time API credential exercise.[4][5]
Migration from a conventional ledger must address reconciliation and legal finality. The application’s token record can coordinate an asset workflow, but the purchaser still needs a contractual relationship with the issuer, registrar, securities depository, settlement bank or custodian as the case demands. A technical transfer is not automatically transfer of legal title.[3][1]
Support, complaints and incident response
Sections ↑The public Canton documentation archive provides versioned node-operation and Daml material. The supplier links licensed users to its support portal. Contracted support establishes response times, recovery duties, upgrade windows and the treatment of dependencies on independently operated synchronizers.[2][7]
Issue resolution may span the application vendor, validator host, synchronizer operator and financial institution. An incident matrix should identify precisely who may replay a failed workflow, restore access to a party and authorise code upgrades.[4][5]
Published contact routes
Scope Official enterprise Canton information and enquiry route.
Scope Versioned Canton and Daml documentation archive.
Scope Technical node-operation guidance, not a contractual support mailbox.
Scope Official support portal linked for licensed users.
Regulatory permissions and entity scope
Sections ↑Neither the Daml language nor a Canton validator is itself a regulated custody, trading or payment-service licence. Specific financial-services permissions must be assessed for the entity that issues assets, holds client keys, matches trades, settles cash or provides investment services.[2][1]
Permissioned network membership is also different from a statutory permission. Network governance can restrict participation or contract execution, but it cannot substitute for securities-law transfer requirements, AML or bank prudential oversight.[4][5]
Company background and contracting identity
Sections ↑The company’s privacy notice names Digital Asset Holdings, LLC and its affiliates and identifies the LLC as the website-data controller. The group markets application development, ecosystem connection and adoption services around Canton. Its privacy identity does not by itself identify the counterparty to every enterprise service contract.[1][8]
External signing limits a host’s ordinary submission authority, but the documented trust model still depends on confirming nodes and package approval. A quorum of faulty confirming nodes can undermine validation. Command completion and deduplication are also tied to the node used for submission in the cited version, so failover design must account for ambiguous outcomes before resending a transaction.[5]
- Operator
- Digital Asset Holdings, LLC and contracting affiliates
- Service scope
- Enterprise software and engineering for interoperable financial applications on the Canton Network, including the Daml language and SDK, validator nodes, synchronizers and tokenization components. The network is infrastructure rather than a bank, custody account or guarantee of cash settlement.
- Customer types
- Banks and capital-markets firms; Securities market infrastructures; Custodians and asset issuers; Institutional software developers; Digital-asset platforms
- Delivery
- API; Hosted; On premises; Hybrid
- Pricing publication
- Public and quoted pricing
- Headquarters
- United States; contracting entity to be confirmed
- Platforms
- Canton; Daml; Canton validator nodes; Canton synchronizers
- Pricing scope
- Developer materials are publicly accessible; production node hosting, enterprise services and traffic economics vary by role and contract. The published traffic-management specification describes purchased capacity but no universal all-in enterprise price.
- Implementation
- Teams must choose node hosting, synchronizer access, party permissions, package vetting and identity operations. A pilot must be upgraded to production-grade persistent storage, security, resilience and monitoring. No universally applicable deployment SLA or fee was published in the reviewed platform pages.
- Support
- Public technical documentation and enterprise engagement routes. Operational support for a validator, hosted services or a synchronizer is contractual; published open documentation alone is not a production support agreement.
- Permissions and regulatory scope
- Digital Asset supplies software and related services. Canton participation does not amount to financial-services authorisation; each issuer, bank, operator, custodian or financial market infrastructure retains its own entity-specific legal obligations and securities, payments and custody permissions.
Provider metadata checked 22 Oct 2026Source 1Source 2Source 3Source 4Source 5Source 6Source 7Source 8
Additional Information
Sections ↑The key architecture review should request a workflow trace from instruction through authorization, contract creation, confirmation and off-chain settlement. Obtain the network participation terms, validator operating model, traffic budget, security responsibilities, legal title analysis and a rollback plan before treating token movement as a completed market settlement.[6][4][3]
Sources & further reading
- Digital Asset and Canton commercial proposition Digital Asset · Accessed 29 Oct 2026
- Canton and Daml documentation archive Digital Asset · Accessed 29 Oct 2026
- Canton technical overview and privacy architecture (version 3.5 archive) Digital Asset · Accessed 29 Oct 2026
- Canton topology and hosting relationships (version 3.5 archive) Digital Asset · Accessed 29 Oct 2026
- Validator permission models (version 3.5 archive) Digital Asset · Accessed 29 Oct 2026
- Canton traffic management and purchased capacity (version 3.5 archive) Digital Asset · Accessed 29 Oct 2026
- Participant and validator node operations Digital Asset · Accessed 29 Oct 2026
- Digital Asset privacy notice and named legal entity Digital Asset · Accessed 29 Oct 2026
This profile reports dated public information, including provider-published services and terms. It does not independently test or guarantee service delivery, integrations or performance. Inclusion is not an endorsement. Permissions and protections apply only to the named legal entity, service and client category; check the current official records and your contract.