0.11 Release Line

0.11.1

  • This patch release fixes a regression in the Helm chart where the ingress proxy’s VirtualService object gets deployed regardless of whether Istio support is enabled in the Helm chart’s values.yaml.

0.11.0

New Registry Utility features

Pre-approvals for direct Transfers

Registry Tokens now support direct transfers using pre-approval contracts, significantly improving the transfer experience.

Asset holders (for example, wallet users) can proactively grant transfer pre-approvals per asset administrator and optionally per instrument. Once in place, authorized transfers can be executed seamlessly without requiring additional receiver interaction for each transfer.

This design enables a smooth and controlled transfer experience while preserving privacy and user control. Unlike public-chain token models, asset holders cannot be spammed with unsolicited or dummy token transfers, as all incoming transfers must be explicitly pre-approved.

Impact

  • Improves transfer UX for wallets and operational flows

  • Reduces the overall traffic cost

  • Prevents unsolicited token transfers at the protocol level

Detailed guidance on conducting direct transfers is available in the Transfer Workflow section of the documentation.

Managed Allowlists

The Registry Utility enforces compliance directly at the smart contract level by embedding credential checks into the minting, transfer, and burn authorization logic. For transactions with assets that have credential requirements, parties must hold valid credentials, preventing transfers to non-compliant or unauthorized parties without relying on off-chain controls.

This release introduces managed allowlists to simplify onboarding for regulated assets that require KYC. Asset administrators (or parties designated by them) can now maintain an allowlist unilaterally, without requiring the KYC-verified party to hold credentials or interact with the Credential Utility.

This change allows users who do not have access to the Credential Utility to hold regulated assets.

There is no action required from credential holders or issuers: the existing credential logic remains fully supported.

Impact

  • Accelerates onboarding for regulated assets

  • Reduces dependency on end-user credential setup during initial access

  • Maintains consistent compliance enforcement

You can find information on using allowlists in the Credential Requirements section of the documentation.

New Registry Utility features

Flush expired deposits

The deposit on the Credential Billing and Commercial Agreement contract is locked for 30 days. If it is not used before that time, the deposit is automatically unlocked and returned to the user. This breaks the Credential Billing and Commercial Agreement contracts, because they contain a reference to an expired UTXO.

In this release a new choice FlushExpiredDeposit is added to these contracts. That will remove the expired deposit and reset it to 0, so that users can top up their deposits as usual again.

UX improvements

When onboarding an instrument admin (registrar), the TransferRule and AllocationFactory are automatically instantiated. The user has the choice to opt out of this behaviour.

Utilities Helm Chart

  • Added resource bocks to all containers in all workloads to allow you to specify CPU/memory requests/limits.

  • New image values bock, for overriding repo and tag across all utilities containers.

  • Deprecated: The imageRepository field is deprecated: use image.repo instead.

  • Added Istio support. The chart will now deploy VirtualService objects if you use the istioGateway value. The hostname will be taken from the frontend.hostname value.

Other changes

This release includes a number of security improvements on the Utility Daml models, as well as the Docker image for the UI.

Daml packages are now compiled with the latest 3.4 SDK and LF 2.2.

Deprecations and supported versions

This version of the Utility removes support for the 0.8.x release line. All users must at a minimum be running the Daml models shipped with the 0.9.x release line.

The legacy 3-step workflows for lock, unlock, and transfer are now deactivated.

Backwards compatibility

The application strives to be backwards compatible with previous versions:

  • If a user has set up a TransferPreapproval, but the sender or instrument admin are not on the latest packages, we will provide the standard “2-step” TransferFactory on requests for the transfer context.

However:

  • Users onboarded via an allow-list mechanism can not interact with older Utility versions, where these contracts are not supported.

Integration guide

API integrations

Users who interact with the Utility models over the API need to make sure they can support the direct transfers that result from the introduction of transfer pre-approvals (i.e. they should no longer assume that a TransferInstruction is created as a result of making a call to TransferFactory_Transfer).

Wallet providers

Wallet providers that support Utility assets need to ensure they can successfully parse direct transfers for the purpose of showing transaction history.

Moreover, they can add support for the creation of the TransferPreapproval template.

Third-party applications

Third-party applications (such as exchanges composing with the Utility over the Token Standard Allocation workflow) should upload and vet the latest Daml packages, in order to support allow-list validations.