# Scheduled Maintenance Source: https://docs.digitalasset.com/Scheduled-Maintenance The DA Apps team performs weekly maintenance every Wednesday from **09:00–10:00 ET / 15:00–16:00 Central European Time / 13:00–14:00 UTC**, aligned with Splice upgrades on MainNet. During this maintenance window, individual components may experience brief periods of downtime. # Get apiutilitiesv0contractinstrument configurationall Source: https://docs.digitalasset.com/api-reference/operator/get-apiutilitiesv0contractinstrument-configurationall /registry/apis/open-api-specs/utility.yaml get /api/utilities/v0/contract/instrument-configuration/all # Get apiutilitiesv0openapi Source: https://docs.digitalasset.com/api-reference/operator/get-apiutilitiesv0openapi /registry/apis/open-api-specs/utility.yaml get /api/utilities/v0/openapi # Get apiutilitiesv0operator Source: https://docs.digitalasset.com/api-reference/operator/get-apiutilitiesv0operator /registry/apis/open-api-specs/utility.yaml get /api/utilities/v0/operator # Get apiutilitiesv0packageall Source: https://docs.digitalasset.com/api-reference/operator/get-apiutilitiesv0packageall /registry/apis/open-api-specs/utility.yaml get /api/utilities/v0/package/all # Post apiutilitiesv0contractinstrument configuration Source: https://docs.digitalasset.com/api-reference/operator/post-apiutilitiesv0contractinstrument-configuration /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/contract/instrument-configuration # Get apitoken standardv0registrars registrymetadatav1info Source: https://docs.digitalasset.com/api-reference/public/get-apitoken-standardv0registrars-registrymetadatav1info /registry/apis/open-api-specs/utility-token-standard/v1/token-metadata-v1.yaml get /api/token-standard/v0/registrars/{registrarParty}/registry/metadata/v1/info Get information about the registry. The response includes the standards supported by the registry. # Get apitoken standardv0registrars registrymetadatav1instruments Source: https://docs.digitalasset.com/api-reference/public/get-apitoken-standardv0registrars-registrymetadatav1instruments /registry/apis/open-api-specs/utility-token-standard/v1/token-metadata-v1.yaml get /api/token-standard/v0/registrars/{registrarParty}/registry/metadata/v1/instruments List all instruments managed by this instrument admin. # Get apitoken standardv0registrars registrymetadatav1instruments 1 Source: https://docs.digitalasset.com/api-reference/public/get-apitoken-standardv0registrars-registrymetadatav1instruments-1 /registry/apis/open-api-specs/utility-token-standard/v1/token-metadata-v1.yaml get /api/token-standard/v0/registrars/{registrarParty}/registry/metadata/v1/instruments/{instrumentId} Retrieve an instrument's metadata. # Post apitoken standardv0registrars registryallocation instructionv1allocation factory Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registryallocation-instructionv1allocation-factory /registry/apis/open-api-specs/utility-token-standard/v1/allocation-instruction-v1.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/allocation-instruction/v1/allocation-factory Get the factory and choice context for creating allocations using the `AllocationFactory_Allocate` choice. # Post apitoken standardv0registrars registryallocation instructionv2allocation factory Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registryallocation-instructionv2allocation-factory /registry/apis/open-api-specs/utility-token-standard/v1/allocation-instruction-v2.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/allocation-instruction/v2/allocation-factory Get the factory and choice context for creating allocations using the `AllocationFactory_Allocate` choice. Registries MAY limit the size of the allocations that they support. To ensure wide compatibility with apps, registries MUST support creating allocations that involve at most 25 transfer legs. In a worst case scenario this means supporting the creation of an allocation with: - 25 transfer legs - 25 distinct instrument ids - 50 distinct accounts - 100 distinct parties Registries MAY support larger allocations. # Post apitoken standardv0registrars registryallocationsv1 choice contextscancel Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registryallocationsv1-choice-contextscancel /registry/apis/open-api-specs/utility-token-standard/v1/allocation-v1.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/allocations/v1/{allocationId}/choice-contexts/cancel Get the choice context to cancel an allocation. # Post apitoken standardv0registrars registryallocationsv1 choice contextsexecute transfer Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registryallocationsv1-choice-contextsexecute-transfer /registry/apis/open-api-specs/utility-token-standard/v1/allocation-v1.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/allocations/v1/{allocationId}/choice-contexts/execute-transfer Get the choice context to execute a transfer on an allocation. # Post apitoken standardv0registrars registryallocationsv1 choice contextswithdraw Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registryallocationsv1-choice-contextswithdraw /registry/apis/open-api-specs/utility-token-standard/v1/allocation-v1.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/allocations/v1/{allocationId}/choice-contexts/withdraw Get the choice context to withdraw an allocation. # Post apitoken standardv0registrars registryallocationsv2 choice contextscancel Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registryallocationsv2-choice-contextscancel /registry/apis/open-api-specs/utility-token-standard/v1/allocation-v2.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/allocations/v2/{allocationId}/choice-contexts/cancel Get the choice context to cancel an allocation. # Post apitoken standardv0registrars registryallocationsv2 choice contextswithdraw Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registryallocationsv2-choice-contextswithdraw /registry/apis/open-api-specs/utility-token-standard/v1/allocation-v2.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/allocations/v2/{allocationId}/choice-contexts/withdraw Get the choice context to withdraw an allocation. # Post apitoken standardv0registrars registryallocationv2settlement factory Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registryallocationv2settlement-factory /registry/apis/open-api-specs/utility-token-standard/v1/allocation-v2.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/allocation/v2/settlement-factory Get the factory and choice context for settling allocations using the `SettlementFactory_SettleBatch` choice. Registries MAY limit the size of the settlement requests that they support. To ensure wide compatibility with apps, registries MUST support all settlement requests that involve at most 25 transfer legs. In a worst case scenario this means supporting a settlement request involving: - 25 transfer legs - 25 distinct instrument ids - 50 allocations - 50 distinct accounts - 100 distinct parties Registries MAY support larger settlement requests. # Post apitoken standardv0registrars registrytransfer instructionv1 choice contextsaccept Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registrytransfer-instructionv1-choice-contextsaccept /registry/apis/open-api-specs/utility-token-standard/v1/transfer-instruction-v1.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/transfer-instruction/v1/{transferInstructionId}/choice-contexts/accept Get the choice context to accept a transfer instruction. # Post apitoken standardv0registrars registrytransfer instructionv1 choice contextsreject Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registrytransfer-instructionv1-choice-contextsreject /registry/apis/open-api-specs/utility-token-standard/v1/transfer-instruction-v1.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/transfer-instruction/v1/{transferInstructionId}/choice-contexts/reject Get the choice context to reject a transfer instruction. # Post apitoken standardv0registrars registrytransfer instructionv1 choice contextswithdraw Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registrytransfer-instructionv1-choice-contextswithdraw /registry/apis/open-api-specs/utility-token-standard/v1/transfer-instruction-v1.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/transfer-instruction/v1/{transferInstructionId}/choice-contexts/withdraw Get the choice context to withdraw a transfer instruction. # Post apitoken standardv0registrars registrytransfer instructionv1transfer factory Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registrytransfer-instructionv1transfer-factory /registry/apis/open-api-specs/utility-token-standard/v1/transfer-instruction-v1.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/transfer-instruction/v1/transfer-factory Get the factory and choice context for executing a direct transfer. # Post apitoken standardv0registrars registrytransfer instructionv2 choice contextsaccept Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registrytransfer-instructionv2-choice-contextsaccept /registry/apis/open-api-specs/utility-token-standard/v1/transfer-instruction-v2.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/transfer-instruction/v2/{transferInstructionId}/choice-contexts/accept Get the choice context to accept a transfer instruction. # Post apitoken standardv0registrars registrytransfer instructionv2 choice contextsreject Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registrytransfer-instructionv2-choice-contextsreject /registry/apis/open-api-specs/utility-token-standard/v1/transfer-instruction-v2.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/transfer-instruction/v2/{transferInstructionId}/choice-contexts/reject Get the choice context to reject a transfer instruction. # Post apitoken standardv0registrars registrytransfer instructionv2 choice contextswithdraw Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registrytransfer-instructionv2-choice-contextswithdraw /registry/apis/open-api-specs/utility-token-standard/v1/transfer-instruction-v2.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/transfer-instruction/v2/{transferInstructionId}/choice-contexts/withdraw Get the choice context to withdraw a transfer instruction. # Post apitoken standardv0registrars registrytransfer instructionv2transfer factory Source: https://docs.digitalasset.com/api-reference/public/post-apitoken-standardv0registrars-registrytransfer-instructionv2transfer-factory /registry/apis/open-api-specs/utility-token-standard/v1/transfer-instruction-v2.yaml post /api/token-standard/v0/registrars/{registrarParty}/registry/transfer-instruction/v2/transfer-factory Get the factory and choice context for executing a direct transfer. # Post apiutilitiesv0registryburn mint instructionv0burn mint factory Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registryburn-mint-instructionv0burn-mint-factory /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/burn-mint-instruction/v0/burn-mint-factory Get the burn mint factory and choice context for burn and mint. # Post apiutilitiesv0registryburnv0offer Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registryburnv0offer /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/burn/v0/offer Get the factory and choice context for creating a burn offer. # Post apiutilitiesv0registryburnv0offer choice contextsaccept Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registryburnv0offer-choice-contextsaccept /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/burn/v0/offer/{burnOfferId}/choice-contexts/accept Get the choice context to accept and execute a burn offer. # Post apiutilitiesv0registryburnv0offer choice contextscancel Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registryburnv0offer-choice-contextscancel /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/burn/v0/offer/{burnOfferId}/choice-contexts/cancel Get the choice context to cancel a burn offer. # Post apiutilitiesv0registryburnv0offer choice contextsreject Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registryburnv0offer-choice-contextsreject /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/burn/v0/offer/{burnOfferId}/choice-contexts/reject Get the choice context to reject a burn offer. # Post apiutilitiesv0registryburnv0request Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registryburnv0request /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/burn/v0/request Get the factory and choice context for creating a burn request. # Post apiutilitiesv0registryburnv0request choice contextsaccept Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registryburnv0request-choice-contextsaccept /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/burn/v0/request/{burnRequestId}/choice-contexts/accept Get the choice context to accept and execute a burn request. # Post apiutilitiesv0registryburnv0request choice contextscancel Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registryburnv0request-choice-contextscancel /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/burn/v0/request/{burnRequestId}/choice-contexts/cancel Get the choice context to cancel a burn request. # Post apiutilitiesv0registryburnv0request choice contextsreject Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registryburnv0request-choice-contextsreject /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/burn/v0/request/{burnRequestId}/choice-contexts/reject Get the choice context to reject a burn request. # Post apiutilitiesv0registrymintv0offer Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registrymintv0offer /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/mint/v0/offer Get the factory and choice context for creating a mint offer. # Post apiutilitiesv0registrymintv0offer choice contextsaccept Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registrymintv0offer-choice-contextsaccept /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/mint/v0/offer/{mintOfferId}/choice-contexts/accept Get the choice context to accept and execute a mint offer. # Post apiutilitiesv0registrymintv0offer choice contextscancel Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registrymintv0offer-choice-contextscancel /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/mint/v0/offer/{mintOfferId}/choice-contexts/cancel Get the choice context to cancel a mint offer. # Post apiutilitiesv0registrymintv0offer choice contextsreject Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registrymintv0offer-choice-contextsreject /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/mint/v0/offer/{mintOfferId}/choice-contexts/reject Get the choice context to reject a mint offer. # Post apiutilitiesv0registrymintv0request Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registrymintv0request /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/mint/v0/request Get the factory and choice context for creating a mint request. # Post apiutilitiesv0registrymintv0request choice contextsaccept Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registrymintv0request-choice-contextsaccept /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/mint/v0/request/{mintRequestId}/choice-contexts/accept Get the choice context to accept and execute a mint request. # Post apiutilitiesv0registrymintv0request choice contextscancel Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registrymintv0request-choice-contextscancel /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/mint/v0/request/{mintRequestId}/choice-contexts/cancel Get the choice context to cancel a mint request. # Post apiutilitiesv0registrymintv0request choice contextsreject Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registrymintv0request-choice-contextsreject /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/mint/v0/request/{mintRequestId}/choice-contexts/reject Get the choice context to reject a mint request. # Post apiutilitiesv0registrytransferv0proof Source: https://docs.digitalasset.com/api-reference/registry/post-apiutilitiesv0registrytransferv0proof /registry/apis/open-api-specs/utility.yaml post /api/utilities/v0/registry/transfer/v0/proof Verify the outcome of a transfer of Registry Utility assets on Canton. Given an UpdateID and a Transfer Object, the service looks up the corresponding ledger transaction and verifies the transfer details against the on-chain events. The response status indicates the transfer outcome: - `Success`: The transfer was executed in the referenced transaction - `Pending`: The transfer instruction has been created but not yet settled - `Failure`: The transfer instruction was rejected or withdrawn by one of the parties If none of the above conditions are met, if the provided transfer details do not match the on-chain data, or if the original TransferInstruction contract cannot be retrieved, a `400` is returned. No further diagnostic information is included in the error response to prevent unintended disclosure of sensitive ledger data. # Covalidating Partner Onboarding Source: https://docs.digitalasset.com/covalidation/covalidator-onboarding The onboarding process consists of the following steps ```mermaid theme={null} flowchart TD A[Configure Your Validator Node] click A "covalidator-onboarding#1-configure-your-validator-node" " " B[Create GitHub App for Reading DAR Repository] click B "covalidator-onboarding#2-create-github-app-for-reading-dar-repository" " " C[Exchange Details and Configure and Install Your Covalidation Service] click C "covalidator-onboarding#3-exchange-details-and-configure-and-install-your-covalidation-service" " " A --> B B --> C ``` ## 1. Configure your Validator Node Create / configure the validator node which you will use as your covalidating node. If creating a new node, follow the [Canton Network Validator Onboarding Process](https://docs.canton.network/global-synchronizer/deployment/onboarding-process). ## 2. Create GitHub App for Reading DAR Repository Before deploying the service, first a GitHub App must be created within your organization's GitHub account in order to access the shared DAR repository. > **Important Note** > > Creating a GitHub App requires GitHub Organization Owner permissions. > > A single GitHub App can be reused for multiple Covalidation Service deployments within the same organization. ```mermaid theme={null} flowchart TD A[Create GitHub App in your organization] --> B[Share Your GitHub App Details with Primary Validator] B --> C[Primary Validator installs GitHub App into Organization of DAR repository and Provides Installation ID] ``` The GitHub App setup process entails: ### Create a GitHub App in your organization Navigate to: > **Organization Settings → Developer Settings → GitHub Apps** > Select **New GitHub App**. #### Configure the application Use the following settings. | Setting | Value | | -------------------------------- | ---------------------------------------------------------------------------- | | Name | ` Covalidation` | | Description | A description such as `Used by the Covalidation Service to synchronize DARs` | | Homepage URL | Your organization's website | | Expire user authorization tokens | Disabled | | Webhooks | Disabled | #### Repository Permissions Configure the following permissions. | Permission | Access | | ---------- | ------------ | | Contents | Read-only | | Webhooks | Read & Write | #### Installation Scope Select: > **Any account** Then create the application. *** #### Record Required Information After the application has been created, save the following values. | Item | Required For | | ----------- | ---------------------------- | | Public Link | Primary validator GitHub App | | App ID | Helm configuration | | Private Key | Kubernetes Secret | #### Generate Private Key Generate a **Private Key** and store it as a Kubernetes Secret in the namespace where the chart will be installed. Example: ```bash theme={null} kubectl create secret generic github-app-private-key \ --from-file=private-key.pem ``` *** ### Share Your GitHub App Details with Primary Validator After creating the GitHub App: 1. Send the **Public Link** to the primary validator. 2. Ask them to install the application into the DAR repository. 3. Request the **Installation ID** from the primary validator. ### Primary Validator installs GitHub App into Organization of DAR repository and Provides Installation ID Once installed, the primary validator will provide you the **Installation ID**, which is required when configuring the Helm chart. *** ## 3. Exchange Details and Configure and Install Your Covalidation Service * Gather details from the Primary Validator and Covalidating operator on DAR repository, GitHub App installation ID and participant IDs so that each co-validator can be configured correctly. * Configure and Install the Covalidation Service Helm Chart ### Install the Covalidation Service Helm Chart #### Setup Before installing Covalidation Service, ensure you have: * Access to your GitHub organization * A primary validator willing to share DARs * A Kubernetes cluster * A Kubernetes namespace for the deployment * Helm 3.x (> 3.17.0) * Kubernetes Secrets containing: * GitHub App private key * Participant OIDC client secret Deploy the service using Helm. ```bash theme={null} helm upgrade --install \ covalidation-service \ -n some-namespace \ -f values.yaml \ oci://europe-docker.pkg.dev/da-images/public/charts/covalidation-service:latest ``` *** #### Configuration A minimal configuration looks like the following. ```yaml theme={null} covalidator: dars: github: appID: installID: privateKey: secretKeyRef: name: github-app-private-key key: private-key.pem repo: owner: repo: # Optional: The branch and directory containing the dars # branch: <`main` by default> # dir: participant: id: oidc: oauthDomain: clientID: clientSecret: secretKeyRef: name: participant-oidc-secret key: client-secret # Optional: audience # audience: # Optional: scopes # scopes: # - endpoints: ledgerApi: participant.namespace:5001 adminApi: participant.namespace:5002 replication: participants: primary: # List other covalidator nodes (if any) covalidators: - monitoring: otel: endpointURL: # OPTIONAL: sync interval # syncInterval: # # Optional: frequency with which party topology events are synchronized # partyTopologyPolling: 30s # # # Optional: frequency with which package upload and vetting are synchronized # packagePolling: 5m # OPTIONAL: log level # log: # format: auto # level: debug ``` *** #### Configuration Reference ##### GitHub | Field | Description | | ------------------------- | ------------------------------------------------------- | | `appID` | GitHub App ID | | `installID` | Installation ID provided by the primary validator | | `privateKey.secretKeyRef` | Kubernetes Secret containing the GitHub App private key | *** ##### DAR Repository | Field | Description | | -------- | ------------------------------------------------- | | `owner` | GitHub organization containing the DAR repository | | `repo` | Repository name | | `branch` | Optional branch (defaults to `main`) | | `dir` | Optional directory containing DAR files | *** ##### Participant | Field | Description | | -------------- | --------------------------------------------------- | | `id` | Participant identifier | | `oauthDomain` | OIDC issuer URI | | `audience` | OIDC audience | | `scopes ` | OIDC scopes | | `clientID` | OIDC client ID | | `clientSecret` | Kubernetes Secret containing the OIDC client secret | | `ledgerApi` | Ledger API endpoint | | `adminApi` | Admin API endpoint | *** ##### Replication | Field | Description | | -------------- | -------------------------------------- | | `primary` | Primary validator participant ID | | `covalidators` | Additional covalidator participant IDs | *** ##### Monitoring | Field | Description | | ------------- | ---------------------------- | | `endpointURL` | OTEL monitoring URL and port | *** ##### Log | Field | Description | | -------- | --------------------------------------------- | | `format` | Format of the logger (text, json, auto) | | `level` | Level of logger (debug, info, warning, error) | *** ##### Sync Interval | Field | Description | | ---------------------- | -------------------------------------------- | | `partyTopologyPolling` | Interval for party topology sync | | `packagePolling` | Interval for package upload and vetting sync | *** ##### Kubernetes Secrets The chart expects existing Kubernetes Secrets. ##### GitHub Private Key ```yaml theme={null} privateKey: secretKeyRef: name: github-app-private-key key: private-key.pem ``` ##### Participant Client Secret ```yaml theme={null} clientSecret: secretKeyRef: name: participant-oidc-secret key: client-secret ``` *** #### Deployment Flow ```mermaid theme={null} sequenceDiagram participant GH as GitHub participant Repo as DAR Repository participant Service as Covalidation Service participant Participant Service->>GH: Authenticate using GitHub App GH-->>Service: Installation Token Service->>Repo: Read DARs Repo-->>Service: DAR Files Service->>Participant: Upload DARs Participant-->>Service: Confirmation ``` #### Uninstall Remove the deployment with Helm. ```bash theme={null} helm uninstall covalidation-service -n some-namespace ``` This removes the Kubernetes resources created by the chart but does not delete Kubernetes Secrets or the GitHub App. #### Release Notes Notable changes to the Helm chart are documented below. *** ## 2026-08-13 ### 0.8.1 * **Party Topology Polling** Change party topology polling default to 30s, and make it configurable through `syncInterval` configuration in helm chart. * **Party Topology Acceptance** Only auto-accept new party topology onboardings, but do not accept topology changes for existing parties. * **Multi-platform Docker Image Support** The produced image is now multi-platform and can run on either ARM or AMD Linux platforms. # Monitoring Source: https://docs.digitalasset.com/covalidation/monitoring Monitoring and Alerting Best Practices ## Monitoring The Covalidation Service contains metrics/traces out of the box to support monitoring. This behavior is enabled by adding the following block to your configuration: ```yaml theme={null} monitoring: otel: endpointURL: ``` The `endpointURL` field is an OpenTelemetry (OTEL) URL and port for sending metrics and traces. Different solutions are available to configure an OTEL endpoint, i.e. Datadog-agents. Logs in the Covalidation Service can be made more verbose by adding the following to your configuration: ```yaml theme={null} log: level: debug ``` It is good practice to monitor for things like: * Kubernetes liveness/readiness probes for the covalidation-service are passing * No ERROR log entries observed * Log indicating last checkpoint processed is progressing *** ## Metrics The covalidation service offers metrics out of the box for both successful and failing operations. Metrics embedded in the code include: * covalidation.error: Metric counting all the errors encountered during the various syncs that occur during the covalidation process * covalidation.github.dars\_uploaded: Metric measuring the total sum of dars uploaded to participant * sync: Metric measuring the total number of sync attempts by the covalidation service * offset: Metric capturing the current highest offset of the ledger API Additionally, a `sync` trace is also included to capture a sync and raise any errors that may occur during the three covalidation processes: * `sync`: Overarching trace that includes 3 subtraces for the 3 processes of covalidation * `github`: Trace for the `Github` dar upload service * `vetter`: Trace for the `Vetter` package vetting service * `partysyncer`: Trace for the `Partysyncer` transaction sync service Any errors that occur during one of the services are captured as a span event and appear under the respective trace to help with debugging service issues. *** ## Alerts We recommend creating the following alerts for overall infrastructure and application health: * Memory usage over time: Set alert on memory usage of the node the service is hosted on * Kubernetes Deployment Replica Pods: Ensure pods are READY and healthy * Covalidation Error Rate Over Time: Change in error rate in the previous X amount of minutes compared to the last Y minutes *** # Overview Source: https://docs.digitalasset.com/covalidation/overview Onboarding process, architecture, security, and support. ## Overview The **Covalidation Service (CVS)** is a managed infrastructure solution for the Canton Network that eliminates single points of failure for wallets and applications. By multi-hosting parties and distributing validation responsibilities across a redundant, high-availability network, CVS helps ensure services remain secure, available, and resilient without requiring organizations to operate every aspect of the infrastructure themselves. *** ## Key Operational and Security Benefits The Covalidation Service is designed around resilience, redundancy, and operational security. Transactions require confirmation from multiple validation nodes, protecting operations against individual node failures or compromises. Validators are deployed across multiple cloud providers and infrastructure environments to reduce operational risk and improve availability. Historical ledger data is retained for **30 days**, enabling rapid recovery following infrastructure failures or disaster recovery events. All validator cryptographic keys are managed using a Key Management Service (KMS), reducing operational risk and improving security. *** ## Getting Started To join the Covalidation network, please contact Digital Asset. *** ### Onboarding and Operational FAQ There are typically three node operators involved in the **Covalidation Service** offering. * **Primary Validator** - Follow the Onboarding a Primary Node steps to get started. This entity will be onboarding parties, submitting transactions, and authoring and vetting the DARs made available through the DAR repository. * **Covalidating Partner** and **Digital Asset** - Follow the Onboarding a Covalidating Node steps to get started. Setting up DAR Repository and Primary Validator Node Setting up Covalidating Node and GitHub App to access DAR Repository Guidance including recommended metrics and alerting thresholds. Frequently asked troubleshooting guidance for Covalidation Service operators. ## Support If you encounter an issue or have a technical question, submit a support request through the Digital Asset Support portal. # Primary Validator Onboarding Source: https://docs.digitalasset.com/covalidation/primary-onboarding Instructions for Onboarding the Primary Validator that makes use of the Covalidation Service. # Onboarding (Primary Validator) The onboarding process consists of the following high-level steps. ```mermaid theme={null} flowchart TD A[Choose Third Node Operator] click A "primary-onboarding#1-choose-a-third-node-operator" " " B[Configure the DAR Repository] click B "primary-onboarding#2-configure-the-dar-repository" " " C[Configure your Validator Node] click C "primary-onboarding#3-configure-your-validator-node" " " D[Exchange Configuration Details] click D "primary-onboarding#4-exchange-configuration-details" " " E[Configure Party Topology] click E "primary-onboarding#5-configure-party-topology" " " F[Validate Transactions] click F "primary-onboarding#6-validate-transactions" " " G[Manage Ongoing Configuration] click G "primary-onboarding#7-manage-ongoing-configuration" " " A --> B B --> C C --> D D --> E E --> F F --> G ``` ## 1. Choose a Third Node Operator * Select a third-party node operator that will host parties on an additional covalidating node. ## 2. Configure the DAR Repository * Create and configure access to a shared repository from which all participating covalidators synchronize DARs. Commit key DARs to this repository. > **Important** > > Configuring a GitHub App requires GitHub Organization Owner permissions. ```mermaid theme={null} flowchart LR A[Create a GitHub Repo] --> B[Install GitHub Apps from URLs provided by Covalidators] ``` ### Create a GitHub Repo * Create a GitHub repo that will hold all your DARs * Separate by directories aligned with environments (DevNet, TestNet, MainNet) ### Install GitHub Apps from URLs provided by Covalidators * Paste in URL provided by each Covalidator * Choose `Configure` from the GitHub UI (login as appropriate) * Choose GitHub Organization to install to -- the organization where you have created your DAR repo. * Grant Repository Access to your DAR repository * Take note of the `Installation ID` from the URI and share this with the covalidator -- it is the last portion of the URL ([https://github.com/organizations/YOURORG/settings/installations/INSTALLATION\_ID](https://github.com/organizations/YOURORG/settings/installations/INSTALLATION_ID)) * Provide the details of your repo to your partner / DA * Installation ID * GitHub Org Name * GitHub Repo Name * Path to DARs (by environment) ## 3. Configure your Validator Node * Create / configure the validator node which you will use as your primary node. ### Upload and Vet DARs * Ensure all DARs are uploaded from your DAR Repository. Vet the DARs which should be active on this node. ## 4. Exchange Configuration Details * Exchange DAR repository details and your participant ID details so that each co-validator can be configured correctly. * Additionally, take note of the participant IDs of the covalidating nodes, as you will need these details when onboarding parties. ## 5. Configure Party Topology * Once all validators are online and configured, create a topology transaction to multi-host a party -- covalidating nodes running the covalidation service will automatically approve the transaction if it matches the agreed-upon topology. ## 6. Validate Transactions * When a multi-hosted party submits a transaction, confirmation nodes independently validate the transaction against the synchronized DARs before confirming it. ## 7. Manage Ongoing Configuration * As applications evolve, new DARs and topology changes can be introduced through the established governance process. # Troubleshooting Source: https://docs.digitalasset.com/covalidation/troubleshooting Troubleshooting and FAQ for common operational issues ## Unable to authenticate with GitHub Verify: * GitHub App ID * Installation ID * Private key Secret * The application has been installed into the correct repository *** ## DARs are not synchronizing Verify: * Repository owner and name * Branch and directory (if configured) * Repository permissions * GitHub App installation *** ## External parties are not being onboarded Verify: * Correct Kubernetes secret for connectivity to Ledger API * Ledger API endpoint * Admin API endpoint * Participant IDs in configuration file are correct * 3 participants have been referenced in the onboarding request * Onboarding request had expected threshold (2 of 3) *** ## Unable to connect to the participant Check: * Ledger API endpoint * Admin API endpoint * OIDC issuer configuration * Client credentials * Network connectivity *** ## Security Considerations * Store all credentials in Kubernetes Secrets. * Do not commit GitHub private keys to version control. * Grant only the minimum required GitHub permissions. * Rotate GitHub App keys periodically. * Limit Kubernetes Secret access using RBAC. *** # General guidance Source: https://docs.digitalasset.com/registry/apis/daml-api This section aims to outline the supported integration modes for apps that wish to compose with the Registry App directly on the Daml level. ## General guidance We recommend that your Daml code only depends on Daml interface packages, rather than packages depending on concrete template implementations. This will ensure that the release cadence for your application is decoupled from the release cadence of the Registry App. Dependencies on concrete template implementations can be used only for code that runs as a one-off during app initialization. ## CIP 56 for transfers and DvPs The Registry App is fully Token Standard (CIP-56) compliant. You can use the Daml interfaces defined as part of CIP-56 in order to execute transfers and allocations from your Daml code. More details can be found in the [Token Standard API section](/registry/apis/token-standard). ## Custom mint / burn workflows We offer an integration point for tokenizers that wish to implement [custom mint and burn workflows](/registry/apis/daml-api/custom-burn-mint) using Daml. # Custom burn / mint workflows Source: https://docs.digitalasset.com/registry/apis/daml-api/custom-burn-mint This is done by implementing the [Splice BurnMintFactory interface](https://github.com/canton-network/splice/blob/main/daml/splice-api-token-burn-mint-v1/daml/Splice/Api/Token/BurnMintV1.daml#L12) in the `AllocationFactory` template of the Registry App. An off-ledger endpoint provides the necessary contract disclosures in order to execute the `BurnMintFactory_BurnMint` choice. See the [Open API spec](/registry/apis/api-specs/utility) for more details. # Operator Backend API Source: https://docs.digitalasset.com/registry/apis/operator-backend-api The Operator backend exposes a set of publicly accessible endpoints serving information essential to the fulfillment of the Registry Daml workflows. It is used by the Registry UI to source reference information, such as the party identifier of the operator, as well as the set of available instruments. It is used by wallets and third-party apps to source off-ledger information to advance token standard workflows (through the use of [explicit contract disclosure](https://docs.digitalasset.com/build/3.3/sdlc-howtos/applications/develop/explicit-contract-disclosure.html)). ## Base URLs ```text theme={null} https://api.utilities.digitalasset.com ``` ```text theme={null} https://api.utilities.digitalasset-staging.com ``` ```text theme={null} https://api.utilities.digitalasset-dev.com ``` # Token Standard APIs (CIP 56 / CIP 112) Source: https://docs.digitalasset.com/registry/apis/token-standard The Registry App supports the Canton Network Token Standard, as defined in [CIP-56](https://github.com/canton-foundation/cips/blob/main/cip-0056/cip-0056.md) and [CIP-112](https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md). ## App / Wallet providers integration App providers and Wallet providers wishing to transact Registry holdings as part of their application's workflows must make sure that * all supported versions of the `utility-registry-app-v0` DARs are installed on their node * the application is configured to source off-ledger data from the [token standard endpoints](/registry/apis/token-standard/off-ledger-api) The Registry dApp UI supports the `AllocationRequest` standard to read allocation requests from other applications and create corresponding `Allocations`. You can download the bundle containing the DAR files from [the Releases page](/registry/releases/daml-models). ## Instrument admin actions Instrument admins who wish to enable token-standard transfers for the tokens they manage must ensure the following contracts have been created | Contract | Purpose | | ------------------- | ------------------------------------------------------------------ | | `AllocationFactory` | Enables users to create and settle transfer offers and allocations | | `TransferRule` | Validates requirements are met upon transfer execution | Both contracts can be instantiated and archived using the dApp UI. ## Support of Token Standard V2 (CIP-112) for a given instrument admin While all supported versions of the Registry App implement the CIP-56 interfaces, support for CIP-112 has only been introduced starting with version **0.14** of the app. A given Registry instrument admin supports CIP-112 only if they have installed the 0.14 DARs. As an app or wallet provider, you can use the `/registry/metadata/v1/info` token metadata endpoint in order to verify whether a given tokenizer supports the CIP-112 interfaces, or whether a fallback to CIP-56 is needed. ```json theme={null} { "adminId": "registrar::12205dd5bd685449653161d47d2a7cb01c25d5b0a02dab5c79cafc8dafd811c79895", "supportedApis": { "splice-api-token-transfer-instruction-v2": 1, "splice-api-token-holding-v2": 1, "splice-api-token-transfer-instruction-v1": 1, "splice-api-token-allocation-instruction-v2": 1, "splice-api-token-metadata-v1": 1, "splice-api-token-allocation-v2": 1, "splice-api-token-allocation-request-v1": 1, "splice-api-token-allocation-v1": 1, "splice-api-token-holding-v1": 1, "splice-api-token-allocation-instruction-v1": 1 } } ``` If the instrument admin has not installed the 0.14 DARs, the response does not include the v2 interfaces: ```json theme={null} { "adminId": "registrar::12205dd5bd685449653161d47d2a7cb01c25d5b0a02dab5c79cafc8dafd811c79895", "supportedApis": { "splice-api-token-transfer-instruction-v1": 1, "splice-api-token-metadata-v1": 1, "splice-api-token-allocation-request-v1": 1, "splice-api-token-allocation-v1": 1, "splice-api-token-holding-v1": 1, "splice-api-token-allocation-instruction-v1": 1 } } ``` # Compatibility with V1 wallets on old Registry versions Source: https://docs.digitalasset.com/registry/apis/token-standard/compatibility-v1-wallets CIP-112 support was introduced with version `0.14` of the Registry App. This page outlines potential compatibility issues when interacting with wallets on older Registry DAR versions. This is an additional aspect to the [compatibility rules](https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md#51-compatibility-rules) outlined in the CIP text. ## Account selection In CIP-112, transfers can be made from and to a specific holder account. The account identifier is represented as a textual `label` field on the `Holding` contract. A user of a Token Standard V2 compatible wallet can therefore have multiple Holding UTXOs with different labels for a given instrument. For instance: | Holding UTXO | Instrument | Amount | Label | | :----------- | :--------- | :----- | :---------- | | `cid1` | INST | 100 | `` | | `cid2` | INST | 100 | `` | | `cid3` | INST | 100 | `account-1` | If the user now wishes to transfer 150 units to a receiver who uses a V1 wallet on an older Registry version (say, 0.13), the input Holding UTXOs need to be selected carefully. This is because **older Registry models expect input holdings to have consistent labels**, failing with a Daml interpretation error otherwise. | Selected input UTXOs | Registry version of the receiver | Outcome | | :------------------- | :------------------------------- | :--------------------------------------------- | | `[cid1, cid2]` | 0.13 | Success | | `[cid1, cid3]` | 0.13 | Failure due to mixed input labels | | `[cid1, cid3]` | 0.14 | Success, as 0.14 can handle mixed input labels | ### Recommended mitigation step The two mitigation options to circumvent this compatibility issue are to Filter input Holding UTXOs to ensure the provided inputs have consistent labels. Merge input Holding UTXOs to obtain an output Holding with a sufficiently large amount. # Token Standard off-ledger API Source: https://docs.digitalasset.com/registry/apis/token-standard/off-ledger-api In order to interact with the Registry App over [CIP-56](https://github.com/canton-foundation/cips/blob/main/cip-0056/cip-0056.md) or [CIP-112](https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md), certain contract disclosures need to be sourced via an off-ledger API. These endpoints are specific to each instrument admin, and are exposed with the following base URL: ```text theme={null} https://api.utilities.digitalasset.com/api/token-standard/v0/registrars/ ``` ```text theme={null} https://api.utilities.digitalasset-staging.com/api/token-standard/v0/registrars/ ``` ```text theme={null} https://api.utilities.digitalasset-dev.com/api/token-standard/v0/registrars/ ``` where `` is the party identifier of the target instrument admin. The instrument admin for `USDCx` is the party `decentralized-usdc-interchain-rep::12208115f1e168dd7e792320be9c4ca720c751a02a3053c7606e1c1cd3dad9bf60ef`. Hence, the instrument metadata endpoint for `USDCx` on MainNet can be retrieved using the following URL [https://api.utilities.digitalasset.com/api/token-standard/v0/registrars/decentralized-usdc-interchain-rep::12208115f1e168dd7e792320be9c4ca720c751a02a3053c7606e1c1cd3dad9bf60ef/registry/metadata/v1/instruments/USDCx](https://api.utilities.digitalasset.com/api/token-standard/v0/registrars/decentralized-usdc-interchain-rep::12208115f1e168dd7e792320be9c4ca720c751a02a3053c7606e1c1cd3dad9bf60ef/registry/metadata/v1/instruments/USDCx). ## Instrument admin discovery There is currently no standardized way to discover the set of instrument admins, and their respective instruments. # Allowlist Source: https://docs.digitalasset.com/registry/features/allowlist Implement flexible, credential-based access controls to securely authorize asset participants throughout their lifecycle. Many digital assets require issuers to stringently control who can participate throughout the asset lifecycle. Whether onboarding investors to a tokenized fund, restricting ownership of regulated securities, or authorizing specific counterparties to mint and redeem stablecoins, issuers need adaptive, policy-driven access controls. The **DA Registry** provides configurable, credential-based allowlists that enable issuers to define precisely who is authorized to hold, receive, transfer, mint, or redeem an asset. Rules are configured independently for each instrument, allowing you to seamlessly tailor unique compliance policies across diverse asset classes. **The On-Chain Difference:** Instead of relying on brittle application-layer logic or manual back-office checks, the DA Registry embeds authorization directly into the asset model. The protocol automatically verifies that the acting party possesses the required credentials *before* a transaction executes, guaranteeing deterministic policy enforcement. ## Key Capabilities By embedding configurable authorization policies directly within the asset lifecycle, the DA Registry achieves "Compliance by Design" without sacrificing operational efficiency. Configure independent authorization requirements for separate phases of the lifecycle, including holding, minting, and redeeming assets. Dynamically verify permissions using highly configurable credential requirements tailored to each specific instrument. Manage allowlists directly or delegate administrative privileges to trusted compliance, KYC, and identity providers. Integrate identity verification while fully leveraging Canton's selective disclosure and privacy model to keep sensitive data protected. ## Lifecycle Authorization Allowlists ensure that every critical interaction with an asset is bound by the instrument's specific compliance requirements: | Operation | Enforcement Behavior | | :---------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- | | **Holding & Receiving** | Restricts asset ownership exclusively to pre-vetted, authorized accounts or wallets. | | **Transfers** | Intercepts movements to ensure both the sender and the receiver maintain valid, unexpired credentials at the exact moment of transfer. | | **Minting & Redeeming** | Limits token creation and destruction capabilities to authorized institutional counterparties, protecting stablecoin supply chains or fund structures. | ### Delegated Administration To alleviate the operational burden on issuers, allowlist management can be securely delegated to trusted third-party compliance providers. This enables organizations to natively integrate existing KYC/AML frameworks and investor onboarding workflows while maintaining an unalterable, on-ledger record of all authorization decisions. # Asset Recovery Source: https://docs.digitalasset.com/registry/features/asset-recovery Enabling lifetime asset access for you and your asset holders when everything else failed The **DA Registry Asset Recovery** is a service and operational feature offered to **Asset Issuers** and their **Holders**. It allows for the secure "recovery" of asset holdings from a lost or inactive node to a new node for the same `partyID`. This service ensures that DA Registry instruments remain accessible even if the technical means of access (such as a participant node) are permanently lost. ## Key Functions * **Asset Portability:** Moves asset balances from an inaccessible node to a newly verified node. * **Issuer-Led Governance:** Provides Asset Issuers with the authority to validate and allow recovery requests, maintaining the integrity of the ledger. * **Auditability:** Every recovery action is recorded on the ledger, providing a transparent audit trail for compliance and regulatory purposes. ## How the Recovery Process Works This service restores access to digital assets and identity if the original system (source node) becomes inaccessible. It migrates a user’s "wallet" and active holdings to a healthy target node without requiring the failed node to be online. The system creates a replica of the user’s digital identity on a new "target" node. This is performed using a secure setup that does not require communication with the original, potentially broken node. The service gathers a complete list of the user’s current holdings and active contracts—known as the **Active Contract Set (ACS)**—from the system operator. These records are then imported directly into the new node. To ensure a clean handoff, the original node is confirmed as disconnected from the network. This ensures no conflicting activity can occur during the migration. Once the identity and assets are moved, the new node is granted the legal and technical rights to act on behalf of the user. This is finalized by the holder signing with their private key. The system performs automated tests to confirm all migrated assets arrived safely. The user can then immediately begin performing new actions, such as minting or transferring tokens, from their new node. > **Final State:** After recovery, the new node functions exactly like the old one, containing both the original migrated assets and any new assets created post-recovery. ### What the Service Does for You If you lose access to your node or wallet due to hardware or infrastructure failure, but still possess your **private key**, you do not lose your underlying assets. The Recovery Service allows you to transition your holdings and `partyID` to a new node. ### How to Access the Service **Prerequisite:** You must be in possession of your private key. * **Step 1:** Reach out to your Asset Issuer. * **Step 2:** Submit a Recovery Request for your DA Registry Asset. * **Step 3:** Verify your identity with the Issuer. * **Step 4:** The Asset Issuer will coordinate with the Registry Operator to initiate the party and holdings replication. * **Step 5:** Follow instructions to recover access via a new node and validate your holdings. ### What the Service Does for You As an Issuer, you are responsible for the lifecycle of the assets you create. This service provides the tools to support your holders during technical failures, ensuring high levels of asset safety. ### How to Manage Recovery * **Step 1:** Receive recovery requests and perform off-ledger checks (identity verification, legal standing). * **Step 2:** Validate that for a given `partyID`, the holder is in possession of the necessary private keys. * **Step 3:** Align with the holder and the Registry Operator on the target node infrastructure. * **Step 4:** Provide holders with prepared recovery tooling; holders execute the workflow by signing with their private key. ## Frequently Asked Questions (FAQ) **Q: Can a Holder initiate a recovery without the Issuer?** **A:** No. To maintain security, the Registry only accepts verified requests from Asset Issuers. **Q: Do I need my original (failed) node to be online to start a recovery?** **A:** No. The service leverages **offline external party replication**. **Q: Where does my asset data come from if my node is broken?** **A:** Your Active Contract Set (ACS) is exported directly from the **Registry Operator**. **Q: How do I know the recovery was successful?** **A:** The process includes a mandatory validation phase. Once moved, you should run integration tests to validate that all functions are active. # Asset Lifecycle Workflows Source: https://docs.digitalasset.com/registry/features/asset-workflows Understand how the DA Registry enables Registrars to configure instruments, manage token supply and execute compliant transfers. The **DA Registry Workflows** provide a structured, permissioned framework for managing digital assets throughout their lifecycle. Operating on the Canton Network Token Standard, these workflows automate compliance checks and coordinate multi-party actions seamlessly. ## Capabilities Overview The DA Registry provides four primary capabilities to help you manage digital assets while ensuring compliance and operational control. Define the identity of an asset and establish the precise credential rules required to hold, mint, or burn its tokens. Increase an instrument's supply via a secure request-and-verify workflow that requires registrar approval. Permanently retire tokens from circulation to manage redemptions or contract supply safely. Move assets between authorized parties using either explicit multi-party confirmation or automated pre-approvals. ## Instrument Configuration & Compliance Before any token operations can occur, an authorized party with the **Registrar** role must establish an `InstrumentConfiguration`. This contract serves as the regulatory template for the asset. ### Key Operational Benefits: * **Rule Enforcement:** Define specific **Holder** and **Issuer** credential requirements. The ledger automatically enforces these rules, ensuring that only verified parties can interact with the asset. * **Legacy System Mapping:** Optionally include traditional identifiers such as **ISIN** or **CUSIP** to streamline reconciliation with external financial systems. * **Transparent Ruleset:** Once created, configurations are explicitly disclosed to the network, ensuring all participants operate under identical compliance parameters. **Automated Guardrails:** If a user does not possess the credentials specified in the instrument configuration, the system will block them from holding or transferring the token at the ledger level. ### Accounts & Labels The holding label corresponds to the account ID field in the Token Standard v2 holding view (also encoded in the meta field of Token Standard v1 holding view). Labels are used to identify holdings across workflows. * **Mint:** the receiver label sets the account ID of the newly minted holding. * **Burn:** the sender label identifies the account to burn from. * **Transfer:** the sender label identifies the account to send from, and the receiver label is used to set the account ID on the received holding. * **Direct pre-approvals:** the receiver label must be empty (`""`) for the pre-approval to take effect. For any workflow where input holdings are provided, the sender label may be specified. If no label is specified, it defaults to the empty string (`""`). The receiver label can similarly be specified in workflows with output holdings. Output holdings receive the specified label, or default to the empty string (`""`) if unspecified. The input holdings may originate from any account and are faded in to the specified sender account before the burn, transfer, or allocation is executed. This fade-in behavior is reflected in transaction history v2, which logs the account-level movement: first the fade-in to the sender account, then the operation to the destination. Each application is responsible for filtering which input holdings to provide. The Registry App UI enforces a strict filtering of input holdings to match the sender label specified. ## Supply Management (Mint & Burn) To maintain precise control over token economics, the supply of any instrument can be adjusted using a secure **Request/Accept** architecture. This prevents unauthorized issuance or accidental supply inflation. **Safely expand asset supply.** An authorized party requests a specific mint volume, detailing the instrument, registrar party, target amount, and target label (account ID) for the minted holding. The system automatically verifies that the requester holds valid **Instrument Issuer** credentials as defined by the instrument's configuration. The Registrar reviews the request. Upon acceptance, the tokens are generated and credited to the requester. If rejected, the offer is voided. *Requesters retain the ability to cancel a mint request at any time prior to registrar acceptance.* **Reduce supply and manage redemptions.** An authorized issuer requests to remove a designated volume of tokens currently in their possession, detailing the instrument, registrar party, burn amount, and sender label (account ID) for the account to burn from. To maintain balance sheet integrity, the targeted tokens are immediately **locked** on the ledger, preventing them from being traded or moved while the burn is pending. Once the Registrar accepts the request, the tokens are permanently removed from circulation. If rejected or canceled, the lock is released immediately. ## 💸 Compliant Token Transfers Moving assets between participants can be adapted to fit different operational velocities, depending on the relationship and trust level between counterparties. ### Transfer Methods Designed for transactions requiring explicit bilateral consent. * **Sender and Receiver Labels:** The sender label specifies the account to send from, and the receiver label sets the account ID on the received holding. * **Asset Locking:** When a sender initiates a transfer, the required tokens are automatically selected and locked, preventing double-spending. * **Bilateral Control:** The receiver must explicitly accept the transfer for ownership to change. If the receiver rejects the offer, or if the sender withdraws it before acceptance, the tokens are safely unlocked and returned to the sender. Optimized for high-frequency operations or automated settlement pipelines. * **Sender and Receiver Labels:** The sender label specifies the account to send from. To enable pre-approvals, the receiver label must be set to the empty string (`""`), otherwise the transfer defaults to standard offer/accept. * **Proactive Authorization:** A receiving party can set up a `TransferPreapproval` contract ahead of time for up to 10 specific instrument IDs (or all instruments managed by a specific admin). * **Straight-Through Processing:** When a sender initiates a transaction that matches a valid pre-approval, the system bypasses the manual acceptance step entirely. The transfer settles instantly and updates token ownership in real-time. **Transfer Prerequisites:** For any transfer workflow to succeed, a valid `TransferRule` must be active, and both the sending and receiving parties must meet the **Instrument Holder** credential requirements established during instrument configuration. # Blocklist Source: https://docs.digitalasset.com/registry/features/blocklist Enforce real-time compliance, AML, and sanction policies directly within your digital asset infrastructure. As digital assets integrate deeper into global financial systems, relying solely on manual operational processes is no longer sufficient. Modern regulatory frameworks expect compliance controls to be technically enforceable and protocol-native rather than operational afterthoughts. The **Registry App** provides configurable, protocol-native blocklists that empower issuers to immediately restrict specific parties from interacting with an asset. Compliance policies are consistently enforced across every lifecycle workflow—guaranteeing that bad actors are stopped before a transaction can even clear. **The On-Chain Difference:** Unlike traditional tokenization platforms that rely on retrospective, off-chain monitoring and manual intervention, the DA Registry embeds compliance directly into the asset model. Every transaction is validated *before* execution. ## Key Capabilities By building compliance directly into the asset lifecycle, the Registry App minimizes operational friction while meeting strict institutional standards. Compliance policies are executed directly by the smart contract logic, eliminating the risk of operational bypass or human error. Transactions that violate configured policies fail automatically prior to execution, ensuring bulletproof rule enforcement. Every compliance decision, blocklist modification, and asset operation is recorded permanently on-ledger for an unalterable audit trail. Enforcement seamlessly respects Canton's privacy model, ensuring selective disclosure capabilities protect sensitive data. ## Lifecycle Coverage Blocklists are comprehensively integrated across the asset lifecycle. The Registry App ensures that compliance checks are not limited to standard transfers, but span all critical token actions: | Operation | Enforcement Behavior | | :------------ | :---------------------------------------------------------------------------------------------------------- | | **Minting** | Prevents blocklisted or unsanctioned addresses from initiating or receiving newly issued assets. | | **Transfers** | Intercepts peer-to-peer, exchange, or smart contract movements involving restricted entities. | | **Burning** | Restricts asset redemption or lifecycle termination events if the holding party is under a regulatory hold. | **Risk Mitigation:** Shifting from reactive monitoring to proactive, on-ledger validation completely eliminates the "settlement window risk" where compliance violations traditionally occur. # Proof of Transfer Source: https://docs.digitalasset.com/registry/features/proof-of-transfer Independent and indisputable transaction verification for privacy-enabled assets on Canton issued through the DA Registry. ## Overview The **Proof of Transfer** service is a specialized core feature designed to verify the definitive outcome of asset transfers on the Canton Network for assets issued through the DA Registry. The service processes two specific cryptographic elements, an `UpdateID` and a structured `Transfer Object` (provided via an exchange platform transaction history detail view or extracted directly from a wallet) and returns an immutable network-verified status response via the **DA Registry API**. This functionality can be directly integrated in any Canton Network Explorer or function as a standalone web interface, enabling direct verification without compromising decentralized ledger integrity. ## Why Is It Critical? Privacy-enabled assets on the Canton Network require a specialized verification paradigm to balance regulatory transparency with confidentiality. * **The Privacy Paradox:** Users must have a reliable method to prove transaction completions, yet traditional public block explorers expose sensitive counterparty data and corporate balance sheets. This service validates the true transaction state while preserving complete party anonymity. * **Market Access & Token Listings:** Providing an independent proofing mechanism satisfies strict compliance, clearing, and auditing standards. It directly addresses the core technical dependencies required to clear the critical path for listing privacy-preserving assets (such as **USDCx**) on Centralized Exchange (CEX) platforms. ## For Whom Is It Built? This framework serves a dual-sided ecosystem to establish external network trust independent of an intermediary's internal database reporting: Provides digital asset platforms with an automated, low-overhead method to supply their users with verifiable network receipts, accelerating regulatory alignment and clearing asset listing blockers. Allows end-users performing incoming or outgoing network transactions to independently confirm asset settlement status, completely free of any single-entity reliance. ## High-Level Operational Flow The lifecycle of a transfer proof moves seamlessly from initial on-chain execution to front-end status confirmation: The user executes an incoming or outgoing asset transfer within their account interface (CEX or Wallet). The transaction history engine packages the unique `UpdateID` and corresponding `Transfer Object` payload data, making it readily available for the customer to copy. The customer follows an embedded referral link directly from their transaction details to the verification interface. The user submits the parameters through a Canton Network Explorer, prompting the underlying **DA Registry API** to cross-reference the on-chain state and output a deterministic status. ### Flow Diagram ```mermaid placement="bottom-left" actions={true} theme={null} %%{init: {'flowchart': {'defaultRenderer': 'elk'}}}%% flowchart LR A([Start: Customer Request]) --> B[Platform Builds History
w/ UpdateID & Transfer Object] B --> C[Customer Navigates
to Proofing Service Link] C --> D{Verification UI Layer} D -->|Option A| E[Network Explorer Integration] D -->|Option B| F[Standalone Proofing UI] E --> G[DA Registry API Service] F --> G G --> H[Customer Confirms &
Submits Transfer Object] H --> I[Service Processes On-Chain Lookup] I --> J{Final Status Returned} J --> K[Success] J --> L[Failure] J --> M[Pending] J --> N[Error] style K fill:#2ecc71,stroke:#27ae60,color:#fff style L fill:#e74c3c,stroke:#c0392b,color:#fff style M fill:#95a5a6,stroke:#7f8c8d,color:#fff style N fill:#e67e22,stroke:#d35400,color:#fff ``` ## Guides & Integration Enable Proof of Transfer, so that you establish indisputable clarity about transfer outcomes on Canton. Expose the functionality in your update ID detail view to provide a high value capability to the ecosystem. # Quickstart Source: https://docs.digitalasset.com/registry/get-started/quickstart In order to onboard as a Registry Provider, the prerequisites detailed below must be completed. ## Prerequisites Use of the DA Registry requires a commercial agreement with Digital Asset. The agreement governs access to DA Registry, licensing, support, and any applicable commercial terms. For licensing and pricing information, please [contact Digital Asset](https://www.digitalasset.com/contact-us). This step can be skipped if you are planning to access the [DA Registry](https://registry.app.digitalasset.com/) with an authorized partyID via a CIP-103 compliant wallet.  Deploy and operate a validator node and complete the required Canton Network onboarding process. Access to the [DA Registry application packages (DARs)](/registry/releases/daml-models) is provided as part of the technical onboarding documentation. For infrastructure and validator setup instructions, see the Canton Network documentation. To use a featured party with the DA Registry, the party must configure a static sharing of Traffic-Based App Rewards according to the applicable commercial agreement. This configuration is required to maintain reward-sharing arrangements under the Canton Network tokenomics. The documentation for the [Canton setup can be found here](https://docs.canton.network/global-synchronizer/splice-fundamentals/reward-sharing#reward-sharing). The Registry User Interface supports the CIP-103 dApp connectivity standard. To access the [DA Registry dApp UI](https://registry.app.digitalasset.com/), connect your Provider party or any other authorized party using a CIP-103 compliant wallet. You can either: * Use an existing CIP-103 compliant wallet provider, or * Deploy the [Wallet Gateway](https://github.com/canton-network/wallet/tree/main/wallet-gateway/remote) within your own infrastructure and connect it to your participant node. This enables users to securely authenticate and interact with the [DA Registry dApp UI](https://registry.app.digitalasset.com/) directly from their wallet. A Provider Service represents the on-ledger contract between Digital Asset and your organization's Registry infrastructure and enables you to onboard registrar parties and administer Registry services. Provider Services can be requested directly through the Registry User Interface. Screenshot 2026 07 09 At 11 46 47 Before submitting a Provider Service request, ensure that the following prerequisites have been completed: * A commercial agreement with Digital Asset has been executed. * Your validator node has been deployed and successfully onboarded to the Canton Network (optional, if using CIP-103 compliant wallet). * You have access to the Registry User Interface through a CIP-103 compliant wallet or Wallet Gateway deployment. * Traffic-Based App Reward sharing has been configured in accordance with the applicable commercial agreement. Once your Provider Service request has been approved, you can begin onboarding registrar parties and creating and administering instruments through the Registry App. ## Next Steps Once your Provider Service has been created, the next steps depend on how you plan to use the DA Registry. If you are issuing your assets in the Canton Network, continue with the **Guides and Integration** section to learn how to: * [Onboard a Registrar](/registry/guides/registrar-onboarding) * [Create an Instrument Configuration](/registry/guides/instrument-configuration) * [Configure compliance controls](/registry/guides/blocklist) * [Mint your first asset using the Registry dApp](/registry/guides/mint) These guides walk through the complete asset issuance workflow using the user interface. If you are building a tokenization platform or integrating the DA Registry into your own applications, continue with the [Role Architecture](/registry/get-started/role-architecture) for an overview of the DA Registry components and integration model. Then follow the API Integration Guides and reference implementations to build against the Ledger API and Token Standard interfaces. ## Lower environments The Registry dApp is also available in the lower environments: [https://registry.test.app.digitalasset.com/](https://registry.test.app.digitalasset.com/) [https://registry.dev.app.digitalasset.com/](https://registry.dev.app.digitalasset.com/) On DevNet users can self-onboard as a Provider: any `ProviderServiceRequest` will be automatically approved. # Registry Primer Source: https://docs.digitalasset.com/registry/get-started/registry-primer Launch, manage, and scale compliant digital assets with production-ready workflows on the Canton Network. The **DA Registry** is the institutional-grade platform designed specifically for asset issuers and tokenization platforms building on Canton. It provides the foundational operational infrastructure required to bring assets on-chain while rigorously maintaining the governance, control, and privacy benchmarks of regulated markets. Whether you are issuing a tokenized fund, stablecoin, private credit instrument, or a bridged asset, the DA Registry provides production-ready workflows and seamless connectivity across the entire Canton ecosystem. **Capital Markets Ready:** Assets minted via the DA Registry are immediately compatible with Canton-native wallets, custodians, exchanges, and settlement applications out of the box. ## Platform Pillars The DA Registry shifts the paradigm from simple tokenization to true programmatic asset sovereignty. Assets retain the exact ownership rights, investor protections, and corporate governance required by traditional financial markets—supercharged by smart contract programmability. Instantly plug into an expanding network of digital cash solutions and financial applications. Seamlessly participate in atomic settlement, collateral management, and cross-application lending. Enforce fine-grained permissioning natively. Leverage configurable allowlists, blocklists, and pre-baked transfer approvals that easily integrate with external KYC/AML monitoring providers. Align incentives via native integration with Canton Network tokenomics, enabling issuers and service providers to capture value directly from asset velocity and transaction volume. ## Core Use Cases ### Real-World Asset (RWA) Tokenization Tokenize private securities, debt funds, real estate, and commodities while flawlessly satisfying the regulatory mandates of institutional investors. * **Capabilities:** Deploy complex investor allowlisting, persistent transfer restrictions, administrative overrides, and direct hooks into external compliance verification platforms. ### Stablecoins & Programmable Cash Issue private stablecoins and fiat-backed payment assets that move securely and privately across the Canton Network without sacrificing issuer sovereignty. * **Capabilities:** Protect your supply chain using institutional-tier blocklists, transfer pre-approvals, and centralized emergency controls designed to meet strict monetary compliance obligations. ### Trust-Minimized Asset Bridges Port legacy assets from external public or private networks onto Canton to unlock private trading and high-velocity settlement. * **Capabilities:** Utilize decentralized registrar configurations and attestation-based mint/burn workflows. This architecture eliminates centralized operator risks and establishes a cryptographic, verifiable audit trail across ledger boundaries. # Role Architecture & Asset Model Source: https://docs.digitalasset.com/registry/get-started/role-architecture A comprehensive guide to the primary roles, infrastructural hierarchy, and asset modeling within the DA Registry. The DA Registry is built around a clear separation of concerns, dividing infrastructure management from asset lifecycle management, and asset definitions from individual ownership records. ## Role Architecture The platform utilizes two primary administrative roles to ensure infrastructure sharing while maintaining strict organizational boundaries. Operates the underlying DA Registry infrastructure. Providers are responsible for onboarding participants to the application and managing infrastructure-level access to DA Registry services. Creates and administers instruments on the DA Registry. Registrars handle the core asset lifecycle, including minting, burning, transfer controls, allowlists, and blocklists. In token-standard terminology, the **registrar** acts as the definitive token administrator for a specific instrument. This role separation allows issuers, custodians, and tokenization platforms to operate dedicated registrar parties while securely leveraging a shared provider infrastructure. A single provider can support multiple registrars, and each registrar can administer one or more instruments. ### Infrastructure Hierarchy ```mermaid theme={null} graph TD P[Provider] --> RA[Registrar A] P --> RB[Registrar B] RA --> I1[Instrument 1] RA --> I2[Instrument 2] RA --> I3[Instrument 3] RB --> I4[Instrument 4] RB --> I5[Instrument 5] ``` ## Asset Model The DA Registry implements the asset model defined in the [CIP-56 Canton Network Token Standard](https://docs.canton.network/overview/reference/cip-0056#cip-0056-canton-network-token-standard). This model splits the concept of an asset into two distinct layers: This structural separation allows a single instrument definition to be globally referenced across multiple unique holdings, keeping asset administration, compliance controls, and actual ownership records independent. ### Instrument to Holding Relationship ```mermaid theme={null} graph TD I[Instrument] --> HA[Holding A
100 units] I --> HB[Holding B
500 units] I --> HC[Holding C
1,000 units] ``` # Allowlist Source: https://docs.digitalasset.com/registry/guides/allowlist As a registrar / token issuer, configure and manage allow-lists for my instruments. The Registry App uses credential-based allowlists to control which parties are permitted to perform specific actions for an asset. This enables issuers to enforce KYC, AML, regulatory, or business-specific requirements while keeping the rules fully configurable for each instrument. Common use cases include: * Restricting who may hold a regulated security. * Restricting who may request minting or redemption of a stablecoin. * Limiting participation to onboarded investors. * Delegating compliance decisions to an external compliance provider. ## How Allowlisting Works Allowlists are implemented using credential contracts. The Instrument Configuration defines the credential requirements for each workflow. When a user performs an action, the Smart Contract model verifies that the required credentials are present when the transaction is executed. This verification happens atomically. Credential requirements can be configured independently for: * **Holder requirements** – Who may hold, receive, or transfer an asset. * **Mint/Burn requirements** – Who may request minting or redemption. If a requirement is left empty, no credential verification is performed for that workflow. ## Configuring an Allowlist Each credential requirement specifies: * **Credential Issuer** – The party responsible for maintaining the allowlist. * **Claim Property** – The permission being granted (for example `canHold` or `canMint`). * **Claim Value** – The asset or permission scope (for example `USDX` or `BondX`). When an action is requested, the Registry App verifies that a valid credential matching the configured requirements exists for the acting party. ## Managing the Allowlist Adding a party to an allowlist is equivalent to issuing a credential with the required claims. The recommended approach is for the credential issuer to also hold the credential. This allows the allowlist to be maintained unilaterally without requiring the allowlisted party to separately accept or manage credential contracts. 1. In the Registry App, go to the **Credential** module. 2. Click **Offer new credential**. 3. Set the credential holder to **Use same party** so that the issuer also holds the credential. 4. Set the subject to the party being added to the allowlist. 5. Add the claim property and value required by the Instrument Configuration. 6. Click **Offer Free credential**. Repeat these steps for each party that you want to add to the allowlist. Before running the workflow scripts, create `source.sh` and update its values for your environment: ```bash theme={null} #!/usr/bin/env bash ## ================================================================================================= ## Purpose: Configurations for this example, amend variables as needed. ## Script: source.sh ## ================================================================================================= # Credential issuer details CREDENTIAL_ISSUER_TOKEN="" CREDENTIAL_ISSUER_PARTY_ID="registrar::122074e948ade481df88c49a94f80a7c6091dd6fb0df94c503b530817a13019d7f93" CREDENTIAL_ISSUER_USER_ID="registrar" # DA operator details OPERATOR_PARTY_ID="operator::1220a6f417751797b91ab08423236f8c0d3c53f1ec62ed1afd4602816390b68be8f0" # Subjects to create an allowlist-entry credential for. CREDENTIAL_SUBJECT_PARTY_IDS='[ "holder1::122074e948ade481df88c49a94f80a7c6091dd6fb0df94c503b530817a13019d7f93", "holder2::122074e948ade481df88c49a94f80a7c6091dd6fb0df94c503b530817a13019d7f93", "holder3::122074e948ade481df88c49a94f80a7c6091dd6fb0df94c503b530817a13019d7f93" ]' # Description used for all created credentials CREDENTIAL_DESCRIPTION="Allowlist-Entry Credential" # Claims to attach to each created credential (JSON list). # The scripts will set the `subject` field of each claim to the current subject party. CREDENTIAL_CLAIMS_JSON='[ {"property":"IsHolderOf","value":"INST1"}, {"property":"IsHolderOf","value":"INST2"} ]' # JSON API endpoint # Example (local): HTTP_JSON_API="http://localhost:8001/api/json-api" # Example (remote): HTTP_JSON_API="https:///api/json-api" HTTP_JSON_API="http://localhost:8001/api/json-api" # Daml template IDs (package-name qualified) CREDENTIAL_TEMPLATE="#utility-credential-v0:Utility.Credential.V0.Credential:Credential" ``` Now run the following script to create credentials for all configured subjects in one atomic transaction: ```bash theme={null} #!/usr/bin/env bash set -euo pipefail SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" DATAFILE="${SCRIPT_DIR}/source.sh" source "$DATAFILE" # Validate inputs if [[ -z "${CREDENTIAL_SUBJECT_PARTY_IDS:-}" ]]; then echo "Error: CREDENTIAL_SUBJECT_PARTY_IDS is not set in source.sh" exit 1 fi if [[ -z "${CREDENTIAL_CLAIMS_JSON:-}" ]]; then echo "Error: CREDENTIAL_CLAIMS_JSON is not set in source.sh" exit 1 fi if [[ -z "${OPERATOR_PARTY_ID:-}" ]]; then echo "Error: OPERATOR_PARTY_ID is not set in source.sh" exit 1 fi echo "${CREDENTIAL_SUBJECT_PARTY_IDS}" | jq -e 'type == "array" and length > 0 and all(.[]; type == "string")' >/dev/null echo "${CREDENTIAL_CLAIMS_JSON}" | jq -e 'type == "array" and length > 0 and all(.[]; has("property") and has("value"))' >/dev/null # Random Credential ID prefix. ID_PREFIX="allowlist-entry: $(od -An -N4 -tu4 < /dev/urandom | tr -d ' ')" COMMANDS_JSON=$(jq -n \ --arg templateId "${CREDENTIAL_TEMPLATE}" \ --arg issuer "${CREDENTIAL_ISSUER_PARTY_ID}" \ --arg description "${CREDENTIAL_DESCRIPTION}" \ --arg holder "${CREDENTIAL_ISSUER_PARTY_ID}" \ --arg operator "${OPERATOR_PARTY_ID}" \ --arg idPrefix "${ID_PREFIX}-" \ --argjson subjects "${CREDENTIAL_SUBJECT_PARTY_IDS}" \ --argjson claimPairs "${CREDENTIAL_CLAIMS_JSON}" \ '[ ($subjects | to_entries[]) as $entry | ($entry.key + 1) as $n | ($entry.value) as $subjectParty | { CreateCommand: { templateId: $templateId, createArguments: { issuer: $issuer, holder: $holder, id: ($idPrefix + ($n | tostring)), description: $description, validFrom: null, validUntil: null, claims: ( $claimPairs | map({subject: $subjectParty, property: .property, value: .value}) ), observers: { map: [[$operator, {}]] } } } } ]') RESULT=$( curl -sS --fail-with-body \ --url "${HTTP_JSON_API}/v2/commands/submit-and-wait-for-transaction" \ --header "Authorization: Bearer ${CREDENTIAL_ISSUER_TOKEN}" \ --header "Content-Type: application/json" \ --request POST \ --data @- < "$OUTPUTFILE" ``` The transaction response is saved to `response-step-1.json`. In the **Credential** module, review the active credentials held by the credential issuer. Confirm that each allowlisted party appears as the subject and that the claim property and value match the Instrument Configuration. Retrieve the current ledger end. ```bash theme={null} #!/usr/bin/env bash SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" DATAFILE="${SCRIPT_DIR}/source.sh" source "$DATAFILE" OFFSET=$(curl -sS --fail-with-body \ --url "${HTTP_JSON_API}/v2/state/ledger-end" \ --header "Accept: application/json" \ --header "Authorization: Bearer ${CREDENTIAL_ISSUER_TOKEN}") echo "$OFFSET" | jq OUTPUTFILE="${SCRIPT_DIR}/response-step-2.json" echo "$OFFSET" > "$OUTPUTFILE" ``` Then, run the following: ```bash theme={null} #!/usr/bin/env bash set -euo pipefail SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" DATAFILE="${SCRIPT_DIR}/source.sh" source "$DATAFILE" # Validate expected claim pairs config (property/value) if [[ -z "${CREDENTIAL_CLAIMS_JSON:-}" ]]; then echo "Error: CREDENTIAL_CLAIMS_JSON is not set in source.sh" >&2 exit 1 fi echo "${CREDENTIAL_CLAIMS_JSON}" | jq -e 'type == "array" and all(.[]; (has("property") and has("value")))' >/dev/null # Get offset from previous step if [[ -f "${SCRIPT_DIR}/response-step-2.json" ]]; then JSONCONTENT=$(cat "${SCRIPT_DIR}/response-step-2.json") OFFSET=$(echo "$JSONCONTENT" | jq -r ".offset") else echo "Error: response-step-2.json not found" exit 1 fi RESULT=$(curl -sS --fail-with-body \ --url "${HTTP_JSON_API}/v2/state/active-contracts" \ --header "Authorization: Bearer ${CREDENTIAL_ISSUER_TOKEN}" \ --header "Content-Type: application/json" \ --request POST \ --data @- < "$OUTPUTFILE" ``` The matching active credentials are saved to `response-step-3.json`. 1. In the **Credential** module, find the active credential for the party being removed. 2. Confirm that its claims match the allowlist entry that you intend to remove. 3. Revoke or delete the credential. The party no longer satisfies the corresponding credential requirement after the credential is removed. In order to remove parties from the allowlist, the corresponding credentials must be archived. The following script archives all credentials returned in step 3. Apply the required filters to the `response-step-3.json` file before running this script if you want to archive only a subset of the credentials. ```bash theme={null} #!/usr/bin/env bash set -euo pipefail SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" DATAFILE="${SCRIPT_DIR}/source.sh" source "$DATAFILE" CONTRACTS_FILE="${SCRIPT_DIR}/response-step-3.json" if [[ ! -f "$CONTRACTS_FILE" ]]; then echo "Error: ${CONTRACTS_FILE} not found. Run step 3 first." >&2 exit 1 fi # Extract contractIds from step 3 output. CONTRACT_IDS_JSON=$(jq -c '[.[].contractId] | map(select(type == "string" and length > 0))' "$CONTRACTS_FILE") COUNT=$(echo "$CONTRACT_IDS_JSON" | jq 'length') if [[ "$COUNT" -eq 0 ]]; then echo "No contractIds found in ${CONTRACTS_FILE}. Nothing to archive." >&2 echo "[]" > "${SCRIPT_DIR}/response-step-4.json" exit 0 fi COMMANDS_JSON=$(jq -n \ --arg templateId "${CREDENTIAL_TEMPLATE}" \ --argjson contractIds "${CONTRACT_IDS_JSON}" \ '[ $contractIds[] | { ExerciseCommand: { templateId: $templateId, contractId: ., choice: "Archive", choiceArgument: {} } } ]' ) RESULT=$( curl -sS --fail-with-body \ --url "${HTTP_JSON_API}/v2/commands/submit-and-wait-for-transaction" \ --header "Authorization: Bearer ${CREDENTIAL_ISSUER_TOKEN}" \ --header "Content-Type: application/json" \ --request POST \ --data @- < "$OUTPUTFILE" ``` # Blocklist Source: https://docs.digitalasset.com/registry/guides/blocklist Guide to the blocklist feature of the Registry App. This feature has been introduced with version `0.13` of the Registry App. An instrument for which the blocklist check is enabled is not compatible with Daml models introduced in previous releases. ## Instantiate the blocklist A blocklist is managed at the instrument admin (i.e. registrar) level, and applies to all instruments managed by that party for which the blocklist check is enabled. ## Enable blocklist verification You can enable blocklist verification on any instrument by modifying the corresponding `InstrumentConfiguration` contract and setting the `checkBlocklist` template field to `Some True`. Please make sure an empty blocklist is instantiated before enabling the blocklist check on an instrument, otherwise all transfers, mints, and burns will fail. Also note that enabling the blocklist check on an instrument makes it incompatible with Daml models introduced before release `0.13`. ## Manage the blocklist The blocklist is available for parties that have a registrar service. Click on Blocklist in the left navigation sidebar to view the blocklist. If no blocklist has been created click on Create blocklist. Parties can be added and removed from the blocklist. ## Cost considerations Using the blocklist feature requires additional contracts to be disclosed as part of the `ChoiceContext` for transfer, minting, and burning transactions. The blocklist is sharded across different party prefixes, so that the cost of these transactions is bounded, rather than linearly increasing with the number of parties in the blocklist. # Burn Source: https://docs.digitalasset.com/registry/guides/burn The Burn workflow removes existing holdings from circulation. Like minting, burning uses a request-and-accept model. ## **Prerequisites** Before burning can occur: * The holdings must already exist. * The requester must hold the amount to be burned. * The requester must satisfy the issuer credential requirements defined in the Instrument Configuration. * If no issuer credential requirements are defined, any party may request a burn. ## **Workflow** 1. The requester creates a Burn request. 2. The requester specifies: * Instrument identifier. * Amount to burn. * Registrar party. * Optional reference. 3. The Registry App selects holdings to cover the burn amount. 4. The selected holdings are locked while the request is pending. 5. The Registrar reviews the Burn request. 6. The Registrar accepts or rejects the request. 7. If accepted, the locked holdings are permanently removed. 8. If rejected, the Burn request is voided and the locked holdings are released. ## **Cancellation** The requester may cancel the Burn request before it is accepted by the Registrar. If cancelled, any locked holdings are released and can be used again. # CIP-104 Guidance Source: https://docs.digitalasset.com/registry/guides/cip-104-guidance Guidance for Registry App tokenizers on how to configure featured parties. ## Configure a Featured Party Under [CIP-104](https://github.com/canton-foundation/cips/blob/main/cip-0104/cip-0104.md), app rewards are attributed to featured parties based on the network traffic generated by application workflows. For Registry transactions, such as mints, transfers, burns, and other asset lifecycle operations, rewards are earned by the featured party associated with each workflow. To earn Traffic-Based App Rewards, one of the following parties must be featured: * Provider party * Registrar party The featured party that earns app rewards for Registry transactions is considered the Asset Issuer for the purposes of **CIP-116** locking requirements, regardless of the legal structure of the deployment or whether the controlling entity acts as an issuer, registrar, custodian, or technology provider. Once you have determined which featured party to use, you will need to configure the contractual [reward share agreement](/registry/guides/reward-share-agreement). ## Guidelines for featured parties #### Use only one featured party for Registry workflows Only one party should be featured: either the registrar or the provider. #### Isolate featured parties To ensure Traffic-Based App Reward sharing for the featured party applies only to Registry workflows, isolate that party from unrelated operational workflows as much as possible. The registrar party should primarily: * Maintain records of ownership * Maintain minting, burning, and transfer criteria for asset tokens The provider party should primarily: * Onboard registrars to the Registry App according to predefined criteria Other operational functions should use separate parties wherever possible, including: * Wallets * DEXs * Market makers * Lending protocols * Payment processors * Other fee-generating application functions Your featured Registry party (provider or registrar) should not also be used for unrelated application workflows. ## Recommended setup examples ### Example 1: Asset Issuer with Single Registry Infrastructure **Recommended for:** Asset issuers who manage one or more instruments and do not require separate registrar parties for individual assets. For example, a CSD with many CUSIPs or a custodian with many different assets under custody. **Why choose this setup?** This is the simplest operational model. It minimizes party management while allowing all Registry workflows to share a single registrar. **Recommended setup** * One provider party * One registrar party shared across all instruments * Separate provider and registrar parties * Either the provider or the registrar should be featured ### Example 2: Asset Issuer with Segregated Registrars **Recommended for:** Asset issuers that require separate registrar parties for individual instruments because of compliance or operational security requirements, while still being treated as a single Asset Issuer by the Tokenomics Committee for featured-party eligibility and locking requirements. **Why choose this setup?** This allows each instrument to have its own registrar while minimizing the number of featured parties, keeping reward attribution straightforward, and maintaining a single featured Asset Issuer party under the provider. This setup is also flexible and supports potential future requirements to split featured parties (see Example 3). **Recommended setup** * One featured provider party * Multiple unfeatured registrar parties, one per instrument or use case ### Example 3: Tokenization Provider supporting multiple Issuers with respective reward share agreements **Recommended for** 1. Tokenization providers that onboard multiple independent asset issuers, where each issuer is considered a separate Asset Issuer by the Tokenomics Committee for the purposes of featured-party eligibility and locking requirements. 2. Organizations that require separate Traffic-Based App Reward sharing agreements for individual assets. **Why choose this setup?** This setup allows separate commercial agreements or separate reward accounting for individual assets or issuers. It aligns with the Tokenomics Committee's treatment of separate Asset Issuers for featured-party eligibility and locking requirements. **Recommended setup** * One unfeatured provider party * One featured registrar party per issuer * Configure a static Traffic-Based App Reward sharing agreement for each featured registrar # Instrument Configuration Source: https://docs.digitalasset.com/registry/guides/instrument-configuration As a registrar / token issuer, define an asset and the rules that apply to it. Before an asset can be minted, the Registrar must create an Instrument Configuration. The Instrument Configuration defines the asset and the rules that apply to it. ## Purpose The Instrument Configuration defines: * The instrument identifier. * Optional external identifiers, such as ISIN or CUSIP. * The rules that determine who may hold, mint, or burn the asset. * Holder credential requirements * Issuer credential requirements ## Workflow 1. The Registrar creates an Instrument Configuration. 2. The Registrar defines the instrument identifier. 3. The Registrar optionally adds external identifiers such as ISIN or CUSIP. 4. The Registrar defines holder credential requirements. 5. The Registrar defines issuer credential requirements. 6. Once created, the Instrument Configuration is made available through the Registry disclosure process. 7. Future mint, burn, and transfer workflows use this configuration to validate permissions. ## Credential Requirements Holder credential requirements determine who may hold or receive the asset. Issuer credential requirements determine who may request minting or burning of the asset. For each credential requirement, the Registrar defines: * Credential issuer * Claim property * Claim value If no credential requirements are configured, the corresponding workflow is open to any party. ## Example Configurations ### Stablecoin Anyone may hold or transfer the stablecoin, but only KYC-approved parties may request minting or redemption. | Workflow | Credential Requirement | | :-------- | :--------------------------------------------------------------- | | Holder | None | | Mint/Burn | Issuer = Registrar
Property = `canMint`
Value = `USDX` | ### Money Market Fund Only onboarded investors may hold, receive, mint, or redeem fund units. | Workflow | Credential Requirement | | :-------- | :----------------------------------------------------------------- | | Holder | Issuer = Registrar
Property = `onboarded`
Value = `MMFX` | | Mint/Burn | Issuer = Registrar
Property = `onboarded`
Value = `MMFX` | ### Tokenized Bond A third-party compliance provider manages the allowlist independently from the registrar. | Workflow | Credential Requirement | | :-------- | :-------------------------------------------------------------------------- | | Holder | Issuer = Compliance Provider
Property = `canHold`
Value = `BondX` | | Mint/Burn | Issuer = Compliance Provider
Property = `canMint`
Value = `BondX` | This model enables issuers to delegate investor onboarding and compliance checks while retaining full control over the asset lifecycle. # Mint Source: https://docs.digitalasset.com/registry/guides/mint The Mint workflow creates new holdings for an instrument. Minting uses a request-and-accept model. The requester initiates the mint, and the Registrar approves or rejects it. ## **Prerequisites** Before minting can occur: * The Instrument Configuration must exist. * The requester must satisfy the issuer credential requirements defined in the Instrument Configuration. * If no issuer credential requirements are defined, any party may request a mint. ## **Workflow** 1. The requester creates a Mint request. 2. The requester specifies: * Instrument identifier. * Amount to mint. * Registrar party. * Optional reference. 3. The Registry App validates the request against the Instrument Configuration. 4. The Registrar reviews the Mint request. 5. The Registrar accepts or rejects the request. 6. If accepted, new holdings are created for the requester. 7. If rejected, the Mint request is voided. ## **Cancellation** The requester may cancel the Mint request before it is accepted by the Registrar. # Proof of Transfer Source: https://docs.digitalasset.com/registry/guides/proof-of-transfer As a Canton Network explorer, enhance your UpdateId detail view with the Proof of Transfer functionality for DA Registry Assets. As a wallet builder add a unique verification feature to your offering. Integrating **Proof of Transfer** capability into a Canton Network Explorer gives users a seamless interface to verify transaction statuses natively, while preserving privacy. ## Integration Blueprint To provide a seamless customer journey, the Explorer handles incoming payload information—an `UpdateID` and a `Transfer Object` payload—usually supplied via direct user copy-pasting or automated routing via a platform referral URL parameter. The platform then submits this data payload to the **DA Registry API** to render an indisputable confirmation receipt. ## Step-by-Step Implementation Flow Follow this workflow sequence to build the verification stack inside your network explorer ecosystem. Create a dedicated, public route in your application routing profile (e.g., `/verify-transfer`) designated to handle incoming cryptographic verification payloads. Ensure the handler is equipped to extract query string components seamlessly if redirected from external wallet histories. Design a clean input card component. If parameters are present in the URL path, auto-populate the data fields for the user. If blank, provide a structured text area box allowing the user to paste their raw transaction JSON payload manually. Dispatch an asynchronous network request from your application frontend layer directly to the live DA Registry network service infrastructure node using the structured body schemas. ```json Curl Request Signature theme={null} curl -X POST "[https://api.utilities.digitalasset.com/api/utilities/v0/registry/transfer/v0/proof](https://api.utilities.digitalasset.com/api/utilities/v0/registry/transfer/v0/proof)" \ -H "Content-Type: application/json" \ -d '{ "updateId": "1220b1223907e943aa24b52e874a78c86067bafcdb429958994cbd2b33fc41df5e1a", "transfer": { "sender": "issuer::12204b6be4677e1e110e63cb3dcd89c62025932458547a09e580458e29e822e9ee26", "receiver": "holder::12204b6be4677e1e110e63cb3dcd89c62025932458547a09e580458e29e822e9ee26", "amount": "1.0000000000", "instrumentId": { "admin": "registrar::12204b6be4677e1e110e63cb3dcd89c62025932458547a09e580458e29e822e9ee26", "id": "INST" }, "requestedAt": "2025-12-09T13:29:42.6187Z", "executeBefore": "2025-12-12T13:28:53.7492Z", "inputHoldingCids": [ "0020a2a23208de8d9fec1efd1c377d9a4343eac83f27b26b554f1c9e95c9653c05ca12122056c38daac3b523885fe8436215c72d0181e81e34379918246fc0ef75852990f9" ] } }' ``` Read the structured enum value returned from the API service. Update the client view container to reflect the deterministic ledger evaluation output cleanly using descriptive status layouts. ## API Request Schema Specifications Your interface layer must accurately frame the request body definitions before transmitting data packages to the network node validation server. ### Technical Payload Fields The unique cryptographic ledger hash tracking indicator marking the target execution sequence window. The private core transaction details package required to process cryptographic balance sheet verification. The specific identity fingerprint address origin string dispatching the digital asset. The destination identity fingerprint address authorized to take legal custody of the asset. Alphanumeric decimal string specifying the absolute transfer token unit volume. Identifies the core registry blueprint details governing the tokenized asset. ISO-8601 string mapping the exact timestamp historical moment the transfer workflow initialization sequence fired. The drop-dead expiration constraint timeline timestamp bounding the transaction validity lifecycle on-chain. The explicit array of structural tracking contract identifiers used directly to fund the ledger movement. ## UI Component States & Response Handling To ensure alignment with network expectations, map the direct string responses from the **DA Registry API** into intuitive, color-coded dashboard indicators for your end users. ### Rendering UI Target: Balanced Verification Badge The transaction variables are authenticated against the ledger state and indicate successful contract finalization. ```json Response Sample theme={null} { "status": "Success" } ``` **Interface Suggestion:** Render a prominent checkmark module highlighting an "Indisputably Settled" receipt statement. Users can confidently treat this transaction as settled. ### Rendering UI Target: Progress Indicator Badge The parameters represent a structurally valid ledger entry path, but the contract steps are still moving through live execution queues. ```json Response Sample theme={null} { "status": "Pending" } ``` **Interface Suggestion:** Inform users that the asset transfer is in an intermediate lifecycle phase (e.g., a two-step transfer workflow where the destination party hasn't formally accepted an open offer yet). Advise re-evaluating once final settlement commits. ### Rendering UI Target: Terminated Execution Badge The proof data successfully resolved to a historical ledger event path, but the workflow instructions failed execution or were rejected. ```json Response Sample theme={null} { "status": "Failure" } ``` **Interface Suggestion:** Update the dashboard to inform the user that the transaction request was intentionally canceled, explicitly aborted by a counterparty, or simply expired on-chain. ### Rendering UI Target: Input Mismatch Panel (HTTP 400) The input fields failed lookup, are missing parameters, or contain structured mismatches against live on-chain transactional tracking parameters. ```json Response Sample theme={null} { "error": "invalid_request", "error_description": "Something went wrong" } ``` **Data Privacy Guardrail Rule:** The backend deliberately zero-discloses tracking details to prevent unwanted transaction state farming by unauthorized actors. Ensure your Explorer frontend handles errors elegantly with a general "Invalid Proof Credentials" module rather than displaying custom data logs. ## Guide overview To enable this transfer proofing capability, wallets must make the **Transfer Object** payload and **UpdateID** extractable, allowing end-users to easily locate and copy this data directly from their transaction history to use in proofing services or network explorers. This guide provides the technical specifications for locating and extracting the Transfer Object from the ledger via the JSON API. ## Exposing the Transfer Object and UpdateID ### Technical Guidelines: What Constitutes the Transfer Object? The **UpdateID** is the unique identifier for a transaction on the ledger. With it, you can fetch the Created, Exercised, and Archived events for that specific transaction. **NOTE: The wallets need to ensure that they display the most recent update for a given transfer. For example, in the case of a 2 step transfer, Wallet Providers will need to explicitly refresh the updateID, after the transaction has been accepted, so that they display the transfer, not just the offer.** The underlying schema defining the Transfer Object can be referenced in the DAML model here: `Splice/Api/Token/TransferInstructionV1.daml` The Transfer Object can also be serialized into JSON format, as shown in the following example: ```json theme={null} { "sender": "issuer::122...", "receiver": "holder::122...", "amount": "2.0000000000", "instrumentId": { "admin": "...", "id": "INST" }, "requestedAt": "2026-03-01T13:58:32.626Z", "executeBefore": "2026-03-04T13:58:27.335Z", "inputHoldingCids": ["005152f0eae9..."], "meta": { "values": { "splice.lfdecentralizedtrust.org/reason": "" } } } ``` **Fetching the Data via JSON API** While gRPC can be used, this guide assumes integration via the [DAML JSON API](/sdks-tools/api-reference/json-api). To fetch update info from the participant node, query the following endpoint using the transaction's `UpdateID`: `GET /v2/updates/update-by-id` ### Locating the Transfer Object (By Transaction State) Depending on the lifecycle stage of the transaction, the Transfer Object is located in different event arguments. You will need to parse the events returned from the endpoint above based on these three scenarios: **Scenario A: The Transfer Offer is Created** If the update represents the creation of a transfer offer, look for a **Created** event. * **Template:** `Utility.Registry.App.V0.Model.Transfer:TransferOffer` * **Location:** Extract the Transfer Object directly from the `createArgument` of this event. ```json theme={null} { "createdEvent": { "templateId": "...:Utility.Registry.App.V0.Model.Transfer:TransferOffer", "createArgument": { "operator": "operator::122...", "provider": "provider::122...", "transfer": { "sender": "issuer::122...", "receiver": "holder::122...", "amount": "2.0000000000", "instrumentId": { "admin": "...", "id": "INST" }, "requestedAt": "2026-03-01T13:58:32.626Z", "executeBefore": "2026-03-04T13:58:27.335Z", "inputHoldingCids": ["005152f0eae9..."], "meta": { "values": { "splice.lfdecentralizedtrust.org/reason": "" } } } } } } ``` **Scenario B: The Transfer is Concluded** If the update represents a concluded transfer (e.g., an accepted offer or a pre-approved transfer), look for an **Exercised** event. * **Template:** `Utility.Registry.V0.Rule.Transfer:TransferRule` * **Triggering Choices:** The event must be triggered by one of the following choices: * `TransferRule_DirectTransfer` * `TransferRule_TwoStepTransfer` * `TransferRule_Transfer` (This choice will be deprecated. It is only required for backwards compatibility) * **Location:** Extract the Transfer Object from the `choiceArgument` of this event. ```json theme={null} { "ExercisedEvent": { "templateId": "...:Utility.Registry.V0.Rule.Transfer:TransferRule", "choice": "TransferRule_DirectTransfer", "choiceArgument": { "transfer": { "sender": "auth0...::122...", "receiver": "auth0...::122...", "amount": "12.0000000000", "instrumentId": { "admin": "...", "id": "INST" }, "requestedAt": "2026-02-24T16:27:33.139Z", "executeBefore": "2026-02-27T16:27:31.633Z", "inputHoldingCids": ["0000c37c6..."], "meta": { "values": { "splice.lfdecentralizedtrust.org/reason": "" } } } } } } ``` **Scenario C: The Transfer Offer is Rejected or Withdrawn** If the update represents an offer that was ultimately rejected or withdrawn, locating the object is a two-step process: 1. **Identify the Event:** Look for an **Exercised** event matching the following: * **Interface ID:** `Splice.Api.Token.TransferInstructionV1:TransferInstruction` * **Triggering Choices:** `TransferInstruction_Reject` OR `TransferInstruction_Withdraw` 2. **Fetch the Contract ID:** Extract the Contract ID of the transfer offer from this exercised event. 3. **Fetch the Original Offer:** Query the JSON API using the extracted Contract ID: `GET /v2/events/events-by-contract-id` 4. **Location:** Extract the Transfer Object from the `createArgument` of the original transfer offer (transfer instruction) returned by this secondary query. ```json theme={null} { "CreatedEvent": { "templateId": "...:Utility.Registry.App.V0.Model.Transfer:TransferOffer", "createArgument": { "operator": "operator::12209b02d...", "provider": "provider::1220c07e7...", "transfer": { "sender": "issuer::1220c07e7...", "receiver": "holder::1220c07e7...", "amount": "2.0000000000", "instrumentId": { "admin": "registrar::1220c07e7...", "id": "INST" }, "requestedAt": "2026-03-01T13:58:32.626Z", "executeBefore": "2026-03-04T13:58:27.335Z", "inputHoldingCids": ["005152f0eae9..."], "meta": { "values": { "splice.lfdecentralizedtrust.org/reason": "" } } } } } } ``` ### Data Persistence and Pruning **Ledger data is subject to pruning.** The JSON API queries described in the previous section will only succeed if the transaction events have not yet been pruned from the participant node. **Wallet Developer Action Required:** To ensure end-users can always access their Transfer Objects for the proofing service, **wallets MUST persist the Transfer Object and UpdateID data in their own backend databases** at the time the transaction occurs. Relying strictly on real-time ledger queries for historical transactions will result in errors once the transactions are pruned. PQS can be considered as an option for storing ledger data. ### Locating the Transfer Object (as an end-user) **Labelling** There are two key items to be displayed within the transaction details: 1. UpdateID 2. Transfer object **Displaying value** A truncated preview of the UpdateID can be displayed or in full. A truncated preview of the json object can be displayed as needed or none at all. **Interactive options** Users must be able to review the full json object. Option 1 * Click to open a modal/side-panel component or an external browser window. Since the content is hidden to start, when a user clicks to open this component, the json object should by default be displayed fully. This component shows the label of "Transfer object", contains the full json object for reviewing, and an accessible copy button. * If an external window is used, its domain must match the application domain from which the window was triggered. * The icon or button for a user to click to review the json object must be accessible, alongside the copy icon/button. Users can copy the object without opening the review component. Option 2 * Click to open the accordion containing the content. The accordion is closed by default, and a copy button is accessible without opening the accordion. The Proof of Transfer API is supporting the validation of multiple transactions within an UpdateID, that means also Batch Transfer can be validated. In order to enable it from a wallet perspective, ensure that end users can extract the `Transfer Object` for each individual transaction of a batch. **Copying behavior** The copy behavior must always copy the full UpdateID and full json object, never the truncated preview string. # Provider Configuration Source: https://docs.digitalasset.com/registry/guides/provider-configuration Before Registrars can be onboarded, the Provider must create a Provider Configuration. The Provider Configuration defines the onboarding requirements for Registrar parties. These requirements determine which parties can be onboarded as Registrar. ### **Purpose** The Provider Configuration allows the Provider to define additional permissioning requirements for registrar onboarding. These requirements are based on credential contracts. A credential proves that a party satisfies a specific claim, for example that it is authorized to act as a registrar for a provider. ### **Workflow** 1. The Provider creates a Provider Configuration. 2. The Provider defines the required credential claims for registrar onboarding. 3. The credential requirements specify: * The credential issuer. * The required claim property. * The required claim value. 4. Parties that want to onboard as registrars must satisfy these requirements. 5. The Provider reviews registrar onboarding requests and accepts or rejects them. Credential contracts can be created directly in the Registry App. If no credential requirements are defined, any party may request a Registrar Service. The Provider still retains control because each Registrar Service request must be accepted by the Provider. # Registrar Onboarding Source: https://docs.digitalasset.com/registry/guides/registrar-onboarding After the Provider Configuration has been created, parties can request to onboard as registrars. A registrar is responsible for creating instruments and managing asset lifecycle workflows such as minting, burning, and transfer controls. ## **Workflow** 1. A party requests a Registrar Service from the Provider. 2. The Registry App checks whether the party satisfies the Provider Configuration requirements. 3. If credentials are required, the party must hold the required credential contract. 4. The Provider reviews the request. 5. The Provider accepts or rejects the request. 6. If accepted, a Registrar Service is created. 7. The Provider and Registrar both become signatories to the Registrar Service contract. ## **Credential Issuance** If a credential is required for onboarding, it can be issued through the Registry App. A Provider can issue a credential offer to the relevant party. The credential defines the claim required by the Provider Configuration. In simple onboarding setups, the credential issuer may also hold the credential on behalf of the party the claim is about. This avoids requiring the target party to separately interact with the credential app. ## **Cancellation, Rejection, and Termination** A Registrar Service request may be cancelled by the requesting party before acceptance. The Provider may reject a request during review. If rejected, no Registrar Service is created. A Registrar Service can also be terminated later by either the Provider or the Registrar. Termination archives the Registrar Service contract but does not remove existing credential contracts. # Reward share agreement Source: https://docs.digitalasset.com/registry/guides/reward-share-agreement As a featured tokenizer, set up the contractual reward share agreement with DA for my featured parties. ## Steps to set up reward sharing for your featured party Use the following steps for each featured Registry party (provider or registrar) you control. Identify the Digital Asset accounting party that should receive the contractual reward share for the featured party. Before proceeding, confirm: * the correct DA accounting party identifier * the expected reward share split defined in your commercial agreement The validator app hosting your featured party can be configured to automatically share Traffic-Based App Rewards with a set of beneficiaries, including the DA accounting party. The setup is documented in the [splice docs](https://docs.canton.network/global-synchronizer/splice-fundamentals/reward-sharing#reward-sharing). Use this as an illustrative template for a featured party reward-sharing setup. Replace placeholder values with your actual party IDs, the DA accounting party, and commercial split. ```yaml theme={null} - name: ADDITIONAL_CONFIG_REWARDSHARING value: | canton.validator-apps.validator_backend { reward-sharing-config-by-party = { "issuer::1220f3459220955drb1e272c7a1e26b4525645636346641fff8210e3835c99e684638dafd" = { min-ttl-after-sharing = 35h beneficiaries = [ {beneficiary = "auth0_007c67dc7c4afbf5bc37f9805e31::12205bcc106efa0eaa7f18dc491e5c6f5fb9b0cc68dc110ae66f4ed6467475d7c78e", percentage = 0.2 }, ] } } } ``` If your featured party is an external party, you will need to additionally sign a [delegation contract](https://docs.canton.network/global-synchronizer/splice-fundamentals/rewards-minting) to allow your validator operator to perform minting and reward sharing on the featured party's behalf. ## Migration from Featured Activity Markers to Traffic-Based App Rewards ### Background information The DA Registry App enables users to tokenize and manage assets on the Canton Network. As part of the service, the Registry App currently generates Featured App Activity Markers through automation to create activity-based rewards for asset tokenizers in accordance with the current tokenomics guidelines. With [CIP-0104: Traffic-Based App Rewards](https://docs.canton.network/global-synchronizer/splice-fundamentals/traffic-based-app-rewards), the mechanism for app rewards will fundamentally change. App rewards will no longer be generated by explicitly setting activity markers. Instead, rewards will be derived directly from measured transaction traffic processed by the network. This transition improves the incentive model by: * aligning incentives with productive network usage * rewarding applications proportionally to actual network burn generated * reducing transaction size and validator workload * increasing Global Synchronizer throughput * eliminating marker-based reward farming and reducing the governance overhead Moving to this model requires changes to how Registry App users structure featured parties and reward-sharing setups in order to: * generate rewards * comply with the updated tokenomics guidelines * maintain existing reward-sharing agreements with Digital Asset and other partners ### Current Registry App Setup The Registry Utility onboards asset tokenizers with the provider role. Providers can onboard other parties with the registrar role. Registrars can create instruments and manage minting and burning workflows. In token-standard terminology, the registrar acts as the token administrator for an instrument. This setup allows issuers and tokenization providers to onboard dedicated registrar parties to the registry app while operating shared provider infrastructure. For instruments where the provider party is featured, an operator automation currently creates activity markers for Registry transactions. The corresponding rewards can then be shared: * with Digital Asset according to the commercial agreement * optionally with additional beneficiaries configured by the provider ### What Changes with CIP-104 #### Change in Reward Mechanism Featured App Activity Markers can no longer be used to mint AppRewardCoupons. Instead, featured parties accrue app reward weight for a transaction based on: * the transaction’s total traffic cost * the size of transaction envelopes for which the featured party is a view confirmer The effective reward attribution therefore depends on: * how much “traffic” a featured party confirms * how many other featured parties participate in the transaction When multiple featured parties confirm parts of the same transaction, the traffic weight is distributed among them. For Registry App users, this represents a major shift from: “one marker per transaction” to: “traffic-weight-based rewards proportional to confirmed transaction traffic”. Monitoring of traffic-weight metrics already available through the Scan API shows a positive expected economic impact for asset issuers, since a significant portion of network activity is based on asset transactions where their parties play a key confirming role. [See CIP-104 Guidance for reference](/registry/guides/cip-104-guidance). #### Reward Share Agreements On-ledger reward-sharing mechanisms based on activity markers are no longer available. That means the current Registry functionality that allows configuring multiple reward beneficiaries per instrument will no longer exist in its current form. To maintain the existing contractual reward-sharing agreement with Digital Asset, Registry users will need to configure automatic sharing of Traffic-Based App Rewards for any featured Registry party (provider or registrar) on a validator node hosting their featured Registry party. [This functionality is part of the Splice 0.6.8 release.](https://docs.canton.network/global-synchronizer/splice-fundamentals/reward-sharing#reward-sharing) #### Required contractual amendment To align the contractual terminology with CIP-104, a small amendment to the existing agreement will be required. The amendment will replace references to: marker-based reward sharing with traffic-based app reward share agreement per party. Separate communication regarding the contractual update will follow in the coming weeks. # Transfer Source: https://docs.digitalasset.com/registry/guides/transfer The Transfer workflow moves ownership of holdings from one party to another. The Registry App supports both two-step transfers and preapproved transfers. ## **Prerequisites** Before a transfer can occur: * The sender must hold the asset. * The Registrar must have created the required transfer rules. * The sender must satisfy the holder credential requirements. * The receiver must satisfy the holder credential requirements. * For preapproved transfers, the receiver must have created a Transfer Preapproval. If no holder credential requirements are defined in the Instrument Configuration, transfers are permitted between any parties. ## **Transfer Mode 1: Offer and Accept** In the offer-and-accept flow, the sender creates a transfer offer and the receiver explicitly accepts or rejects it. ### **Workflow** 1. The sender creates a Transfer offer. 2. The sender specifies: * Receiver party. * Instrument identifier. * Amount. * Registrar party. * Optional reference. 3. The Registry App selects holdings to cover the transfer amount. 4. The selected holdings are locked while the offer is pending. 5. The receiver reviews the Transfer offer. 6. The receiver accepts or rejects the offer. 7. If accepted, ownership moves from the sender to the receiver. 8. If rejected, the offer is voided and the locked holdings are released. ### **Withdrawal** The sender may withdraw the Transfer offer before it is accepted. If withdrawn, any locked holdings are released back to the sender. ## **Transfer Mode 2: Preapproved Transfer** A preapproved transfer allows the sender to transfer holdings directly to a receiver without requiring the receiver to manually accept each transfer. ### **Prerequisites** The receiver must create a Transfer Preapproval before the transfer is initiated. The Transfer Preapproval can define: * The Registrar whose instruments are eligible. * Specific instrument identifiers. * Whether all instruments from the Registrar are eligible. If no instrument identifiers are specified, the preapproval applies to all instruments administered by the selected Registrar. ### **Workflow** 1. The receiver creates a Transfer Preapproval. 2. The sender initiates a transfer to the receiver. 3. The Registry App checks whether a matching Transfer Preapproval exists. 4. If a matching preapproval exists, the transfer executes immediately. 5. Ownership moves from the sender to the receiver. 6. No separate receiver acceptance step is required. # Transaction History Parsing Source: https://docs.digitalasset.com/registry/guides/tx-history-parsing As an app user, how to inspect the ledger to parse transaction history. This page explains how to inspect the ledger to parse transaction history for a given party, in order to identify executed mints, burns, and transfers. ## CIP-112 transaction parsing guidelines CIP-112 introduces a dedicated Daml `EventLog` interface to record transaction events. This interface exposes a `nonconsuming` choice which is exercised within a transaction to record relevant events. A ledger client can query events on this interface to obtain an ordered series of events from the participant node. You can refer to the relevant pieces of the [Canton Network documentation](https://docs.canton.network/appdev/deep-dives/token-standard#parsing-the-history-v2) for additional details. The `EventLog` interface is not implemented in Registry Daml models prior to the **0.14** release. These guidelines unfortunately do not apply to these earlier versions. As long as you support Registry **0.13** and older, you will need to use the below CIP-56 transaction parsing guidelines. Here is an example query, using the JSON API endpoint for paginated updates `v2/updates/get-updates-page`. ``` { "beginOffsetExclusive": 0, "endOffsetInclusive": 3703, "maxPageSize": 100, "updateFormat": { "includeTransactions": { "transactionShape": "TRANSACTION_SHAPE_LEDGER_EFFECTS", "eventFormat": { "filtersByParty": { "registrar-dLhm20fxdH8_dL17::12205dd5bd685449653161d47d2a7cb01c25d5b0a02dab5c79cafc8dafd811c79895": { "cumulative": [ { "identifierFilter": { "InterfaceFilter": { "value": { "interfaceId": "#splice-api-token-transfer-events-v2:Splice.Api.Token.TransferEventsV2:EventLog" } } } } ] } }, "verbose": false } } } } ``` You will then need to filter the output events for exercises of the `EventLog_HoldingsChange` choice and look at the content of the `choiceArgument` object. For a transfer from `issuer` to `holder`, the `choiceArgument` object of the `ExercisedEvent` includes the relevant information: * instrument admin * relevant account * transfer leg (`SenderSide` if the relevant account is the sender, `ReceiverSide` otherwise) ```json theme={null} "admin": "registrar-S92p6Rp513u3mvsg::12205dd5bd685449653161d47d2a7cb01c25d5b0a02dab5c79cafc8dafd811c79895", "account": { "owner": "issuer-S92p6Rp513u3mvsg::12205dd5bd685449653161d47d2a7cb01c25d5b0a02dab5c79cafc8dafd811c79895", "provider": null, "id": "" }, "inputHoldingCids": [ "00bb9c3dc01c7cebc82d29ffcb677a2b50bddbb9a096cde58000ec97ec0eb9abc8ca121220b950163ec54c0b03cd1e1ed19e20d64862aa9dd2cacf02d8884423dd4c266fe8" ], "transferLegSides": [ { "transferLegId": "", "side": "SenderSide", "otherside": { "owner": "holder-S92p6Rp513u3mvsg::12205dd5bd685449653161d47d2a7cb01c25d5b0a02dab5c79cafc8dafd811c79895", "provider": null, "id": "holder-account-1" }, "amount": "100.0000000000", "instrumentId": "INST", "meta": { "values": { "splice.lfdecentralizedtrust.org/reason": "reference" } } } ], ... ``` Note that both the `SenderSide` and `ReceiverSide` are logged separately. The same format is used for allocations (where there could be multiple `TransferLegs` for a given event). Mints only have a `ReceiverSide` leg. ```json theme={null} "admin": "registrar-dLhm20fxdH8_dL17::12205dd5bd685449653161d47d2a7cb01c25d5b0a02dab5c79cafc8dafd811c79895", "account": { "owner": "issuer-dLhm20fxdH8_dL17::12205dd5bd685449653161d47d2a7cb01c25d5b0a02dab5c79cafc8dafd811c79895", "provider": null, "id": "" }, "transferLegSides": [ { "transferLegId": "mint", "side": "ReceiverSide", "otherside": { "owner": null, "provider": null, "id": "cip-112/mint" }, "amount": "100.0000000000", "instrumentId": "burn-mint-request-dLhm20fxdH8_dL17", "meta": { "values": {} } } ], ``` Likewise, burns only log a `SenderSide` leg. ## A note on ledger pruning In order to keep a Canton participant node healthy, it should be pruned at regular intervals. This means that the ledger will generally not retain all of the transaction history. The methodology described in this guide only applies to data that has not been pruned from the ledger. If the user needs to retain transaction data for a period of time longer than their pruning window, they should move the data outside of the Canton participant node before it gets pruned. For reference, the Registry operator node uses a retention period of 30 days for pruning. ## Other transaction parsing options If you have been integrating with Registry prior to version 0.14, you are probably using one of the below options for transaction history parsing. ### CIP-56 transaction parsing guidelines CIP-56 transaction parsing works for all workflows across all currently supported Registry versions (0.12, 0.13, 0.14). We recommend migrating to CIP-112 transaction parsing only once versions 0.12 and 0.13 are no longer supported. The first iteration of the Token Standard introduced a set of transaction history parsing guidelines. These are documented in the relevant pieces of the [Canton Network documentation](https://docs.canton.network/appdev/deep-dives/token-standard#parsing-the-history-v1). #### Mint and Burn workflows Mint and burn workflows are not part of the Token Standard and use Daml templates rather than interfaces. Choice exercises resulting in a successful mint or burn are tagged with the appropriate metadata as part of their choice result. For instance, the choice result for a successful burn includes ``` "meta": { "values": { "splice.lfdecentralizedtrust.org/burned": "100.0", "splice.lfdecentralizedtrust.org/reason": "", "splice.lfdecentralizedtrust.org/tx-kind": "burn" } } ``` ### Transaction parsing based on ExecutedTransfer, ExecutedMint, ExecutedBurn **DEPRECATED** This transaction parsing method is no longer supported from version 0.14 of the Registry. Please refer to the [migration guide](#migration-guide-executed-transfers) below to understand how to migrate off these contracts. Versions of Registry prior to 0.14 create an active `Executed*` contract upon a successful transfer, mint, or burn. Similar contracts are created when a request is rejected by a counterparty. | Transaction type | Executed contract | | ---------------- | ------------------ | | Transfer | `ExecutedTransfer` | | Mint | `ExecutedMint` | | Burn | `ExecutedBurn` | These can be retrieved via an ACS query in order to reconstruct transaction history. They should however be regularly archived by the corresponding `registrar` in order to prevent excessive ACS growth. Batch archival can be performed in order to minimize the cost of this operation. #### Disable the creation of Executed\* contracts Parties with the `registrar` role can disable the creation of `Executed*` contracts on versions of the app prior to `0.14`. This is controlled by a flag in the `RegistrarService` template, which can be set by calling ```haskell theme={null} choice RegistrarService_Set : ContractId RegistrarService -- ^ Sets the `enableResultContracts` flag. -- This choice is introduced as of version `0.5.0` of this package. -- As of version `0.9.0` of this package the value of the `enableResultContracts` flag is ignored. with enableResultContracts : Optional Bool -- ^ New value for the flag. ``` ### Template-based transaction parsing A final transaction parsing option is to rely on concrete template choice exercises, such as exercises of ```haskell theme={null} nonconsuming choice TransferRule_DirectTransfer : TransferRule_DirectTransfer_Result -- ^ Used for executing a direct transfer. -- This choice was added as of version `0.5.0` of this package. ``` to identify a transfer. While this mechanism is arguably simpler than the CIP-56 guidelines, it is not very robust: template choice exercises are subject to change and are not guaranteed to be stable across releases. ## Migrating from Executed contracts Up until version `0.13` of the Registry App, an `ExecutedTransfer` contract is created by default on each transfer transaction. Similar contracts are created for mint and burn operations. While these contracts are very convenient to use, they are not sustainable as they lead to unbounded ACS growth unless they get regularly archived by the instrument admin. Thus, starting with version `0.14`, these "execution" contracts are no longer created. Tokenizers that rely on these contracts to determine whether a transfer, mint, or burn has occurred must switch to transaction history parsing based on ledger events before adopting the `0.14` release. The following sub-section outlines a migration path, which * relies on Executed contracts for transactions using the `0.13` DARS or older * uses [CIP-112 transaction parsing](#cip-112-tx-parsing) for transactions using the `0.14` DARS or newer It is not the role of the Canton participant node to store your entire transaction history, especially if your data retention requirements span a period of months or years. You should determine a durable store for the history that you need to retain, such as a Postgres DB. See the [note on ledger pruning](#ledger-pruning) for why this data should be stored outside the Canton participant node. Query the active `ExecutedMint`, `ExecutedBurn`, and `ExecutedTransfer` contracts for the parties and instruments whose history you need to retain. Copy the relevant contract payloads and transaction identifiers (`updateId`, `recordTime`) into the durable store. This needs to be an ongoing process, as transactions using Registry versions 0.12 and 0.13 keep creating these contracts. Archive the ingested `Executed*` contracts to reduce the burden on the participant node. This step is optional, but recommended. Archival of these contracts can be done in a batched fashion in order to minimize transaction cost. Introduce an additional process that updates the stored transaction history based on the parsing guidelines introduced with CIP-112. You can now install the `0.14` DARS. Transactions using these models will be caught only by the ingestion process introduced in step 3. Once you (or the Registry operator) no longer support versions of the Registry App prior to `0.14`, you can safely unvet the corresponding DARS, so that these can no longer be used for transactions involving your assets. Finally, you can switch off the ingestion process introduced in Step 2. Transaction parsing is now fully driven by CIP-112 event-based parsing. # Overview Source: https://docs.digitalasset.com/registry/overview The DA Registry is the fastest way for asset issuers and tokenizers to issue, mobilize and monetize institutional-grade digital assets on Canton.
# Overview

