> ## Documentation Index
> Fetch the complete documentation index at: https://docs.digitalasset.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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)
).