0.15

​

DARs

This release introduces the following DAR versions:

​

Features

​

Force transfer

Registrars can now enable force transfer when they create an instrument. For an instrument with force transfer enabled, the registrar can transfer holdings from any holder back to itself, without the holder’s approval. The setting can’t be changed after the instrument is created. Force transfer is disabled for all existing instruments. Registrars can create such instruments and perform force transfers in the Registry UI, or programmatically with the new Holding_ForceTransfer choice. Force transfers appear in the holder’s transaction history. For more information, see Force Transfer and the Force Transfer guide.

​

Pause and unpause instruments

Registrars can now pause an instrument, for example to respond to a security incident or a regulatory hold. While an instrument is paused, other parties can’t mint, burn, transfer, or allocate it. The registrar can still administer the instrument, and actions where the registrar itself is the holder, sender, or receiver aren’t blocked. Pausing an instrument doesn’t affect the registrar’s other instruments. Registrars pause and unpause an instrument in the Registry UI, or programmatically with the new isPaused field of the instrument configuration. For more information, see Pause / Unpause and the Instrument Pause guide.

​

Registry UI uplift

The Registry UI has been redesigned. Changes include:

• A new instrument management page. The instrument configuration page now uses tabs, and includes the blocklist.
• Holdings, mint request, burn request, and transfer offer dialogs moved to side drawers.
• The onboarding page shows the operator only its own registrar services and requests.
• An improved UX for managing allow lists.
• Support for additional instrument identifiers.
• The UI now queries active contracts via paginated endpoints for configurations and onboarding, which improves responsiveness for parties with many contracts.

​

Batch deletion of executed transfers by providers

Providers can now exercise RegistrarService_DeleteExecutedTransfers to archive executed transfer contracts in batches.

​

Blocklist shard creation

The RegistrarService_CreateBlockListShards choice can only be exercised successfully once per RegistrarService instance. This prevents creating duplicate blocklist shards.

​

Other changes

The Daml models are now built with the --explicit-serializable=yes option. Data types stored on the ledger now explicitly derive Serializable. This doesn’t change the data stored on the ledger. The Splice dependencies were upgraded to splice-amulet-0.1.24 and splice-util-0.1.8.

​

Removed and disabled functionality

The following templates and choices, which were deprecated in earlier releases, are now disabled with ensure False clauses or fail when exercised:

• The legacy 3-step burn, mint, lock, unlock, and transfer templates in utility-registry-v0 (for example BurnRequest, MintRequest, LockRequest, UnlockRequest, and TransferRequest, together with their offer, accepted, rejected, failed, and executed counterparts).
• The Holding_Lock choice on the Holding template. It was redundant and required strong authorization from the registrar, the owner, and the lockers.

The holderRequirements field of ProviderService_CreateProviderConfiguration is no longer used and must be set to []. Providers with existing ProviderConfiguration contracts should set holderRequirements to []. A future release will enforce this with an ensure clause.

​

Deprecation and Supported Versions

The 0.12 release line will be deprecated as of January 31, 2027. All users must be running the Daml models shipped with the 0.13 release line at a minimum.

​

Integration Guide and Backwards Compatibility

​

Tokenizers

To use force transfer for an instrument, enable it when you create the instrument. The participant nodes hosting holders must have vetted utility-registry-holding-v0 version 0.4.0 or later for you to force transfer their holdings. Providers with existing ProviderConfiguration contracts should set holderRequirements to [].

​

Third-Party Applications

No action is required by third-party applications. Applications that show holdings or the transaction history can follow the Force Transfer guide for wallets to detect force transfers. Applications can read the paused field of the token-standard instrument metadata endpoint to detect paused instruments; see Instrument Pause.

​

Wallet Providers

Wallets can show which holdings have force transfer enabled, and label force transfers in the transaction history. See the Force Transfer guide for wallets. Registrars can now pause instruments. The token-standard instrument metadata endpoint returns the current pause state in the paused field. Wallets can check it to show that an instrument is paused, and to disable actions on it. Transfers, allocations, mints, and burns of a paused instrument fail. Wallets can show the resulting errors to users; see the error messages in the Instrument Pause guide.