Skip to main content

​
DARs

This release introduces the following DAR versions:

Download 0.14 DAR Bundle

DAR bundle archive (.tar.gz)

Download SHA-256 Checksum

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

​
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. This identifier will be set on Holding contracts using the textual label field.

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

​
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, 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

This release is backwards-compatible. Third-party applications that wish to use CIP-112 workflows must make sure that the target instrument admin supports CIP-112. See Support of Token Standard V2 (CIP-112) for a given instrument admin for details.

​
Wallet providers

This release is backwards-compatible. Wallet providers that wish to use CIP-112 workflows must make sure that the target instrument admin supports CIP-112. See Support of Token Standard V2 (CIP-112) for a given instrument admin for details.