The DA Registry is the fastest way for asset issuers and tokenizers to issue, mobilize and monetize institutional-grade digital assets on Canton.


If you are not familiar yet with the DA Registry, we recommend briefly reading the [**PRIMER**](/registry/get-started/registry-primer) first. Issue compliant, interoperable assets on Canton - fast. Whether you are an Asset Issuer or Tokenizer, we've got how-tos for you.  In case of any questions, we are here for you.  Registry APIs. Everything you need, from asset issuance to management. Get info on the latest releases incl. what's needed to activate them. Validate our security approach for your Digital Asset Ops on Canton. Registry tutorials
# DA Parties Source: https://docs.digitalasset.com/registry/reference/da-parties Explains the role of Digital Asset parties in Registry workflows. ## Operator Party The DA operator party is used * as a **signatory** on onboarding contracts (i.e. `ProviderService`) * as an **observer** on all other Registry contracts (e.g. `InstrumentConfiguration`, `TransferPreapproval`, ...) The latter is required for DA to be able to run the Registry Operator backend for explicit disclosure of the choice context. Importantly, the DA operator party does not need to confirm any Registry transactions, with the exception of the initial onboarding transaction. ### How to retrieve it Use the environment-specific operator endpoint: [https://api.utilities.digitalasset.com/api/utilities/v0/operator](https://api.utilities.digitalasset.com/api/utilities/v0/operator) [https://api.utilities.digitalasset-staging.com/api/utilities/v0/operator](https://api.utilities.digitalasset-staging.com/api/utilities/v0/operator) [https://api.utilities.digitalasset-dev.com/api/utilities/v0/operator](https://api.utilities.digitalasset-dev.com/api/utilities/v0/operator) ## Accounting Parties DA accounting parties are DA-controlled beneficiary parties used to receive Digital Asset's contractual share of Traffic-Based App Rewards from featured providers and registrars. ### How to retrieve them The correct accounting parties will be shared during the setup of a commercial agreement with Digital Asset. Please reach out to your DA contact for details. # Daml models Source: https://docs.digitalasset.com/registry/releases/daml-models Supported versions of the Daml models for the Registry App. The Daml models for the Registry App are shipped as a bundle of DAR files. ## Supported versions We currently support the Daml models shipped with the `0.12`, `0.13`, and `0.14` releases, and include the DARs for those releases in the latest available bundle. For maximum compatibility, we recommend vetting all packages for all supported versions. Refer to the [release notes](./release-notes) for more details on the changes included in each release. As of the `0.14` release, support for the `0.11` release has been dropped. **Current deployment status:** * **MainNet:** `0.14.4` is currently deployed. * **TestNet:** `0.14.4` is currently deployed. * **DevNet:** `0.14.4` is currently deployed. **Recommendation:** Use the `0.14.4` DARs for new deployments and upgrades. ### 0.14 | Package | Version | Package Id | | :-------------------------- | :------ | :--------------------------------------------------------------- | | utility-registry-app-v0 | 0.9.2 | 1eddd268bdd50d6e262722bea799c9455da032b3f94489e589975151b274b8c0 | | utility-registry-v0 | 0.8.2 | 8c654487d9f5fb195fbcdd7b44cd8e365b1ea39c15ae62ce6c7a48343f1210dd | | utility-registry-holding-v0 | 0.3.2 | 415a1ec96a9e2839453e9aa1c5c71b6511c008c79511cb6f873e0b7393fe3b92 | | utility-credential-app-v0 | 0.4.3 | 87d6bfac3adf937cf5f603767f440a3b60416c2dfd9f82346455547972f5e236 | | utility-credential-v0 | 0.1.2 | 044be226f82e81609111569fb7253421cdb86b2bf0ecab781f46a58003e69574 | DAR bundle archive (.tar.gz) Checksum file These DARs are compiled using Daml LF 2.3. If you are running PQS, please ensure you are at least on version `3.5.5` before uploading these DARs to your validator node. Previous versions of PQS are not compatible with Daml LF 2.3. ### 0.13 | Package | Version | Package Id | | :-------------------------- | :------ | :--------------------------------------------------------------- | | utility-registry-app-v0 | 0.8.2 | 2293eb12e82ceaeb3ff7f8fe3346dece8578e1e9fd7d46624aeb7bb07fa31eda | | utility-registry-v0 | 0.7.1 | 1f80e086e9ce218cf93fdeed80943793e902ac35c521733d7373a5ba58813150 | | utility-registry-holding-v0 | 0.2.2 | 71fbaea211f07a65666892748498bd4a0d7462a9d75bbb215ba9fbdbba78efa7 | | utility-credential-app-v0 | 0.4.2 | 3f0341b825b1e2cc94b3b216303e5497f0adf2bae0f1dc6e16e19d7aa955a6d6 | | utility-credential-v0 | 0.1.1 | 418370044b5c6cd76ec78b73b8553c592328dec0afb6defbd2fdc5909e024033 | The 0.13 DARs are compiled using Daml LF 2.3. If you are running PQS, please ensure you are at least on version `3.5.5` before uploading these DARs to your validator node. Previous versions of PQS are not compatible with Daml LF 2.3. ### 0.12 | Package Name | Version | Package Id | | --------------------------- | ------- | ---------------------------------------------------------------- | | utility-commercials-v0 | 0.4.1 | fa5b1cc5c8368dff7c2e6a74aa2af9d520d755e2a508f44acd17343326e41839 | | utility-credential-app-v0 | 0.4.1 | e9a3b7df354dfd2f15c7d015328c34256308c90ba96f86f185dad58ffca8299b | | utility-credential-v0 | 0.1.0 | 5a29ead611a0abd5f5b3fc3caf7d0f67c0ff802032ab6d392824aa9060e56d70 | | utility-registry-app-v0 | 0.7.0 | 7a75ef6e69f69395a4e60919e228528bb8f3881150ccfde3f31bcc73864b18ab | | utility-registry-v0 | 0.6.0 | a236e8e22a3b5f199e37d5554e82bafd2df688f901de02b00be3964bdfa8c1ab | | utility-registry-holding-v0 | 0.2.1 | 8107899ac4723ce986bf7d27416534e576e54b92161e46150a595fb78ff3d3a1 | ## Previous DARs This is a list of DARs that were previously used but are now unsupported, which is kept here for reference. | Package Name | Version | Package Id | | --------------------------- | ------- | ---------------------------------------------------------------- | | utility-collateral-app-v1 | 1.0.0 | 6bb2a795fd783646676705085d6548175783a5e63dd9084a6792cb25b32769d0 | | utility-commercials-v0 | 0.0.1 | 43c23473b5b15a090d617fb1e45bc445951200453db607f8a02b214124b937ce | | utility-commercials-v0 | 0.1.0 | c40ba02fec104dc33afd60ed8ecfcfe69e8b65682fbfa7e7d4dfd2430a184754 | | utility-commercials-v0 | 0.2.0 | 8209a411cf3988feeaf56d5534199b54864955f1175e30880628299506c36ea4 | | utility-commercials-v0 | 0.2.1 | 20a934ae6b3f29230534b6640ea711ced761e8b3ad195ddf59f2cddc9c345ed6 | | utility-commercials-v0 | 0.2.2 | 6c656fb4169c35ec4c3be8d134fc4bc9a93e11fb5c939ab5a7e7e7f345f1b5dc | | utility-commercials-v0 | 0.3.0 | 2c9bf120ccbf831f4512536f984359bdd4d548a211858096d30ecdd7d704da0a | | utility-commercials-v0 | 0.4.0 | 4576f523725ab10bb489a64d81d195ab962e8d0dad5f26b2c3364ad1e4050617 | | utility-credential-app-v0 | 0.0.2 | 40830dd0e8381e35998ed2df4716f82a2cc7096ec1e718a8a314e92e8a301890 | | utility-credential-app-v0 | 0.1.0 | bbe070b706a3b8b18e5a5c108a4e5a9a4145f81d7dcf76c18a51664807377ddd | | utility-credential-app-v0 | 0.2.0 | 9d57b6f784ebcaa08ab7555e62c4e1c40d54f94d5a50613cdcc543c7c283f167 | | utility-credential-app-v0 | 0.2.1 | da2af36b42e336c5dff764ce9d445a09a32788626bc18c6cb0c9a52cbf160b68 | | utility-credential-app-v0 | 0.2.2 | e4beed1b8ae0506e63d6da04bffb447f8f406261dd64b9abf457c4655d031a6a | | utility-credential-app-v0 | 0.2.3 | 50c7e43393cf6017b017e9ae84e2ac322a6fe203f879addb02c0a49ac7952d3c | | utility-credential-app-v0 | 0.2.4 | 512449f872b9770ca1b2aab52eafd1e382f09b987227dbd849635a9cfec78a5a | | utility-credential-app-v0 | 0.3.0 | dd204b26bc3c7907f9e12d117d8290728fc9b5daa7669a405d4d87d8db53c7c5 | | utility-credential-app-v0 | 0.4.0 | 2fbf92ed701ff45c6d7133d824b925cd090ac8aabdd3cea09d4e1325c404d805 | | utility-credential-v0 | 0.0.1 | b5d1109eed821be936f295fdd348b0ad609c562311eb0c9d8e4607b747e41636 | | utility-credential-v0 | 0.0.2 | aa472491115b521b2855f869999b432c57f39fcb41ef68c659d12431f9d8ddd6 | | utility-credential-v0 | 0.0.3 | 77df4e7b980c12de438d7b052141a762215fae790d81f71179c8fb534beb68f7 | | utility-credential-v0 | 0.0.4 | 0207e2ca0b52468fc03dd81c69f13cfb54f57eb59bee5f75582ebe45dce63f3a | | utility-registry-app-v0 | 0.0.1 | 5a6f6551759c95a8a1b491c34c4f2b74d74737e2cb070c662639a7ed90280059 | | utility-registry-app-v0 | 0.1.0 | 98cdf68988bc8987227e90905458779957b3687d6a067b2314e7a4c9fe9f33fa | | utility-registry-app-v0 | 0.2.0 | 82798df018301852704f210b97adaabf76d3ecd37d889e1bf96b5f31a20eea34 | | utility-registry-app-v0 | 0.3.0 | 1f2ad7f61d511e44c4d9c42322b3ec304f60bcb0da0b72f26ff24a339d7e0e5b | | utility-registry-app-v0 | 0.3.1 | 8c335bb7d522489d71faf3eef046ad1a56f091b55b4f2d3086c7266afca1d647 | | utility-registry-app-v0 | 0.4.0 | 170929b11d5f0ed1385f890f42887c31ff7e289c0f4bc482aff193a7173d576c | | utility-registry-app-v0 | 0.5.0 | 2717412f011584c6001ef2229949661da69bbe49790c9fc2c2b7d35a479311ff | | utility-registry-app-v0 | 0.6.0 | 661151768d69141dfd6b757bdc348012b2a64b2c956ad586782f97d07408f264 | | utility-registry-holding-v0 | 0.0.1 | a83fb2d68f6f220f10da4e92146ff919ca9228fd467441e4c870b904ae9d516f | | utility-registry-holding-v0 | 0.0.2 | 3d443920585d7e53514839bc2ef4feff5df87adbd047a64b8e266e4b72c85418 | | utility-registry-holding-v0 | 0.1.0 | c8b555c1b5109c9b1d437af242d215f9a9714281c9cca2b3d7653cb8f9e7bfdc | | utility-registry-holding-v0 | 0.1.1 | 3dbbfe38deeda1e4d46a439eea4e89a9cabf5eb75b6fc7279663c5423eb125d3 | | utility-registry-holding-v0 | 0.1.2 | dd3a9f2d51cc4c52d9ec2e1d7ff235298dcfb3afd1d50ab44328b1aaa9a18587 | | utility-registry-holding-v0 | 0.2.0 | 112742269c282ab77490b7933f65582bc223e3bf6c120d81e0799cf0d99ecd9e | | utility-registry-v0 | 0.0.1 | d0c8b1c2d96c50c26c47e515d07302a55577013582ee65ec5931df4be610bf3b | | utility-registry-v0 | 0.1.0 | 3b25e7327b493bbe063e89d34fdacbfcc491007e5eabefea3a2919044a28f452 | | utility-registry-v0 | 0.2.0 | 28c80fcf2b947b7eb04c8d2de99ef7d320e68ec5fb07bb49feff8807735de73e | | utility-registry-v0 | 0.3.0 | 48f2042a95420b739a83529ac7cc669bc4f964e72a18e61593433224d6de07d4 | | utility-registry-v0 | 0.3.1 | b4ae77b8c0c7faa8bc8bb048f035dfe3d85d3e36d4bafaa4cf59631ec635ddb2 | | utility-registry-v0 | 0.4.0 | ed73d5b9ab717333f3dbd122de7be3156f8bf2614a67360c3dd61fc0135133fa | | utility-registry-v0 | 0.4.1 | fc7214ab1078eb1e0d6ce670f203423c54882bd043234364f3cb181c831d7dbd | | utility-registry-v0 | 0.5.0 | 672e7c8762314b1ac44dabb6f7b15f53f7078a062257395618e71d07b35336eb | | utility-settlement-app-v1 | 1.0.0 | d8a00b0c170f1b21c06634d6814a750fcf9a96fa7a8feebb2e444e053f0deb1f | | utility-settlement-app-v1 | 1.1.0 | 34ab886ee88b045637ff416f558734309f5650fec81a603cb5db76bbd863b950 | | utility-settlement-app-v1 | 1.2.0 | f169e1d84c476cb1321eff8ac2aebc9ce1c6b20790db5e788ee4ca87256a0639 | | utility-version-v0 | 0.0.1 | 42e902610f593c6fb5516d7a7401ad0892dc44507a777ace0a468a5f6c9d3381 | # Release Notes Source: https://docs.digitalasset.com/registry/releases/release-notes Release notes for Registry App releases. # 0.12 Source: https://docs.digitalasset.com/registry/releases/release-notes/0.12 ## DARs This release introduces the following DAR versions: | Package | Version | Package Id | | :-------------------------- | :------ | :--------------------------------------------------------------- | | utility-commercials-v0 | 0.4.1 | fa5b1cc5c8368dff7c2e6a74aa2af9d520d755e2a508f44acd17343326e41839 | | utility-credential-app-v0 | 0.4.1 | e9a3b7df354dfd2f15c7d015328c34256308c90ba96f86f185dad58ffca8299b | | utility-registry-app-v0 | 0.7.0 | 7a75ef6e69f69395a4e60919e228528bb8f3881150ccfde3f31bcc73864b18ab | | utility-registry-v0 | 0.6.0 | a236e8e22a3b5f199e37d5554e82bafd2df688f901de02b00be3964bdfa8c1ab | | utility-registry-holding-v0 | 0.2.1 | 8107899ac4723ce986bf7d27416534e576e54b92161e46150a595fb78ff3d3a1 | ## Features ### Batched Featured App Markers The Registry Daml workflows no longer create featured app activity markers. They are now generated through a batched app marker automation operated by Digital Asset. The automation ensures that the optimal number of app markers for Asset Issuers (Registry Providers) is applied in accordance with the latest tokenomics guidelines. In order to delegate the respective marker creation for your featured party to the DA operator, you need to opt in to that service. This can be done in the UI on the Registry Onboarding tab (click on Delegate Marker Creation which will create a `DelegatedBatchedMarkersProxy` instance). For users who continue to utilize the backward-compatible Registry workflows (versions `0.10` and `0.11`), please note that the Utility Operator Backend API will no longer provide the context required to create activity markers. This is in order to adhere to the latest Tokenomics guidelines. Additionally, this change is instrumental in reducing transaction costs incurred by the submitters of Registry transactions (detailed below). #### Additional Transaction Cost Reduction All registry workflows have undergone optimizations, leading to significant cost reductions across the board. The table below indicates the expected cost reduction for various workflows, assuming no third-party credentials and the minimal number of input holdings: | Workflow | Choice | Template | Approx. Cost (in USD) | Approx. Cost Reduct. (vs 0.11) | | :------------------ | :--------------------------------- | :------------------ | :-------------------- | :----------------------------- | | **Direct Transfer** | TransferFactory\_Transfer | TransferPreapproval | \$0.5 | 70% | | **2-Step Transfer** | TransferFactory\_Transfer | AllocationFactory | \$0.5 | 50% | | | TransferInstruction\_Accept | TransferOffer | \$0.4 | 50% | | **Merge** | TransferFactory\_Transfer | AllocationFactory | \$0.5 | 40% | | **BurnMint** | BurnMintFactory\_BurnMint | AllocationFactory | \$0.5 | 60% | | **Allocation** | AllocationFactory\_Allocate | AllocationFactory | \$0.5 | 50% | | | AllocationFactory\_ExecuteTransfer | DvpLegAllocation | \$0.4 | 50% | | **Burn Request** | AllocationFactory\_RequestBurn | AllocationFactory | \$0.3 | 60% | | | BurnRequest\_Accept | BurnRequest | \$0.3 | 60% | | **Burn Offer** | AllocationFactory\_OfferBurn | AllocationFactory | \$0.3 | 50% | | | BurnOffer\_Accept | BurnOffer | \$0.3 | 60% | | **Mint Request** | AllocationFactory\_RequestMint | AllocationFactory | \$0.3 | 30% | | | MintRequest\_Accept | MintRequest | \$0.3 | 60% | | **Mint Offer** | AllocationFactory\_OfferMint | AllocationFactory | \$0.3 | 50% | | | MintOffer\_Accept | MintOffer | \$0.3 | 60% | Note that the proportional cost reduction becomes even more pronounced as the number of input holdings increases. For instance, merging several UTXOs is now significantly cheaper than before. #### ExecutedTransfer and other Result Contracts * **Batch Archival:** A choice was added to the `RegistrarService` to allow for more cost-efficient batched archival of `ExecutedTransfer` and `RejectedTransfer` contracts. * **Observer Removal:** The operator has been removed as an observer on all result contracts, including `ExecutedTransfer`, `RejectedTransfer`, and all other Executed\* and Rejected\* contracts. #### Allocations and the TransferRule The execution of allocations now leverages the `TransferRule` via the newly introduced `TransferRule_ExecuteAllocation` choice. Consequently, a TransferRule instance of the token admin (or registrar) must exist for the execution to be successful. Furthermore, the TransferRule has been updated with dedicated choices to better distinguish the capacity in which the rule is invoked: * `TransferRule_TwoStepTransfer` * `TransferRule_DirectTransfer` This is a prerequisite for further planned enhancements of the TransferRule validation logic. ### Synchronizer ID Migration With the update of `utility.yaml` from 2.0.0 to 2.1.0, we have introduced `synchronizerId` to our utility endpoints. This new field uses the identical value as the existing `domainId`, which is now deprecated but remains available for backwards compatibility. We recommend that all users transition to `synchronizerId`. ### Documentation Updates the tutorials in the documentation to align with version 0.12.x. ### Independent Transaction Validation Introduced a new verification API that allows participants to submit an UpdateID and Transfer Object to independently confirm asset transfer outcomes on registry assets. The service provides standardized Success, Failure, Pending statuses, or invalid input. ### Historical Transfer Verification Enhanced the Transfer Proof API to retrieve proof data for pruned transactions, ensuring users can verify historical transfers even after ledger data has been archived. ### UX Improvements * The UX for self-issuing credentials was improved (this is typically used for Registry allowlists). * The deprecated `HolderService` is no longer visible in the UI. The `holderCredentialRequirements` field in `ProviderServiceConfiguration` is now hidden if empty and is zeroed out whenever the configuration is modified. ### Other Changes Splice dependencies were upgraded to splice-amulet-0.1.16. ## Deprecation and Supported Versions This version removes support for the 0.9.x release line. All users must be running the Daml models shipped with at least the 0.10.x release line. The `HolderService` has been deprecated since version 0.8.0. Providers with active `HolderService` instances are encouraged to archive them and zero out the corresponding holder requirements on their `RegistrarConfiguration` (this can be done swiftly via the UI). In the next release, it is planned to fully disable HolderServices in Daml via ensure false clauses. The legacy 3-step mint and burn flows have been disabled in Daml. ## Integration Guide and Backwards Compatibility ### Tokenizers * For the purpose of batched app marker creation, featured providers should delegate app marker creation to the operator via the newly introduced `DelegatedBatchedMarkersProxy` template at their earliest convenience. In the UI, go to the Registry Onboarding tab and click on the Delegate Marker Creation button (once the operator has deployed the packages which enable the release). To ensure uninterrupted marker creation until this is in place, the operator's featured app right will be used as an interim solution. * Additionally, Tokenizers should be following the Canton Foundation's Validator release schedule and ensure they are on a recent version of Splice to ensure uninterrupted marker creation. * In order for executions of allocations to be successful, token administrators (or registrars) need to ensure the token has a corresponding `TransferRule` instance, otherwise the transaction will fail. ### Wallet Providers Wallet providers that support Utility assets need to ensure they can successfully parse transfers for the purpose of showing transaction history. Two-step transfers have transitioned from using the `TransferRule_DirectTransfer` choice to the newly introduced, dedicated `TransferRule_TwoStepTransfer` choice. ### Third-Party Applications All other third-party applications (such as exchanges composing with the Utility over the Token Standard Allocation workflow) should upload and vet the latest Daml packages. There are no additional steps required. # 0.13 Source: https://docs.digitalasset.com/registry/releases/release-notes/0.13 ## DARs This release introduces the following DAR versions: | Package | Version | Package Id | | :-------------------------- | :------ | :--------------------------------------------------------------- | | utility-registry-app-v0 | 0.8.2 | 2293eb12e82ceaeb3ff7f8fe3346dece8578e1e9fd7d46624aeb7bb07fa31eda | | utility-registry-v0 | 0.7.1 | 1f80e086e9ce218cf93fdeed80943793e902ac35c521733d7373a5ba58813150 | | utility-registry-holding-v0 | 0.2.2 | 71fbaea211f07a65666892748498bd4a0d7462a9d75bbb215ba9fbdbba78efa7 | | utility-credential-app-v0 | 0.4.2 | 3f0341b825b1e2cc94b3b216303e5497f0adf2bae0f1dc6e16e19d7aa955a6d6 | | utility-credential-v0 | 0.1.1 | 418370044b5c6cd76ec78b73b8553c592328dec0afb6defbd2fdc5909e024033 | DAR bundle archive (.tar.gz) Checksum file These DARs are compiled using Daml LF 2.3. If you are running PQS, please ensure you are at least on version `3.5.5` before uploading these DARs to your validator node. Previous versions of PQS are not compatible with Daml LF 2.3. ## Features ### Blocklist A party with the `Registrar` role can now define a blocklist of parties that are not allowed to transfer / mint / burn instruments for which the blocklist check is enabled. The `InstrumentConfiguration` contract has been extended with a `checkBlocklist` field, which can be set to `True` to enable the blocklist check for that instrument. More details can be found in the [Blocklist Guide](/registry/guides/blocklist). ### UI changes Transfer history display in the UI no longer relies on `ExecutedTransfer` contracts, but reads the ledger's transaction trees directly. Paginated query endpoints introduced in Canton 3.5 are used in order to improve the responsiveness of the UI. The Collateral tile is no longer shown, as the app has been decommissioned following a series of successful pilot trades. The UI no longer displays the user's Canton Coin balance, as this can be retrieved from dedicated wallets. The UI no longer offers the ability to create paid credentials. ### Disclosure endpoints for Mint / Burn workflows An optional `extraArgs` argument has been added to the `BurnRequest_Cancel`, `MintRequest_Cancel`, `BurnOffer_Cancel`, and `MintOffer_Cancel` choices. Corresponding operator backend endpoints serve the execution context for these choices. This is currently always empty, but will be used in future releases to allow for more flexible mint / burn workflows. ### Batch archival of `Executed*` Contracts A choice was added to the `RegistrarService` to allow for more cost-efficient batched archival of executed mint/burn contracts. ### Changes to the `DvpLegAllocation` ensure clause The `DvpLegAllocation` ensure clause was strengthened to enforce `sender /= receiver` and `amount > 0.0`. These conditions were already validated at execution time, but checking them in the ensure clause surfaces failures earlier. The temporal ordering check was also relaxed from `requestedAt < allocateBefore < settleBefore` to `requestedAt <= allocateBefore <= settleBefore`. ### Auto top-up app The auto top-up app for paid credentials and commercial agreements has been decommissioned. ### Other Changes Splice dependencies were upgraded to `splice-amulet-0.1.20`. Daml models are now compiled using LF 2.3. ## Deprecation and Supported Versions This version removes support for the `0.10` release line. All users must be running the Daml models shipped with the `0.11` release line at a minimum. ## Integration Guide and Backwards Compatibility ### Tokenizers Tokenizers that integrate with the Burn / Mint workflows over their API should adapt their integration to * source the execution context for the `BurnRequest_Cancel`, `MintRequest_Cancel`, `BurnOffer_Cancel`, and `MintOffer_Cancel` choices from the corresponding backend endpoints * populate the new `extraArgs` field with the result from the previous step In order to ensure backwards compatibility with users running earlier Daml models, we recommend setting `extraArgs` to `None` if an empty choice context is returned. ### Third-Party Applications The execution context for transfers and allocations might include the blocklist, should the instrument admin enable the blocklist check for the instrument. No action is required by third-party applications, unless custom logic is used to produce the execution context. ### Wallet Providers The execution context for transfers and allocations might include the blocklist, should the instrument admin enable the blocklist check for the instrument. No action is required by wallet providers, unless custom logic is used to produce the execution context. # 0.14 Source: https://docs.digitalasset.com/registry/releases/release-notes/0.14 ## DARs The `0.14.4` release introduces the following DAR versions: | Package | Version | Package Id | | :-------------------------- | :------ | :--------------------------------------------------------------- | | utility-registry-app-v0 | 0.9.2 | 1eddd268bdd50d6e262722bea799c9455da032b3f94489e589975151b274b8c0 | | utility-registry-v0 | 0.8.2 | 8c654487d9f5fb195fbcdd7b44cd8e365b1ea39c15ae62ce6c7a48343f1210dd | | utility-registry-holding-v0 | 0.3.2 | 415a1ec96a9e2839453e9aa1c5c71b6511c008c79511cb6f873e0b7393fe3b92 | | utility-credential-app-v0 | 0.4.3 | 87d6bfac3adf937cf5f603767f440a3b60416c2dfd9f82346455547972f5e236 | | utility-credential-v0 | 0.1.2 | 044be226f82e81609111569fb7253421cdb86b2bf0ecab781f46a58003e69574 | DAR bundle archive (.tar.gz) Checksum file ## Features ### Support for Token Standard v2 ([CIP-112](https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md)) The Token Standard v2 workflows are now supported in the Registry App. Moreover, non-v2 workflows have been enhanced to emit events through the CIP-112 `EventLog` interface. ### Support for account id selection on CIP-56 transfers Asset holders can specify a textual sender and receiver label (account id) when instructing a transfer and creating an allocation. The receiver label will be set on `Holding` contracts using the textual `label` field. ### V2 allocations and cross-version compatibility The V1 allocation (`DvpLegAllocation`) provides cross-version compatibility with V2 settlement. The V1 allocation factory supports sender and receiver accounts, as well as additional executors, through `allocation.settlement.meta`. Additional executors are added as observers on the allocation (with the `withAdditionalExecutorsAsObservers` field set to `Some True`). V1 allocations have more limited privacy semantics. Users who need V2 committed or iterated settlement, or stronger privacy guarantees, can use the V2 allocation (`AllocationV2`). For more information, see the [CIP-112 documentation](https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md). ### Removal of ExecutedTransfer, ExecutedMint, ExecutedBurn `ExecutedTransfer`, `ExecutedMint`, and `ExecutedBurn` contracts are no longer created upon execution of the corresponding workflows. ### Other Changes A choice has been added to the `InstrumentConfiguration` to let the operator archive duplicate contracts. The `Holding_Transfer` choice on the `Holding` template has been disabled. Self-allocations (where sender equals receiver) for CIP-56 can be created again, after being disabled in `0.13`. To use direct transfer, senders must select the "" receiver label. Choosing any other label will default to the standard two-step transfer, requiring the receiver to accept the holding. ## Release history and compatibility issues During the `0.14` release cycle, we discovered compatibility issues in releases `0.14.1` and `0.14.2` which forced us to release new Daml models to resolve the problems. **Upgrade guidance:** * If you are not yet on `0.14` releases, upgrade directly to `0.14.4` (skip `0.14.1` and `0.14.2`). * If you are currently running `0.14.1` or `0.14.2`, upgrade to `0.14.4` as soon as possible. * If you have any questions or concerns about the upgrade, please contact us for support. **Unvetting schedule:** We will unvet the `0.14.1` and `0.14.2` DARs in the respective environments on Thursday, September 17, 2026, due to the compatibility issues described below. Below is a detailed explanation of the compatibility issues and fixes in each patch. ### Patch 0.14.4 Compared with `0.14.2`, `0.14.4` updates the Registry DARs as follows: | Package | 0.14.2 version | 0.14.4 version | | :-------------------------- | :------------- | :------------- | | utility-registry-app-v0 | 0.9.1 | 0.9.2 | | utility-registry-v0 | 0.8.1 | 0.8.2 | | utility-registry-holding-v0 | 0.3.1 | 0.3.2 | The credential DARs remain unchanged from `0.14.2`. #### Additional executors as observers (compatibility fix) In `0.14.4`, the `withAdditionalExecutorsAsObservers` field on `DvpLegAllocation` is set to `None` when no additional executors are provided in the metadata, and to `Some True` otherwise. This preserves backwards compatibility with users on versions `0.13.x` or earlier while retaining additional-executor visibility for newer versions. ### Patch 0.14.2 Compared with `0.14.1`, `0.14.2` updates the Registry DARs as follows: | Package | 0.14.1 version | 0.14.2 version | | :-------------------------- | :------------- | :------------- | | utility-registry-app-v0 | 0.9.0 | 0.9.1 | | utility-registry-v0 | 0.8.0 | 0.8.1 | | utility-registry-holding-v0 | 0.3.0 | 0.3.1 | The credential DARs remain unchanged from `0.14.1`. #### V1 wallet compatibility in 0.14.2 In `0.14.1`, all input holdings had to use the sender's specified label (account ID). Earlier versions allowed any label, provided all input holdings used the same label. The `0.14.2` release relaxed this requirement: holdings can now use different labels, and any excess input holdings are returned to the specified sender account. This applies to all Token Standard factory choices. As V1 wallets are unaware of accounts, they source input holdings using any label (account ID). If labels are mixed and no account ID filtering is applied, the transaction will only succeed for users on version `0.14.2` or later, unless V1 wallet providers add that support. See [Compatibility with V1 wallets on old Registry versions](/registry/apis/token-standard/compatibility-v1-wallets) for detailed guidance and mitigation strategies. #### Align account ID handling with mint and burn flows Custom mint and burn flows now handle account IDs consistently with transfer flows. A receiver `account.id` in `mint.meta` specifies the label for the minted holding. Likewise, a sender `account.id` in `burn.meta` specifies which holding label to burn. Both fields default to `""` when omitted. All involved parties must use version `0.14.2` or later for this behavior to take effect. ## Deprecation and Supported Versions This version removes support for the `0.11` release line. All users must be running the Daml models shipped with the `0.12` release line at a minimum. ## Integration Guide and Backwards Compatibility ### Tokenizers Before consuming this release, tokenizers must ensure that they do not rely solely on `ExecutedTransfer`, `ExecutedMint`, and `ExecutedBurn` contracts for transaction history parsing. If you currently rely on such contracts, the [Transaction History Parsing Guide](/registry/guides/tx-history-parsing) describes the different parsing guidelines and illustrates a migration path. ### Third-Party Applications CIP-56 workflows that utilize input holdings of the same label (e.g., the empty string "") will continue to function as before. To interoperate with V1 wallet users having mixed input labels, third-party applications should implement input holding filtering or make sure all users are on the `0.14.4` DARs. See [Compatibility with V1 wallets](/registry/apis/token-standard/compatibility-v1-wallets) for detailed guidance and mitigation strategies. To support accounts as specified in CIP-112 in both CIP-56 and CIP-112 workflows, third-party applications must upgrade their applications (see [Compatibility Rules for CIP-112](https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md#51-compatibility-rules) ). Instrument admins indicate their support for CIP-112 via a Token Standard metadata endpoint (see [Support of Token Standard V2 (CIP-112) for a given instrument admin](/registry/apis/token-standard#support-cip-112-instrument-admin) ). ### Wallet providers CIP-56 workflows that utilize input holdings of the same label (e.g., the empty string "") will continue to function as before. To interoperate with V1 wallet users having mixed input labels, V1 wallet providers should implement input holding filtering or make sure all users are on the `0.14.4` DARs. See [Compatibility with V1 wallets](/registry/apis/token-standard/compatibility-v1-wallets) for detailed guidance and mitigation strategies. To support accounts as specified in CIP-112 in both CIP-56 and CIP-112 workflows, wallet providers must upgrade their applications (see [Compatibility Rules for CIP-112](https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md#51-compatibility-rules) ). Instrument admins indicate their support for CIP-112 via a Token Standard metadata endpoint (see [Support of Token Standard V2 (CIP-112) for a given instrument admin](/registry/apis/token-standard#support-cip-112-instrument-admin) ). # Versioning Source: https://docs.digitalasset.com/registry/releases/versioning Versioning for the Registry App and backwards-compatibility guarantees. Registry App versions are numbered using an `X.Y` format. `X` represents the major version, and `Y` represents the minor version. Each minor release adopts a new set of Daml models. These are [compatible upgrades](https://docs.canton.network/appdev/deep-dives/smart-contract-upgrade) of the models released in the previous minor release. The major version is incremented when there are breaking changes that require an extensive contract migration. We follow a staggered roll-out approach, where a new release is first rolled out to `DevNet`, then `TestNet`, and finally to `MainNet`, at 1 week intervals. ## Backwards compatibility At any given time, we strive to support the two minor versions before the current release. For instance, together with the rollout of `0.12`, we would be dropping support for version `0.9`. What that means is that we expect transactions submitted using `0.9` versions of the Daml packages to fail. We however expect transactions submitted using `0.10` or `0.11` package versions to continue to work. Our current release schedule of at most one release per month should provide sufficient time to upgrade to the new package versions. Deprecation of the old version, as well as the target upgrade path for integrations, is communicated as part of the release notes. ## Adopting a new release In order to adopt a new release, it is sufficient for the newly introduced Daml packages to be uploaded and vetted by the operator of your validator node. If you have built off-ledger or on-ledger integrations with the Registry App, you should only adopt a new release once you have verified that your integration can consume it on one of the lower environments. We provide an Integration Guide as part of the Release Notes for each release. # Audits Source: https://docs.digitalasset.com/registry/security/audits Smart Contract as well as Application safety and security is paramount to us. Therefore we regularly conduct On & Off-Chain audits with reputable auditors. ## Security Philosophy Our top priority is to systematically mitigate and reduce potential risks through a multi-layered security approach: * **In-Depth External Audits** * Collaborating with leading security researchers to identify potential vulnerabilities, logical edge-case errors, and structural inefficiencies * **Continuous Monitoring** * Ongoing on-chain tracking and alerting framework deployments to watch over smart contract and application interactions post-launch > 🔒 **Security Reporting:** Found a potential vulnerability? Please do not open a public issue. Reach out directly to our security team at [**security@digitalasset.com**](mailto:security@digitalasset.com). # Completed Audits Below is the chronological overview of our completed technical security reviews. Click on any section to view the specific audit scope and access the official PDF assessment reports. ### Overview CertiK conducted a security assessment focused on the Daml smart contracts that implement the xReserve functionality on Canton Network. The review centered on workflows that coordinate attestation for deposits/withdrawals, authorization controls, and USDCx lifecycle management, which also included the whole DA Registry set of functionalities. ### Scope Details * **Daml:** Registry & xReserve Contracts * **Off-chain components:** xReserve Backend Download Executive Summary (PDF) ### Overview CertiK completed a comprehensive security assessment for Digital Asset, evaluating the Daml smart contracts for the Digital Asset Registry alongside Off-Chain components across both frontend and backend repositories. Employing a methodology of static analysis, manual review, dynamic execution testing, and architectural threat modelling, the audit evaluated system-critical components, including utility APIs, credential workflows, operator automation, contract archival and reward processing interacting with the Canton ledger. ### Scope Details * **Daml:** DA Registry Smart Contracts * **Off-chain components:** DA Registry Frontend & Backend # Monitoring Source: https://docs.digitalasset.com/registry/security/monitoring Ensuring highly available, performant and reliable services for our clients ## Overview Digital Asset actively monitors the suite of services that support the functionality of the **Registry** application on Canton Network. We maintain a comprehensive observability strategy that facilitates our **24/7 Global Support Team** to: * **Detect**: Identify infrastructure anomalies and performance regressions in real time. * **Diagnose**: Rapidly isolate root causes across distributed systems. * **Resolve**: Mitigate operational issues swiftly; often before they impact clients. The following sections provide a technical overview of how we monitor our production environment, manage telemetry data and maintain continuous operational resilience. Digital Asset support teams are geographically distributed across the world, utilising the "follow-the-sun" model to ensure 24/7 coverage. Teams in different time zones have overlapping shift windows, daily handoffs, a shared knowledge base amongst other procedures and tooling at their disposal to ensure the availability and reliability of our services for our customers. A 24/7 on-call rotation is maintained to ensure our systems are available to respond to any incidents or raised alerts: | Severity | Definition | | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Application is not operational and/or all production data is inaccessible. Dataflow is completely stopped resulting in a critical impact on the client's business. **No workaround** is available. | | 2 | Application is operational but severely restricted functionality or degradation impacting the client's operations. **No workaround** is available. | | 3 | Application is operational with functional limitations or restrictions that are not critical to the overall client's operations. | | 4 | Application is operational with no current impact on client's operations, but errors have been identified that will potentially impact client operations. | We employ a consolidated, best-in-class tooling ecosystem to monitor our services: Native cloud based metrics and logging for baseline resource health across our entire cloud footprint (Compute, Kubernetes, SQL, etc.). A single pane for dashboards, metrics and distributed tracing (APM) which provides insights from the overall health of our services to tracing individual requests through our distributed system. Alerts are generated by our cloud infrastructure and centralised observability stack, and get routed to the correct team with both the alert context and severity rating. Critical alerts contain a **runbook** to assist engineers on how to investigate and mitigate issues quickly. For instructions on configuring monitoring for your own validator, please consult the Canton Network documentation [here](https://docs.canton.network/global-synchronizer/production-operations/monitoring-setup). # Security Practices Source: https://docs.digitalasset.com/registry/security/security-practices Our security stance. Security is a fundamental part of how we operate. We recognise that firms using our **Registry** application entrust us with sensitive information and technology supporting the issuance, management and transfer of tokenised assets. We therefore take a structured, risk-based approach to security across our people, processes and technology. Security is embedded across our technology, processes and operations, with dedicated leadership, disciplined controls and ongoing independent assessment. Security has dedicated senior oversight through our CISO function, with responsibility for maintaining and continuously developing our security programme. Our security approach is supported by: * Ongoing risk assessments * Independent testing and assurance * Relevant industry certifications and standards Digital Asset attests to SOC2 and is certified to ISO27001 annually. For further information on our security posture, controls and certifications, please visit our [Trust Center](https://www.digitalasset.com/trust-center). We apply established security practices to harden our infrastructure and production environments. Development, testing and production environments are segregated to reduce operational risk and limit the potential impact of security events. Our infrastructure is regularly assessed and maintained. No production data is used for testing or in non-production environments. Access to production systems is tightly controlled and granted according to role and business need. Access is granted on a just-in-time, peer approved basis with no standing permissions to production for any staff. Sensitive access is subject to peer review and regular permission reviews to ensure that access remains appropriate and limited to what is required. Privileged activity is subject to appropriate oversight and control. We maintain continuous monitoring and observability across our production environment to identify anomalous activity, operational issues and potential security events. Established processes support the timely investigation, escalation and response to identified issues. Critical data is backed up using controlled processes designed to support recovery and business continuity. Our approach to data resilience forms part of our broader operational risk and recovery planning, which includes regularly testing and validating our Disaster Recovery procedures. Disaster recovery test results may be available upon request, subject to an NDA. Security is considered throughout the software development lifecycle. Our development practices incorporate appropriate peer review and testing, and third-party libraries and dependencies are continuously assessed for known vulnerabilities and licensing. Identified vulnerabilities are evaluated and remediated according to their risk, potential impact and exploitability. Details of completed smart contract audits and reviews of our off-chain components are available [here](https://docs.digitalasset.com/registry/security/audits). Security is an ongoing responsibility. We regularly review our controls, assess emerging risks and use the results of monitoring, testing and independent assurance to strengthen our security programme over time. # Contact & Support Source: https://docs.digitalasset.com/registry/support/contact Get in touch with the Digital Asset team for product inquiries or technical assistance. Whether you want to explore our enterprise solutions or require technical assistance with an active deployment, the Digital Asset team is here to help guide you. Connect with a specialist to explore our products, services, or to receive a comprehensive overview of the **Canton Network**. Are you an existing client? Log in to our dedicated service desk to submit technical tickets and track issue resolutions. ## What to Expect * **Product Inquiries:** After submitting a request through our website, a Digital Asset specialist will reach out to schedule a discovery call tailored to your organization's infrastructure goals. * **Technical Support:** Tickets submitted through our Atlassian Service Desk portal are routed directly to our engineering support queues to ensure rapid resolution in accordance with your service-level agreements (SLAs). # Frequently Asked Questions Source: https://docs.digitalasset.com/registry/support/faq Got questions about the DA Registry? Find answers about integration, security, wallet connections, and compliance controls here. Welcome to the DA Registry FAQ. If you cannot find the answer you are looking for here, please reach out to your [Digital Asset support representative](https://digitalasset.atlassian.net/servicedesk/customer/portals). ## General & Platform The DA Registry is designed for organizations that want to operate a tokenization platform. This includes: * **Issuers:** Organizations looking to deploy and operate the DA Registry to issue their own native digital assets. * **Platform Providers:** Entities wanting to offer a turnkey tokenization platform for their clients to issue assets into the network. The DA Registry provides the secure, onchain infrastructure needed to get production-ready tokenization up and running quickly. **No, but it is its direct evolution.** The DA Registry evolved from the tokenization tooling originally included in the Canton Network Utilities toolbox. It has been carved out as a dedicated, stand-alone application, receiving a UI/UX & Brand refresh to deliver a comprehensive, purpose-built experience. The underlying business workflow and smart contract logic remained intact.  The DA Registry dApp UI (decentralized app) is a user interface centrally hosted and provided by DA, so that you don't have to deploy and host the UI with your validator. It enables asset issuers to quickly launch and manage onchain assets on Canton. By leveraging this fully hosted experience, asset issuers can skip the costly and time-consuming process of building and maintaining a custom front-end interface. ## Getting Started & Integrations ### How do I get started? Select one of our paths below to begin your integration journey with the DA Registry: Learn how to access and navigate the pre-built DA Registry user interface to start managing assets. Explore how to integrate DA Registry's robust APIs directly into your core business systems.
You can connect using any CIP-103 compliant wallet or institutional custody provider to start issuing assets via the Registry UI. If you are running your own validator, you can utilize the **Wallet Gateway** to seamlessly connect to the Registry using your preferred enterprise signing provider, such as: * **Fireblocks** * **BitGo** * **Blockdaemon** * **Dfns** CIP 103 compliant wallets: ## Compliance & Security The DA Registry provides granular compliance control capabilities for onchain assets operating on the Canton Network through two primary tools: #### 1. The Credentials Contract This contract enables you to attach verifiable claims to trusted parties on the network, supporting flexible permissioning use cases like KYC. *For example: After onboarding and verifying a financial institution through an off-ledger KYC process, an asset issuer can instantly record that verified credential onchain.* #### 2. On-Ledger Allowlist / Blocklist DA Registry provides a cryptographically verifiable, on-ledger list that allows asset administrators to programmatically enforce transfer rules. This dynamically blocks or permits actions in the **mint**, **transfer**, and **burn** logic to satisfy strict regulatory compliance and sanction-screening workflows. ### Who audits the DA Registry smart contracts and how often? Our smart contracts undergo rigorous, independent third-party audits by **CertiK** as a core component of our security and risk management protocols. [**Click here to view our latest official audit reports.**](/registry/security/audits) # Onboarding Roles Source: https://docs.digitalasset.com/registry/tutorials/issuance/1-onboarding-roles ## Onboarding credential services for all entities All entities request credential service from DA, the Operator. | Actor | Utility Module | | --------- | -------------- | | Provider | CREDENTIAL | | Registrar | CREDENTIAL | | Issuer | CREDENTIAL | | Investor1 | CREDENTIAL | Select ONBOARDING on the left navigation. Click REQUEST CREDENTIAL USER SERVICE on the right side. A request is shown in the REQUESTS table in the REQUESTS tab. The request is automatically accepted in the DevNet. Now the credential service is created in the SERVICES table. Request credential service ## Provider credential DA as the Operator offers a credential to Provider. Provider accepts this credential offer. | Actor | Utility Module | | -------- | -------------- | | Provider | CREDENTIAL | Select OFFERS on the left navigation. If there is a credential offer, click ACCEPT. Then select CREDENTIALS on the left navigation. The onboarding credential for onboarding provider will be there. Provider accepts credential ## Onboard Provider | Actor | Utility Module | | -------- | -------------- | | Provider | REGISTRY | Select ONBOARDING on the left navigation. In the Services box, click REQUEST PROVIDER SERVICE. A request is shown in the Requests box. (Wait for acceptance by the Operator). Once accepted, a Provider Service is created. Now Provider is onboarded as a Provider. Request provider service ## Onboard requirements for registrars and holders Here Provider specifies the credential requirement, i.e. what credentials are needed in order to be onboarded as a registrar or a holder. | Actor | Utility Module | | -------- | -------------- | | Provider | REGISTRY | Select CONFIGURATIONS on the left navigation. In the Provider Configurations box, click CREATE PROVIDER CONFIGURATION. Provider configuration step 1 A window pops up for input. Provider configuration step 2 In this demo, the credential requirements are designed as follows: | Role in Registry | Credential Requirements | | ---------------- | ----------------------------------------- | | Registrar | \[holder] \[hasRegistryRole] \[Registrar] | Under Required Credentials for Registrars, click ADD. * In the Credential Issuers, paste the Provider's Party ID. * Then under Claim Requirements (where subject is the holder), click ADD. * In Property, input hasRegistryRole. * In Value, input Registrar. Provider configuration step 4 Then click CREATE. The provider configuration is created. Provider configuration complete ## Provider offers Registrar credential Provider offers a free credential to Registrar. | Actor | Utility Module | | -------- | -------------- | | Provider | CREDENTIAL | Select CREDENTIALS on the left navigation. Click OFFER FREE CREDENTIAL. A window pops up for input. Click OFFER. A credential offer is created (check OFFERS on the left navigation). The Registrar can then accept the credential offer.