Daml Hub is a cloud platform built to help you take your Software-as-a-Service (SaaS) application from humble beginnings to mass adoption with as little development as possible.

Daml Hub is for developers looking to build a simpler, scalable backend for their applications with a serverless experience.

Almost any application heavier than a pure web app can benefit from using Daml Hub as a backend. Developers use Daml Hub to build applications like crypto exchanges, loan management platforms, medical claims management, digital rights management, and many more.

Daml Hub Features

As of July 28, 2024, Daml Hub no longer offers a free service tier. Free tier users can upgrade to Enterprise by contacting Digital Asset Sales here.

Daml Hub Enterprise offers the following features:

• The ability to create up to 10 standard ledgers
• The ability to create high capacity ledgers with no ledger event quota
• The option to stream logs from high capacity ledgers to Datadog
• The option to invite ledger collaborators
• The option to reserve custom subdomains and assign them to ledgers
• 99.9% uptime commitment
• 24/7 support

Credentials and Tokens in Daml Hub

The tables below list the credentials and tokens needed when performing actions on Daml Hub or against the ledger or services.

Credentials

The first account token needs to be manually copied from the ‘Copy Account JWT’ button in the Profile tab of Account Settings in the Daml Hub console

Credentials	What do the Credentials do?	Required Authentication Token	Where is this Created in the Console?	Works with Ledgers?	Works with the New Services?	API Link	Expiry Time
Personal Access Credentials - Account	Mints new account tokens	Account token	PACs tab in the account settings	Y	Y	Site API: PACs	User defined up to 365 days
Personal Access Credentials - User	Mints user tokens	Account token	PACs tab in the account settings	Y	Y	Site API: PACs	User defined up to 365 days
Service Account Credentials	Mints party tokens	Account token	Service accounts tab in the identities tab of a ledger	Y	N	Application API: Service Accounts	365 days
Site Credentials (deprecated): use Personal Access Credentials - Account	Mints account tokens	Account token	Site credentials tab in the account settings	Y	Y (but they’re deprecated)	None	User defined

Tokens / JWTs

Token	What it Does	Credentials Needed to Mint	Daml Hub JWT or Participant JWT	Docs Link / API Link	Where is this Created in the Console?	Expiry Time	Notes
Account token	Authenticates a Hub account to take Daml Hub platform actions through the site API (or via the console)	Personal Access Credentials - Account	Daml Hub	After the first time use Site API: PACS generateAccessToken	Profile tab of the Account Settings ‘Copy Account JWT’	User defined up to 24 hours. Defaults to 24 hours.	Used for creating projects, ledgers, services and uploading artifacts to the workspace
User token	Authenticates a user on the ledger / participant	Personal Access Credentials - User	Participant JWT	Site API: PACS generateAccessToken	Copy the JWT in the identities tab of the ledger / participant	User defined up to 24 hours. Defaults to 24 hours.	Preferred mechanism for automation when interaction with the Application Api
Ledger party token	Authenticates a party against the ledger / participant	Service Account Credentials	Participant JWT	Application API: Service Account saLogin	Copy the JWT of the party in the identities tab of the ledger (only in ledgers)	24 hours	Less-preferred (but still supported for ledgers) mechanism for automation when interaction with Application Api. User token preferred

User Actions Available

Only the ledger owner/collaborator users can perform administrative actions on the participant – the actions available to each are detailed below.

User Type	Type of Token	Administrative Right	Return Own User Identity	Retrieve Own User Rights	Create/Delete/Modify/View Other Users	Create Parties	List Parties
Ledger / Service owner	User token	IdentityProviderAdmin	Y	Y	Y	Y	Y
Collaborator	User token	IdentityProviderAdmin	Y	Y	Y	Y	Y
Standard user	User token		Y	Y	N	N	N

Quotas and Limits on Daml Hub

Component Capacities

The table below lists the capacities of the different ledger sizes and integrations on Daml Hub.

Component	CPUs	RAM (GB)	Storage (GB)
Standard Capacity Ledger	2	3	20 GB
High Capacity Ledger (Large)	4	8	50 GB
High Capacity Ledger (Huge)	4	8	555 GB
Synchronizer	1	2	20 GB
Automations (Integrations)	1	12	n/a
Automations (Bots)	1	8	n/a
Triggers	1	4	n/a

