0.14

​

DARs

The 0.14.4 release introduces the following DAR versions:

​

Features

​

Support for Token Standard v2 (CIP-112)

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.

​

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.

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: 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: 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 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 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 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 ). 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 ).

​

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 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 ). 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 ).