Standard Capacity and High Capacity Ledgers

Users can manage the capacity of their ledgers from the console. Each account has one primary account holder, and a given primary account holder can have up to three High Capacity ledgers at one time. If you already have three High Capacity ledgers, you must delete one or reset it to standard before creating another.

You can set the ledger capacity at the creation of a new ledger or project by selecting "High Capacity" on the Ledger Details screen.

To change the capacity of an existing ledger, use the "Ledger Capacity" drop-down on the Ledger Settings page. Changing the ledger capacity of an existing ledger causes up to ten minutes of downtime for that ledger as it restarts with new settings.

gRPC Request Size Limits

gRPC requests on Daml Hub have a 10MB limit.

This means that:

• The maximum size of a gRPC request is 10MB
• The maximum size of a gRPC response is 10MB, and
• The sequencer only performs computation on transaction trees under 10MB

Because of these limits:

• The Canton domain sequencer only performs computation on transaction trees under 10 MB.

• Integrating with other Canton domains/participants that have these limits set to different limits can result in unanticipated gRPC message failures.

To stay within these limits:

• Any individual contract must be smaller than 10 MB.

  • To achieve this, avoid contracts with large blob data or very large data structures. Blobs can be stored off-ledger and their hashes recorded on the ledger; very large data structures should be split up into multiple contracts.

• Total transaction tree sizes must also remain smaller than 10MB.

  • To achieve this, keep the number of commands submitted small, and write your Daml so that choice exercises result in a reasonable number of changes.

A primary goal of gRPC size limits is to reduce the memory consumption of the participant/sequencer. The larger the payloads, the more resources get used and the longer the response times. Without a limit, Hub encourages development anti-patterns: if you run into this limit, you are probably not using the system as intended. By design, the platform encourages limiting request sizes.

Additionally, in a Canton-enabled world, even if you increase the size limits on your participant and/or domain, you have no way to increase the size limit on other people's participants and domains. Increasing your size limits is therefore unlikely to produce the desired result.

Batch Size Limitations

The maximum number of individual commands submitted in a single CommandService.Submit or SubmitAndWait call is not limited, but you should target batch sizes between 50–100 commands for optimal performance:

• Too few commands in one submission increase the overall time to completion.
• Too many commands in one submission increase the complexity of that command and could lead to command rejection or the issue described in "Transaction Trees".

File Size Limit

The file size limit for all files, including .dar, .dit, .tar, .tgz, .tar.gz, and .zip, is 32 MB.

Daml Hub Rate Limits

Daml Hub imposes rate limits on cluster traffic based on IP address:

• HTTP Requests to auth endpoints (/auth/) are limited to 500/minute.
• HTTP Requests to the API (/api/) are limited to 1000/minute.
• All HTTP requests are limited to 5000/minute.

Requests that exceed this rate limit receive a 429 HTTP error response.

API Docs

You can find detailed Daml Hub API documentation here.

Ledger Performance

To provide guidance on what to expect from Daml Hub ledgers, here are the results of some intra-cluster load tests.

First, the numbers, followed by an explanation of the methodology. An important detail to note - all throughput numbers target an average latency of 1s:

Ledger Size	Test Type	Command Submissions* (CS)	Events**
Standard	gRPC IOU payload	40 CS/s	40 Events/s
Standard	gRPC large payload	13 CS/s	13 Events/s
Standard	gRPC 18 create events per CS	12 CS/s	213 Events/s
High Capacity	gRPC IOU payload	81 CS/s	81 Events/s
High Capacity	gRPC large payload	50 CS/s	50 Events/s
High Capacity	gRPC 18 create events per CS	17 CS/s	307 Events/s

Methodology

These load tests were run in-cluster; command submissions were made via gRPC. The load tester sent X command submissions per second, increasing X until it reached an average latency for command submissions of one second. It then averaged the rate of command submissions per second for the run.

Definitions

*Command Submission (CS): A command submission is a request sent over the wire containing one or more commands. All command submissions in this test use only one command.

**Events: Each "event" is an individual contract change, such as a create or archive. Multiple events in a command submission were achieved by performing a varying number of creates within a single choice exercise.

Ledger Pruning

Pruning in Daml frees up storage space by deleting archived contracts.

Daml Hub prunes every other hour based on the following rules:

1. If a ledger’s disk size is less than <usage threshold %> of the disk capacity available to it, no archived contracts are pruned.
2. If a ledger’s disk usage exceeds <usage threshold %>, the oldest archived contracts are pruned, starting with an < oldest age - 3 days> range.
3. If a ledger’s disk usage still exceeds <usage threshold %> after the initial pruning, the system continues to prune increasingly smaller time windows, reducing the retention window by one day (90 days, 89 days, 88 days ... down to 1 day) until disk usage is under <usage threshold %>.

The ledger remains available for use during pruning.

Disk sizes and percentage usage thresholds for the different classes of Daml Hub Ledgers are listed below:

Ledger Size	DB Disk Size	DB Percentage Usage Threshold
small	10GB	30%
medium	20GB	30%
large	50GB	30%
huge	555GB	90%

Synchronizers are regularly pruned within a 14 day period.

NOTE: Internally stored objects related to archived contracts within the domain and participant are regularly pruned within a 7 day period, but this does not affect the ability to stream these archived contracts via Ledger API.

Disaster Recovery

Daml Hub takes backups of all ledgers every hour and keeps the last 24 hours of hourly backups, the last backup from every previous day for the past week, and the last backup for the past week for 4 weeks. In the case of a disaster that takes out the persistent layer of the ledgers, Daml Hub recovers from the most recent backup. Ledgers with a large amount of data may take longer than an hour to back up, in which case subsequent backups only start once the previous backup finishes meaning they're backed up less than every hour.

Customers running a hybrid environment -- where some Canton components are hosted on Daml Hub and some are hosted elsewhere -- should ensure that they have a disaster recovery plan in place, following the documentation and the recommended approach for handling different disaster recover scenarios outlined in the docs linked below :

Guidance on backup and restore considerations Guidance on recovering from a lost domain Guidance on recreating a missing participant from a synchronizer

Daml Hub Updates and Releases

Release Classifications

The following table shows the Daml Hub release classifications, the customary notification periods and the scope of the release.

Release Classification	Customary Notification Period	Impact scope
Critical impact	As soon as identified	Variable
High impact	5 business days	The Daml Hub platform is taken down and the console, ledgers, and all user websites are inaccessible for the duration of the upgrade
Medium impact	2 business days	The Daml Hub console remains running, but users’ ledgers may briefly restart and be unavailable for 5–30 minutes; this may also cause automations and triggers to restart
Minimal impact	1 business day	The Daml Hub console remains running, but users’ ledgers may briefly restart and be unavailable for up to 5 minutes; this may also cause automations and triggers to restart

Daml Hub aims to keep medium and high-impact releases to a minimum and to apply them at most once a month, only as needed. This may not always be possible when addressing critical issues and security patches.

The release classification and expected impact on customers are included in the release announcement forum post. Most releases have no impact on customer applications because Daml is backward compatible between minor releases and Daml Hub does not deprecate features without appropriate warning. Releases that may necessitate changes to users' applications, for example moving to a new major Daml version, are announced with enough time for customers to plan and implement changes.

New Daml Hub features are announced after the release on the Daml Release Notes blog.

Release Notifications

Releases are announced on the Daml forum using the tag damlhub-release.

To receive email notifications about Daml Hub releases you will need to:

1. Sign up to the forum with the email address where you'd like to receive the notifications
2. Filter posts by the daml-hub-releases tag
3. Click the bell icon and change your notification level to 'Watching'

Early Access Features

Features marked Alpha in the Daml Hub console or the documentation are in a very early stage of their development. Alpha features are not complete and have not been as thoroughly tested as beta or generally available (GA) features. The incomplete aspects may be noted in the documentation. A feature is released in an alpha state to receive feedback from customers as early in the development phase as possible. Users should expect breaking changes in alpha features and should not build the use of alpha features into production applications.

Features marked Beta in the Daml Hub console or the documentation are usually complete but have not been as thoroughly tested as GA features. A feature is released in beta to receive feedback from customers and to continue testing. Users should not build use of beta features into production applications.

To provide feedback on an alpha or beta feature in Daml Hub, please email productfeedback@digitalasset.com.