CIP-0112: Token Standard V2

Dear Community,

The CIP-0056 token standard just celebrated its first birthday and has become an integral part of the network in that time. I'd like to invite you all to share your experiences and insights gained in that time by participating in shaping an iteration that makes incremental but material improvements to the standard. 

CIP Text: CIP-0112: Token Standard V2

Abstract

This proposal outlines a set of improvements to the CIP-0056 Canton Network Token Standard. These enhancements make the token standard more suitable for integration with traditional trading and settlement venues, as well as on-chain securities that model holding and settlement via custody chains. They also include improvements to settlement efficiency at the protocol level as well as optimization to the funds that need to be allocated. A high level of backward compatibility with CIP-0056 means that the evolved standard will further foster interoperability between wallets, apps, and assets across crypto and traditional finance.

Process

Digital Asset will sponsor this CIP, but we are not asking for endorsement at this point. We propose at least a month of soak time for discussion and will attempt to take it to vote only once inputs from the community could be adequately addressed and there is sufficient alignment around the new standard.

The iteration is motivated by discussions we've been having with apps and assets trying to enter the network, especially in the RWA/TradFi space, as well as our own experience since the introduction of CIP-0056. The initial draft CIP text presented here proposes a scope of iteration that solves what we have so far identified as the most pressing matters.

We'd now like to get inputs from the community at large:

- Feedback on the value and validity of the improvements proposed

- Inputs on additional improvements that would move the needle for the network

- Feedback on the specific design decisions or indeed ideas for improvements to the proposed APIs and guidelines

To allow for practical validation, we are doing a large part of the implementation work as part of the CIP discussion phase. We have already spun up a dedicated "token standard v2 devnet". Any DevNet validator operator can join it following these instructions. Please take care to use dedicated throw-away nodes. Do not use your DevNet nodes. On this network and over the course of the month of April, Canton Coin will be fully upgraded to also support token standard v2, and we will add a Daml model for a token with privacy that makes use of the advanced features as well. 

Related Grant

There is a grant proposal related to this CIP which was accepted by Tech & Ops this week. 

Since this is the first time that we as a community work through a technical/standards CIP based on a foundation grant, I want to frame the relationship here. The grant does not represent a decision on the scope of the iteration, nor a decision to adopt the standard. Rather, it gives Digital Asset, the recipient of this grant, the mandate to do the necessary heavy lifting of gathering community inputs, making a design proposal, laying the groundwork for the community to validate that proposal, and to iterate on it until the community as a whole is aligned and the new standard can be ratified through the CIP process.

That process is kicking off with this email.

Kind regards,

Bernhard

--

Dr. Bernhard Elsner

Chief Product Officer / +41 76 696 70 50

Digital Asset, creators of Daml

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

CIP-0112 is now in the CIP repository in Draft state.

 

https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md

Dear Community,

Since originally posting this CIP draft, we received feedback and made some discoveries ourselves on the Token Standard DevNet and have been iterating based on that. The validation and iteration work can be tracked in the V2_Validation.md file. The below is largely a summary and expansion on its contents. The sections are increasingly more detailed as you go down, with all but the top-most sections targeted at those that are knees-deep in coding against the CIP-0112 draft standard.

As you can see there’s a lot going on, and I want to thank all those that engaged in validation and feedback so far. I would like to encourage everyone to provide feedback on this email thread or on the token standard devote Slack channel so it’s visible and available to the whole community.

Kind regards,

Bernhard

Functional extensions to the standard
These are proposed extensions to CIP-0112, which will get new top-level sections in the CIP-0112 text.

• We are proposing to add improved transaction history parsing to CIP-0112. There’s a PoC in the works here.
  The improvement introduces an EventLog interface, which emits standalone events as side-effect free non-consuming choices, similar to ERC-20 events.
  The rationale for this is this:
  CIP-0056 tx history parsing relies on events from the TransactionFactory and AllocationFactory interfaces with a fallback to metadata. Both have some shortcomings: Using the factory events means that observing the event means observing all consequences thereof. E.g. to show a receiver of a transfer the TransactionFactory_Transfer event, one would also have to show them the input holding pre-split. Using meta-data requires full transaction tree traversal on the client side rather than being able to rely on a list of filtered events.
  It has also been a challenge to get the cross-version-compatibility to work fully on the transaction history-parsing side. If the same factory-choice based approach was adopted in CIP-0112, and one wanted to emit both V1 and V2 events for a transfer, then the V1 choice has to call the V2 choice and vice versa. This circular dependency with the needed switching logic whether the choice is called directly or by the other version is not practical.

Functional Interface Improvements
These improvements are minor, but change the functionality of the proposed standard slightly. These will be reflected in the CIP-0112 text.

• Add an explicit AllocationRequest_Accept choice to provide a standard way for wallets to signal acceptance and provide replay protection for the creation of the corresponding allocations. Rather than apps, wallets will have the responsibility to remove AllocationRequest contracts from state. This means that apps should issue one AllocationRequest per trading party and can no longer save costs by emitting one AllocationRequest for all trading parties as was possible in CIP-0056.
• (Planned) The way CIP-0112 proposes to authorize V1 Allocations within a V2 SettleBatch call via extra extraSettlementAuthorizers (discovered from extraReceiptAuthorizers) has proven to not work as intended. Firstly, the complexity introduced is high, but more importantly, the privacy implications were that all traders of a V1 allocation end up seeing the entire V2 batch settlement, defeating a big art of the purpose of CIP-0112. Instead, V2 apps now need to create the receipt Allocations outside the settlement. This is demonstrated in the V2 trading app on the PR for this change.

Open Discussions

• We got feedback suggesting we change the type of `availableActions : Map.Map [Party] [SomeAction]` to `availableActions : Map.Map SomeAction [Party]` as Inverting the lookup direction has proven to be simpler in implementations.
• We (DA) agree, but propose to use type `Map AllocationAction [[Party]]` where the values represent disjunctive normal form. E.g. an entry `(TIA_Accept, [[Alice], [Bob], [Alice, Bob]])` indicates, that either Alice alone, Bob alone, or Alice and Bob jointly can call the Accept choice. Likely this would indicate that if Alice or Bob alone call it, the other party would afterward have to call it as well.
• The original proposers of the improvement have countered with a typed approach consisting of `type ActionsMap = Map.Map AllocationRequestAction SigType` where `data SigType = AnySig [Party] | MultiSig [Party] | FlexiSig [SigType]`, where the equivalent to the above would just be `MultiSig [Alice, Bob]`. The argument is that for many common cases, readability and expression complexity are lower. 
• We’d love to hear from the community whether there are any opinions on one versus the other. DA’s position on the above is that the disjunctive normal form strikes a good balance of expressivity and complexity and has the great advantage that authorization checks (Can Alice call this choice?) are simple list element checks (`elem alice availableActions`). 

Minor Interface improvements
These are changes to the interfaces that don’t change functionality, but improve the interfaces in style or futureproofness. These will not be mentioned in the CIP-0112 text unless directly impacting shown code sections.

• Replace ChoiceExecutionMetadata with concrete result types for AllocationRequest_Reject and AllocationRequest_Withdraw choices to prepare for an eventual future where interface definitions may be upgraded
• Use authorizerHoldingCids instead of senderHoldingCids in all V2 choice results that return holdings of the allocation authorizer. This is a pure naming change to consolidate terminology around “authoriser” in stead of “sender” for allocations.
• Reordered the HoldingV2.Account fields to put owner first for improved readability of debug output
• Return "holding change" as TextMap [ContractId Holding] where the keys are instrumentId.ids, so that callers can identify the holdings for a specific instrument without needing to fetch the holding.
• Improve commentary on V2.AllocationRequest choices
• Add choice observers to V2.TransferFactory_Transfer. This allows adding informs to the V2.TransferFactory_Transfer event, which can be used to save cost/traffic in some cases.
• Renamed _extraObserverDefaultImpl to _extraObserversDefaultImpl to reflect that it can return multiple observers
• Use Account.id : Text instead of Optional Text to ensure that wallets do not have to deal with two different kinds of default accounts (empty string vs None). Use "" as the default account identifier.

Improvements to Splice/Utility Functions/Sample Token(s)

These are improvements to the code-base beyond the token standard interfaces. These will not be reflected in the CIP-01112 text.

•  Add a new Splice.Util.TokenWallet.BatchingUtilityV2 template with choices that implement the standard logic for accepting V1 and V2 requests in a V2 wallet. This template can be used by wallets to create transfers to multiple counterparties in a view- and cost optimised way, or to accept/reject/withdraw offers in bulk.
• Test tokens for V1 and V2 are in the works here. The V2 token in particular is not yet finished, but should be done over the next two weeks.
• Replace buggy netAllocationCreditAmount with netAllocationCreditAmounts that properly distinguishes between legs of different instruments, and a map of credit amounts by instrument id.
• Export 'require' and 'isGreaterOrEqualR' and its variants from Splice.TokenStandard.Utils to simplify writing validation code in choice bodies.
• Extend token standard test infrastructure:
• Add TestTokenV1 to simulate settlement involving V1-only tokens
• Add TestTokenV2 to simulate settlement involving tokens with support for accountable holdings and multiple instruments maintained by the same admin
• Add MultiRegistry to simulate the off-ledger APIs of multiple registries in a single test environment
• Extend TradingAppV2 to support mixed version settlement of trades involving V1-only tokens, and V1/V2 tokens whose allocations are created through either a V1 wallet or a V2 wallet
• Remove redundant Splice.Testing.UtilsV2 module: use Splice.Testing.Utils instead
• Add utility functions to create metadata for V1 transaction history parsing to Splice.TokenStandard.Utils
• (Planned) Move TradingAppV2 into its own package to enable reuse in integration tests.
• (Planned) Merge splice-token-standard-test-v1 and splice-token-standard-test-v2 into a single test package, with separate modules for V1 and V2 tests.

On Thu, Apr 9, 2026 at 9:06 PM Wayne Collier via lists.sync.global <wayne.collier=digitalasset.com@...> wrote:

CIP-0112 is now in the CIP repository in Draft state.

 

https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md

--

Dr. Bernhard Elsner

Chief Product Officer / +41 76 696 70 50

Digital Asset, creators of Daml

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Hi all,

Time for another update on Token Standard V2 developments.

Since the last update, we’ve further evaluated the initial designs and worked with participants on further enhancements that I wanted to share. Discussions have shifted from the originally proposed scope to a whole range of further enhancements that have also led to us not yet having put the CIP up for vote at the end of April as originally intended. But with the test token and amulet now fully integrating the enhancements, we are sufficiently confident that the interfaces deliver what they promise. Over the coming week, we expect to finalize the CIP text and then ask for it to be taken to a vote. So if you still have feedback in the pipe, please share it asap so we can work with you to incorporate it.

Kind regards,

Bernhard

Closing out the Open Discussion from the last update

We will change the type of availableActions to availableActions : Map.Map SomeAction [[Party]]. This seems to work well for implementing the TestTokenV2 with highly flexible authorization models.

Functional extensions to the standard
These are proposed extensions to CIP-0112, which will get new top-level sections in the CIP-0112 text.

• The Token Standard V2 Transaction History Parsing API discussed in the last update has been iterated on to allow event based reporting of all holdings changes and transfers.

• This simplifies parsing for wallets: just look for `EventLog_HoldingsChange` events to understand all changes to the holdings of an account

• #4638 adds the new APIs. More details in the changelog.

• All interfaces are in a new API package `splice-api-token-transfer-events-v2`

• This API is fully implemented for Amulet/Canton Coin.

• Open and Committed Allocations for Prefunded Trading and Iterated Settlement

• One of the inputs we got from multiple sides is around locking and allowing for pre-funded trading. V1 Allocations as well as the initially specified V2 allocations always give the sender the ability to withdraw, and always specify the exact transfer legs that will be executed. This was designed for settlement of executed trades. Yet several venues have emerged on Canton Network that do or want to do pre-funded trading. In the prefunded model, the owner needs to be able to give the venue the ability to specify the transfer legs later and must forego the ability to withdraw the allocation for a duration to avoid settlement failures.

• #5333 adds API extensions that allow for open and committed allocations. Full details in the changelogs.

• It introduces committed allocations that lock the funds until settlement time.

• `RequestedAllocation.committed` lets an app request creation of a committed allocation.

• `AllocationSpecification.committed` records that commitment on the created allocation.

• if `committed = True`, the authorizer cannot withdraw the allocation before the settlement deadline; if there is no settlement deadline, the authorizer cannot withdraw it at all. The allocation must instead be concluded by settlement, cancellation, or registry-specific expiry.

• Allocations can now hold extra funding that can be used in yet to be specified transfer legs.

• This is specified in a new field `nextIterationFunding : Optional (TextMap.TextMap Decimal)` that maps from instrumentId to amount.

• When set, “iterated settlement” is enabled on the allocation.

• The type of `allocations` on SettlementFactory_SettleBatch has been changed to allow the executor to pass in extra transfer legs and new values of nextIterationFunding per input allocation.

• Prefunded trading now works as follows, e.g. for CC/FooCoin trading:

• User creates a committed allocation with executor “dex” with 100 CC in nextIterationFunding, and no legs specified.

• User creates a committed allocation with executor “dex” with 0 FooCoin and an emptyMap in nextIterationFunding.

• User trades 30CC for 10 FooCoin.

• dex settles by atomically calling SettlementFactory_SettleBatch on both tokens, specifying the two legs, and iteratedSettlementFunding of 70 CC and 10 FooCoin respectively.

• The result is new committed allocations with 70 CC / 10 FooCoin. The user can trade again.

• Iterated settlement requires disambiguating whether a self-transfer is incoming or outgoing. Therefore AllocationSpecification now doesn’t store a list of TransferLegs, but a list of TransferLegSides, that state whether the Allocation is on the SenderSide or ReceiverSide of the transfer.

• This allows merging of committed Allocations by adding self-transfers on both sides, one on the SenderSide and one on the ReceiverSide.

• The primary use case is to top up the deposit for prefunded trading.

• As committed state and iterated settlement apply per Allocation, there may now be cases where a venue wants to request multiple allocations for the same admin party from a single trader. To allow this, AllocationRequest has been structured to allow requesting a list of Allocations rather than just a list of TransferLegs.

• Use of ownerless Accounts to represent special operations like Burns/Mints.

• The owner field on Account is now optional.

• Special accounts are represented by `Account.owner = None`. These are intended to be used by registries to report burns and mints as transfers. For example:

• Registries can use them to allow allocations to encapsulate a burn or mint action, allowing “Delivery vs Mint” or “Delivery vs Burn” settlements.

• Or they could use them to enable trade settlement without disclosing the identity of the settlement counterparties.

• #5515 makes the API changes and demonstrates use on the TestToken.

• Better support for pausing instruments

• A global “pause” function is fairly universal in RWAs, but is currently not detectable through the token standard other than via attempted but failed transfers.

• The token metadata API was extended to expose a `paused` flag and optional `pauseInfo`, allowing wallets and other clients to detect when an instrument is paused and why.

• This was done as a backwards-compatible change to `token-metadata-v1.yaml` to allow both V1 and V2 clients to benefit from this information without needing to upgrade to a new version of the metadata API.

• See #5405 for the API changes.

Functional Interface Improvements
These improvements are minor, but change the functionality of the proposed standard slightly. These will be reflected in the CIP-0112 text.

• Remove the need for extra actors to settle V1 allocations.

• Drop the need for `extraSettlementAuthorizers` and `extraReceiptAuthorizers` to use allocations created using `V1.AllocationFactory_Allocate` in a V2 settlement.

• Motivation: the extra actors on `SettlementFactory_SettleBatch` made it impossible to use V1 allocation with privacy, which was discovered by app providers attempting to implement the compatibility mode.

• Key changes: 

• The `V2.Allocation_Settle` choice always only requires authorization from the `executors` and the instrument `admin`. Apps can thus call `V2.SettlementFactory_SettleBatch` using `executors` authority only.

• Apps need to create missing receipt allocations using their own delegation contracts from their traders. See the `TradingAppV2` implementation for an example of how to do this. Also note these of `Splice.TokenStandard.Utils.ensureIsReceiptAllocation` to check that the allocation factory call delegation is for a receipt allocation only.

• Asset owners must be aware that allocations created using `V1.AllocationFactory_Allocate` can be settled with only `executor` authority. They must only create allocations for `executors` that they trust to atomically settle trades involving their allocations.

• Introduce `AllocationRequest.originalRequestId` and `Allocation.originalAllocationId` fields, which can be used to track the same request or allocation across state updates, analogously to the `originalInstructionCid` of transfer and allocation instructions.

• Enhancements resulting from validation of account authorization in TestTokenV2

• We added support for managing jointly controlled accounts via a token standard wallet in the reference token implementation to show the power and flexibility of the new Account type and authorization model.

• The general approach is that the other party across owner and provider must use the same action to confirm their agreement to an action. The state of pending actions is tracked  in the `TransferInstruction`, `AllocationInstruction`, or `Allocation` contracts.

• This generalizes `TransferInstruction_Accept` from just the receiver to be used for anyone that needs to authorize it; e.g., the account provider of the sender might use this choice to confirm that they agree to the transfer being offered to the recipient.

• To allow this uniformly, we added a `AllocationInstruction_Accept` choice to confirm the creation of an allocation as well. 

• To also allow uniformity on the return types, we introduced a uniform `AllocationResult` for `Allocation` choices in line with the *InstructionResult types.

Minor Interface improvements
These are changes to the interfaces that don’t change functionality, but improve the interfaces in style or futureproofness. These will not be mentioned in the CIP-0112 text unless directly impacting shown code sections.

• Use `Account.id : Text` instead of `Optional Text` to ensure that wallets do not have to deal with  two different kinds of default accounts (empty string vs None). Use "" as the default account identifier.

• Improve commentary on `AllocationRequest_Accept` to call out that there is no guarantee that wallets call the choice, and thus apps must clean up allocation requests independently

• Add an `expiresAt` field to transfer instruction and allocation instruction, so that registries can report and enforce a TTL for instructions that is shorter than the `executeBefore` or the `settlementDeadline` of the underlying transfer or allocation. Registries are expected to bump that TTL on updates to the instruction, so that only long times of inactivity lead to expiry. This extra field allows for standardized garbage collection and avoids hard to remove state leakage for registries.

• Remove the `description` and `meta` fields from the `_Custom` actions, as they bloat the representation and can be delivered out of band (or in the view's overall metadata) by the registry if needed.

Improvements to Splice/Utility Functions/Sample Token(s)

These are improvements to the code-base beyond the token standard interfaces. These will not be reflected in the CIP-0112 text.

• Change default implementation of `SettlementFactory_SettleBatch` to check uniqueness of transfer leg ids to provide better safety guarantees for code that identifies legs by their ids

• add default implementations for extra observers for `SettlementFactory_SettleBatch`  for public and private assets

• Consistently use *-v2-1.0.0 for token standard v2 packages

• Change version numbers of `splice-api-token-*-v2` packages to `1.0.0` to be consistent with the existing `splice-api-featured-app-v2` package, which also has version `1.0.0`

On Mon, Apr 20, 2026 at 1:57 PM Bernhard Elsner via lists.sync.global <bernhard.elsner=digitalasset.com@...> wrote:

Dear Community,

Since originally posting this CIP draft, we received feedback and made some discoveries ourselves on the Token Standard DevNet and have been iterating based on that. The validation and iteration work can be tracked in the V2_Validation.md file. The below is largely a summary and expansion on its contents. The sections are increasingly more detailed as you go down, with all but the top-most sections targeted at those that are knees-deep in coding against the CIP-0112 draft standard.

As you can see there’s a lot going on, and I want to thank all those that engaged in validation and feedback so far. I would like to encourage everyone to provide feedback on this email thread or on the token standard devote Slack channel so it’s visible and available to the whole community.

Kind regards,

Bernhard

Functional extensions to the standard
These are proposed extensions to CIP-0112, which will get new top-level sections in the CIP-0112 text.

• We are proposing to add improved transaction history parsing to CIP-0112. There’s a PoC in the works here.
  The improvement introduces an EventLog interface, which emits standalone events as side-effect free non-consuming choices, similar to ERC-20 events.
  The rationale for this is this:
  CIP-0056 tx history parsing relies on events from the TransactionFactory and AllocationFactory interfaces with a fallback to metadata. Both have some shortcomings: Using the factory events means that observing the event means observing all consequences thereof. E.g. to show a receiver of a transfer the TransactionFactory_Transfer event, one would also have to show them the input holding pre-split. Using meta-data requires full transaction tree traversal on the client side rather than being able to rely on a list of filtered events.
  It has also been a challenge to get the cross-version-compatibility to work fully on the transaction history-parsing side. If the same factory-choice based approach was adopted in CIP-0112, and one wanted to emit both V1 and V2 events for a transfer, then the V1 choice has to call the V2 choice and vice versa. This circular dependency with the needed switching logic whether the choice is called directly or by the other version is not practical.

Functional Interface Improvements
These improvements are minor, but change the functionality of the proposed standard slightly. These will be reflected in the CIP-0112 text.

• Add an explicit AllocationRequest_Accept choice to provide a standard way for wallets to signal acceptance and provide replay protection for the creation of the corresponding allocations. Rather than apps, wallets will have the responsibility to remove AllocationRequest contracts from state. This means that apps should issue one AllocationRequest per trading party and can no longer save costs by emitting one AllocationRequest for all trading parties as was possible in CIP-0056.
• (Planned) The way CIP-0112 proposes to authorize V1 Allocations within a V2 SettleBatch call via extra extraSettlementAuthorizers (discovered from extraReceiptAuthorizers) has proven to not work as intended. Firstly, the complexity introduced is high, but more importantly, the privacy implications were that all traders of a V1 allocation end up seeing the entire V2 batch settlement, defeating a big art of the purpose of CIP-0112. Instead, V2 apps now need to create the receipt Allocations outside the settlement. This is demonstrated in the V2 trading app on the PR for this change.

Open Discussions

• We got feedback suggesting we change the type of `availableActions : Map.Map [Party] [SomeAction]` to `availableActions : Map.Map SomeAction [Party]` as Inverting the lookup direction has proven to be simpler in implementations.
• We (DA) agree, but propose to use type `Map AllocationAction [[Party]]` where the values represent disjunctive normal form. E.g. an entry `(TIA_Accept, [[Alice], [Bob], [Alice, Bob]])` indicates, that either Alice alone, Bob alone, or Alice and Bob jointly can call the Accept choice. Likely this would indicate that if Alice or Bob alone call it, the other party would afterward have to call it as well.
• The original proposers of the improvement have countered with a typed approach consisting of `type ActionsMap = Map.Map AllocationRequestAction SigType` where `data SigType = AnySig [Party] | MultiSig [Party] | FlexiSig [SigType]`, where the equivalent to the above would just be `MultiSig [Alice, Bob]`. The argument is that for many common cases, readability and expression complexity are lower. 
• We’d love to hear from the community whether there are any opinions on one versus the other. DA’s position on the above is that the disjunctive normal form strikes a good balance of expressivity and complexity and has the great advantage that authorization checks (Can Alice call this choice?) are simple list element checks (`elem alice availableActions`). 

Minor Interface improvements
These are changes to the interfaces that don’t change functionality, but improve the interfaces in style or futureproofness. These will not be mentioned in the CIP-0112 text unless directly impacting shown code sections.

• Replace ChoiceExecutionMetadata with concrete result types for AllocationRequest_Reject and AllocationRequest_Withdraw choices to prepare for an eventual future where interface definitions may be upgraded
• Use authorizerHoldingCids instead of senderHoldingCids in all V2 choice results that return holdings of the allocation authorizer. This is a pure naming change to consolidate terminology around “authoriser” in stead of “sender” for allocations.
• Reordered the HoldingV2.Account fields to put owner first for improved readability of debug output
• Return "holding change" as TextMap [ContractId Holding] where the keys are instrumentId.ids, so that callers can identify the holdings for a specific instrument without needing to fetch the holding.
• Improve commentary on V2.AllocationRequest choices
• Add choice observers to V2.TransferFactory_Transfer. This allows adding informs to the V2.TransferFactory_Transfer event, which can be used to save cost/traffic in some cases.
• Renamed _extraObserverDefaultImpl to _extraObserversDefaultImpl to reflect that it can return multiple observers
• Use Account.id : Text instead of Optional Text to ensure that wallets do not have to deal with two different kinds of default accounts (empty string vs None). Use "" as the default account identifier.

Improvements to Splice/Utility Functions/Sample Token(s)

These are improvements to the code-base beyond the token standard interfaces. These will not be reflected in the CIP-01112 text.

•  Add a new Splice.Util.TokenWallet.BatchingUtilityV2 template with choices that implement the standard logic for accepting V1 and V2 requests in a V2 wallet. This template can be used by wallets to create transfers to multiple counterparties in a view- and cost optimised way, or to accept/reject/withdraw offers in bulk.
• Test tokens for V1 and V2 are in the works here. The V2 token in particular is not yet finished, but should be done over the next two weeks.
• Replace buggy netAllocationCreditAmount with netAllocationCreditAmounts that properly distinguishes between legs of different instruments, and a map of credit amounts by instrument id.
• Export 'require' and 'isGreaterOrEqualR' and its variants from Splice.TokenStandard.Utils to simplify writing validation code in choice bodies.
• Extend token standard test infrastructure:
• Add TestTokenV1 to simulate settlement involving V1-only tokens
• Add TestTokenV2 to simulate settlement involving tokens with support for accountable holdings and multiple instruments maintained by the same admin
• Add MultiRegistry to simulate the off-ledger APIs of multiple registries in a single test environment
• Extend TradingAppV2 to support mixed version settlement of trades involving V1-only tokens, and V1/V2 tokens whose allocations are created through either a V1 wallet or a V2 wallet
• Remove redundant Splice.Testing.UtilsV2 module: use Splice.Testing.Utils instead
• Add utility functions to create metadata for V1 transaction history parsing to Splice.TokenStandard.Utils
• (Planned) Move TradingAppV2 into its own package to enable reuse in integration tests.
• (Planned) Merge splice-token-standard-test-v1 and splice-token-standard-test-v2 into a single test package, with separate modules for V1 and V2 tests.

On Thu, Apr 9, 2026 at 9:06 PM Wayne Collier via lists.sync.global <wayne.collier=digitalasset.com@...> wrote:

CIP-0112 is now in the CIP repository in Draft state.

 

https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md

--

Dr. Bernhard Elsner

Chief Product Officer / +41 76 696 70 50

Digital Asset, creators of Daml

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

--

Dr. Bernhard Elsner

Chief Product Officer / +41 76 696 70 50

Digital Asset, creators of Daml

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Note that the last four changes are still being merged into the main token standard branch. You can find the corresponding PRs using this query: https://github.com/canton-network/splice/pulls?q=is%3Aopen+is%3Apr+author%3Ameiersi-da+label%3Adaml-api

Once these PRs have been merged in the coming days, all of the changes explained by Bernhard can be found on the main integration branch: https://github.com/canton-network/splice/tree/token-standard-v2-upcoming 

And they should land on TokenStdDevNet next week.

On Thu, May 14, 2026 at 3:53 PM Bernhard Elsner via lists.sync.global <bernhard.elsner=digitalasset.com@...> wrote:

Hi all,

Time for another update on Token Standard V2 developments.

Since the last update, we’ve further evaluated the initial designs and worked with participants on further enhancements that I wanted to share. Discussions have shifted from the originally proposed scope to a whole range of further enhancements that have also led to us not yet having put the CIP up for vote at the end of April as originally intended. But with the test token and amulet now fully integrating the enhancements, we are sufficiently confident that the interfaces deliver what they promise. Over the coming week, we expect to finalize the CIP text and then ask for it to be taken to a vote. So if you still have feedback in the pipe, please share it asap so we can work with you to incorporate it.

Kind regards,

Bernhard

Closing out the Open Discussion from the last update

We will change the type of availableActions to availableActions : Map.Map SomeAction [[Party]]. This seems to work well for implementing the TestTokenV2 with highly flexible authorization models.

Functional extensions to the standard
These are proposed extensions to CIP-0112, which will get new top-level sections in the CIP-0112 text.

• The Token Standard V2 Transaction History Parsing API discussed in the last update has been iterated on to allow event based reporting of all holdings changes and transfers.

• This simplifies parsing for wallets: just look for `EventLog_HoldingsChange` events to understand all changes to the holdings of an account

• #4638 adds the new APIs. More details in the changelog.

• All interfaces are in a new API package `splice-api-token-transfer-events-v2`

• This API is fully implemented for Amulet/Canton Coin.

• Open and Committed Allocations for Prefunded Trading and Iterated Settlement

• One of the inputs we got from multiple sides is around locking and allowing for pre-funded trading. V1 Allocations as well as the initially specified V2 allocations always give the sender the ability to withdraw, and always specify the exact transfer legs that will be executed. This was designed for settlement of executed trades. Yet several venues have emerged on Canton Network that do or want to do pre-funded trading. In the prefunded model, the owner needs to be able to give the venue the ability to specify the transfer legs later and must forego the ability to withdraw the allocation for a duration to avoid settlement failures.

• #5333 adds API extensions that allow for open and committed allocations. Full details in the changelogs.

• It introduces committed allocations that lock the funds until settlement time.

• `RequestedAllocation.committed` lets an app request creation of a committed allocation.

• `AllocationSpecification.committed` records that commitment on the created allocation.

• if `committed = True`, the authorizer cannot withdraw the allocation before the settlement deadline; if there is no settlement deadline, the authorizer cannot withdraw it at all. The allocation must instead be concluded by settlement, cancellation, or registry-specific expiry.

• Allocations can now hold extra funding that can be used in yet to be specified transfer legs.

• This is specified in a new field `nextIterationFunding : Optional (TextMap.TextMap Decimal)` that maps from instrumentId to amount.

• When set, “iterated settlement” is enabled on the allocation.

• The type of `allocations` on SettlementFactory_SettleBatch has been changed to allow the executor to pass in extra transfer legs and new values of nextIterationFunding per input allocation.

• Prefunded trading now works as follows, e.g. for CC/FooCoin trading:

• User creates a committed allocation with executor “dex” with 100 CC in nextIterationFunding, and no legs specified.

• User creates a committed allocation with executor “dex” with 0 FooCoin and an emptyMap in nextIterationFunding.

• User trades 30CC for 10 FooCoin.

• dex settles by atomically calling SettlementFactory_SettleBatch on both tokens, specifying the two legs, and iteratedSettlementFunding of 70 CC and 10 FooCoin respectively.

• The result is new committed allocations with 70 CC / 10 FooCoin. The user can trade again.

• Iterated settlement requires disambiguating whether a self-transfer is incoming or outgoing. Therefore AllocationSpecification now doesn’t store a list of TransferLegs, but a list of TransferLegSides, that state whether the Allocation is on the SenderSide or ReceiverSide of the transfer.

• This allows merging of committed Allocations by adding self-transfers on both sides, one on the SenderSide and one on the ReceiverSide.

• The primary use case is to top up the deposit for prefunded trading.

• As committed state and iterated settlement apply per Allocation, there may now be cases where a venue wants to request multiple allocations for the same admin party from a single trader. To allow this, AllocationRequest has been structured to allow requesting a list of Allocations rather than just a list of TransferLegs.

• Use of ownerless Accounts to represent special operations like Burns/Mints.

• The owner field on Account is now optional.

• Special accounts are represented by `Account.owner = None`. These are intended to be used by registries to report burns and mints as transfers. For example:

• Registries can use them to allow allocations to encapsulate a burn or mint action, allowing “Delivery vs Mint” or “Delivery vs Burn” settlements.

• Or they could use them to enable trade settlement without disclosing the identity of the settlement counterparties.

• #5515 makes the API changes and demonstrates use on the TestToken.

• Better support for pausing instruments

• A global “pause” function is fairly universal in RWAs, but is currently not detectable through the token standard other than via attempted but failed transfers.

• The token metadata API was extended to expose a `paused` flag and optional `pauseInfo`, allowing wallets and other clients to detect when an instrument is paused and why.

• This was done as a backwards-compatible change to `token-metadata-v1.yaml` to allow both V1 and V2 clients to benefit from this information without needing to upgrade to a new version of the metadata API.

• See #5405 for the API changes.

Functional Interface Improvements
These improvements are minor, but change the functionality of the proposed standard slightly. These will be reflected in the CIP-0112 text.

• Remove the need for extra actors to settle V1 allocations.

• Drop the need for `extraSettlementAuthorizers` and `extraReceiptAuthorizers` to use allocations created using `V1.AllocationFactory_Allocate` in a V2 settlement.

• Motivation: the extra actors on `SettlementFactory_SettleBatch` made it impossible to use V1 allocation with privacy, which was discovered by app providers attempting to implement the compatibility mode.

• Key changes: 

• The `V2.Allocation_Settle` choice always only requires authorization from the `executors` and the instrument `admin`. Apps can thus call `V2.SettlementFactory_SettleBatch` using `executors` authority only.

• Apps need to create missing receipt allocations using their own delegation contracts from their traders. See the `TradingAppV2` implementation for an example of how to do this. Also note these of `Splice.TokenStandard.Utils.ensureIsReceiptAllocation` to check that the allocation factory call delegation is for a receipt allocation only.

• Asset owners must be aware that allocations created using `V1.AllocationFactory_Allocate` can be settled with only `executor` authority. They must only create allocations for `executors` that they trust to atomically settle trades involving their allocations.

• Introduce `AllocationRequest.originalRequestId` and `Allocation.originalAllocationId` fields, which can be used to track the same request or allocation across state updates, analogously to the `originalInstructionCid` of transfer and allocation instructions.

• Enhancements resulting from validation of account authorization in TestTokenV2

• We added support for managing jointly controlled accounts via a token standard wallet in the reference token implementation to show the power and flexibility of the new Account type and authorization model.

• The general approach is that the other party across owner and provider must use the same action to confirm their agreement to an action. The state of pending actions is tracked  in the `TransferInstruction`, `AllocationInstruction`, or `Allocation` contracts.

• This generalizes `TransferInstruction_Accept` from just the receiver to be used for anyone that needs to authorize it; e.g., the account provider of the sender might use this choice to confirm that they agree to the transfer being offered to the recipient.

• To allow this uniformly, we added a `AllocationInstruction_Accept` choice to confirm the creation of an allocation as well. 

• To also allow uniformity on the return types, we introduced a uniform `AllocationResult` for `Allocation` choices in line with the *InstructionResult types.

Minor Interface improvements
These are changes to the interfaces that don’t change functionality, but improve the interfaces in style or futureproofness. These will not be mentioned in the CIP-0112 text unless directly impacting shown code sections.

• Use `Account.id : Text` instead of `Optional Text` to ensure that wallets do not have to deal with  two different kinds of default accounts (empty string vs None). Use "" as the default account identifier.

• Improve commentary on `AllocationRequest_Accept` to call out that there is no guarantee that wallets call the choice, and thus apps must clean up allocation requests independently

• Add an `expiresAt` field to transfer instruction and allocation instruction, so that registries can report and enforce a TTL for instructions that is shorter than the `executeBefore` or the `settlementDeadline` of the underlying transfer or allocation. Registries are expected to bump that TTL on updates to the instruction, so that only long times of inactivity lead to expiry. This extra field allows for standardized garbage collection and avoids hard to remove state leakage for registries.

• Remove the `description` and `meta` fields from the `_Custom` actions, as they bloat the representation and can be delivered out of band (or in the view's overall metadata) by the registry if needed.

Improvements to Splice/Utility Functions/Sample Token(s)

These are improvements to the code-base beyond the token standard interfaces. These will not be reflected in the CIP-0112 text.

• Change default implementation of `SettlementFactory_SettleBatch` to check uniqueness of transfer leg ids to provide better safety guarantees for code that identifies legs by their ids

• add default implementations for extra observers for `SettlementFactory_SettleBatch`  for public and private assets

• Consistently use *-v2-1.0.0 for token standard v2 packages

• Change version numbers of `splice-api-token-*-v2` packages to `1.0.0` to be consistent with the existing `splice-api-featured-app-v2` package, which also has version `1.0.0`

On Mon, Apr 20, 2026 at 1:57 PM Bernhard Elsner via lists.sync.global <bernhard.elsner=digitalasset.com@...> wrote:

Dear Community,

Since originally posting this CIP draft, we received feedback and made some discoveries ourselves on the Token Standard DevNet and have been iterating based on that. The validation and iteration work can be tracked in the V2_Validation.md file. The below is largely a summary and expansion on its contents. The sections are increasingly more detailed as you go down, with all but the top-most sections targeted at those that are knees-deep in coding against the CIP-0112 draft standard.

As you can see there’s a lot going on, and I want to thank all those that engaged in validation and feedback so far. I would like to encourage everyone to provide feedback on this email thread or on the token standard devote Slack channel so it’s visible and available to the whole community.

Kind regards,

Bernhard

Functional extensions to the standard
These are proposed extensions to CIP-0112, which will get new top-level sections in the CIP-0112 text.

• We are proposing to add improved transaction history parsing to CIP-0112. There’s a PoC in the works here.
  The improvement introduces an EventLog interface, which emits standalone events as side-effect free non-consuming choices, similar to ERC-20 events.
  The rationale for this is this:
  CIP-0056 tx history parsing relies on events from the TransactionFactory and AllocationFactory interfaces with a fallback to metadata. Both have some shortcomings: Using the factory events means that observing the event means observing all consequences thereof. E.g. to show a receiver of a transfer the TransactionFactory_Transfer event, one would also have to show them the input holding pre-split. Using meta-data requires full transaction tree traversal on the client side rather than being able to rely on a list of filtered events.
  It has also been a challenge to get the cross-version-compatibility to work fully on the transaction history-parsing side. If the same factory-choice based approach was adopted in CIP-0112, and one wanted to emit both V1 and V2 events for a transfer, then the V1 choice has to call the V2 choice and vice versa. This circular dependency with the needed switching logic whether the choice is called directly or by the other version is not practical.

Functional Interface Improvements
These improvements are minor, but change the functionality of the proposed standard slightly. These will be reflected in the CIP-0112 text.

• Add an explicit AllocationRequest_Accept choice to provide a standard way for wallets to signal acceptance and provide replay protection for the creation of the corresponding allocations. Rather than apps, wallets will have the responsibility to remove AllocationRequest contracts from state. This means that apps should issue one AllocationRequest per trading party and can no longer save costs by emitting one AllocationRequest for all trading parties as was possible in CIP-0056.
• (Planned) The way CIP-0112 proposes to authorize V1 Allocations within a V2 SettleBatch call via extra extraSettlementAuthorizers (discovered from extraReceiptAuthorizers) has proven to not work as intended. Firstly, the complexity introduced is high, but more importantly, the privacy implications were that all traders of a V1 allocation end up seeing the entire V2 batch settlement, defeating a big art of the purpose of CIP-0112. Instead, V2 apps now need to create the receipt Allocations outside the settlement. This is demonstrated in the V2 trading app on the PR for this change.

Open Discussions

• We got feedback suggesting we change the type of `availableActions : Map.Map [Party] [SomeAction]` to `availableActions : Map.Map SomeAction [Party]` as Inverting the lookup direction has proven to be simpler in implementations.
• We (DA) agree, but propose to use type `Map AllocationAction [[Party]]` where the values represent disjunctive normal form. E.g. an entry `(TIA_Accept, [[Alice], [Bob], [Alice, Bob]])` indicates, that either Alice alone, Bob alone, or Alice and Bob jointly can call the Accept choice. Likely this would indicate that if Alice or Bob alone call it, the other party would afterward have to call it as well.
• The original proposers of the improvement have countered with a typed approach consisting of `type ActionsMap = Map.Map AllocationRequestAction SigType` where `data SigType = AnySig [Party] | MultiSig [Party] | FlexiSig [SigType]`, where the equivalent to the above would just be `MultiSig [Alice, Bob]`. The argument is that for many common cases, readability and expression complexity are lower. 
• We’d love to hear from the community whether there are any opinions on one versus the other. DA’s position on the above is that the disjunctive normal form strikes a good balance of expressivity and complexity and has the great advantage that authorization checks (Can Alice call this choice?) are simple list element checks (`elem alice availableActions`). 

Minor Interface improvements
These are changes to the interfaces that don’t change functionality, but improve the interfaces in style or futureproofness. These will not be mentioned in the CIP-0112 text unless directly impacting shown code sections.

• Replace ChoiceExecutionMetadata with concrete result types for AllocationRequest_Reject and AllocationRequest_Withdraw choices to prepare for an eventual future where interface definitions may be upgraded
• Use authorizerHoldingCids instead of senderHoldingCids in all V2 choice results that return holdings of the allocation authorizer. This is a pure naming change to consolidate terminology around “authoriser” in stead of “sender” for allocations.
• Reordered the HoldingV2.Account fields to put owner first for improved readability of debug output
• Return "holding change" as TextMap [ContractId Holding] where the keys are instrumentId.ids, so that callers can identify the holdings for a specific instrument without needing to fetch the holding.
• Improve commentary on V2.AllocationRequest choices
• Add choice observers to V2.TransferFactory_Transfer. This allows adding informs to the V2.TransferFactory_Transfer event, which can be used to save cost/traffic in some cases.
• Renamed _extraObserverDefaultImpl to _extraObserversDefaultImpl to reflect that it can return multiple observers
• Use Account.id : Text instead of Optional Text to ensure that wallets do not have to deal with two different kinds of default accounts (empty string vs None). Use "" as the default account identifier.

Improvements to Splice/Utility Functions/Sample Token(s)

These are improvements to the code-base beyond the token standard interfaces. These will not be reflected in the CIP-01112 text.

•  Add a new Splice.Util.TokenWallet.BatchingUtilityV2 template with choices that implement the standard logic for accepting V1 and V2 requests in a V2 wallet. This template can be used by wallets to create transfers to multiple counterparties in a view- and cost optimised way, or to accept/reject/withdraw offers in bulk.
• Test tokens for V1 and V2 are in the works here. The V2 token in particular is not yet finished, but should be done over the next two weeks.
• Replace buggy netAllocationCreditAmount with netAllocationCreditAmounts that properly distinguishes between legs of different instruments, and a map of credit amounts by instrument id.
• Export 'require' and 'isGreaterOrEqualR' and its variants from Splice.TokenStandard.Utils to simplify writing validation code in choice bodies.
• Extend token standard test infrastructure:
• Add TestTokenV1 to simulate settlement involving V1-only tokens
• Add TestTokenV2 to simulate settlement involving tokens with support for accountable holdings and multiple instruments maintained by the same admin
• Add MultiRegistry to simulate the off-ledger APIs of multiple registries in a single test environment
• Extend TradingAppV2 to support mixed version settlement of trades involving V1-only tokens, and V1/V2 tokens whose allocations are created through either a V1 wallet or a V2 wallet
• Remove redundant Splice.Testing.UtilsV2 module: use Splice.Testing.Utils instead
• Add utility functions to create metadata for V1 transaction history parsing to Splice.TokenStandard.Utils
• (Planned) Move TradingAppV2 into its own package to enable reuse in integration tests.
• (Planned) Merge splice-token-standard-test-v1 and splice-token-standard-test-v2 into a single test package, with separate modules for V1 and V2 tests.

On Thu, Apr 9, 2026 at 9:06 PM Wayne Collier via lists.sync.global <wayne.collier=digitalasset.com@...> wrote:

CIP-0112 is now in the CIP repository in Draft state.

 

https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md

--

Dr. Bernhard Elsner

Chief Product Officer / +41 76 696 70 50

Digital Asset, creators of Daml

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

--

Dr. Bernhard Elsner

Chief Product Officer / +41 76 696 70 50

Digital Asset, creators of Daml

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

--

 

	Dr. Simon Meier
	Principal Architect	simon@...
		Creators of Canton Network

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Update: all four PRs have now been merged and will be deployed on TokenStdDevNet next week.

On Thu, May 14, 2026 at 4:51 PM Simon Meier via lists.sync.global <simon=digitalasset.com@...> wrote:

Note that the last four changes are still being merged into the main token standard branch. You can find the corresponding PRs using this query: https://github.com/canton-network/splice/pulls?q=is%3Aopen+is%3Apr+author%3Ameiersi-da+label%3Adaml-api

Once these PRs have been merged in the coming days, all of the changes explained by Bernhard can be found on the main integration branch: https://github.com/canton-network/splice/tree/token-standard-v2-upcoming 

And they should land on TokenStdDevNet next week.

On Thu, May 14, 2026 at 3:53 PM Bernhard Elsner via lists.sync.global <bernhard.elsner=digitalasset.com@...> wrote:

Hi all,

Time for another update on Token Standard V2 developments.

Since the last update, we’ve further evaluated the initial designs and worked with participants on further enhancements that I wanted to share. Discussions have shifted from the originally proposed scope to a whole range of further enhancements that have also led to us not yet having put the CIP up for vote at the end of April as originally intended. But with the test token and amulet now fully integrating the enhancements, we are sufficiently confident that the interfaces deliver what they promise. Over the coming week, we expect to finalize the CIP text and then ask for it to be taken to a vote. So if you still have feedback in the pipe, please share it asap so we can work with you to incorporate it.

Kind regards,

Bernhard

Closing out the Open Discussion from the last update

We will change the type of availableActions to availableActions : Map.Map SomeAction [[Party]]. This seems to work well for implementing the TestTokenV2 with highly flexible authorization models.

Functional extensions to the standard
These are proposed extensions to CIP-0112, which will get new top-level sections in the CIP-0112 text.

• The Token Standard V2 Transaction History Parsing API discussed in the last update has been iterated on to allow event based reporting of all holdings changes and transfers.

• This simplifies parsing for wallets: just look for `EventLog_HoldingsChange` events to understand all changes to the holdings of an account

• #4638 adds the new APIs. More details in the changelog.

• All interfaces are in a new API package `splice-api-token-transfer-events-v2`

• This API is fully implemented for Amulet/Canton Coin.

• Open and Committed Allocations for Prefunded Trading and Iterated Settlement

• One of the inputs we got from multiple sides is around locking and allowing for pre-funded trading. V1 Allocations as well as the initially specified V2 allocations always give the sender the ability to withdraw, and always specify the exact transfer legs that will be executed. This was designed for settlement of executed trades. Yet several venues have emerged on Canton Network that do or want to do pre-funded trading. In the prefunded model, the owner needs to be able to give the venue the ability to specify the transfer legs later and must forego the ability to withdraw the allocation for a duration to avoid settlement failures.

• #5333 adds API extensions that allow for open and committed allocations. Full details in the changelogs.

• It introduces committed allocations that lock the funds until settlement time.

• `RequestedAllocation.committed` lets an app request creation of a committed allocation.

• `AllocationSpecification.committed` records that commitment on the created allocation.

• if `committed = True`, the authorizer cannot withdraw the allocation before the settlement deadline; if there is no settlement deadline, the authorizer cannot withdraw it at all. The allocation must instead be concluded by settlement, cancellation, or registry-specific expiry.

• Allocations can now hold extra funding that can be used in yet to be specified transfer legs.

• This is specified in a new field `nextIterationFunding : Optional (TextMap.TextMap Decimal)` that maps from instrumentId to amount.

• When set, “iterated settlement” is enabled on the allocation.

• The type of `allocations` on SettlementFactory_SettleBatch has been changed to allow the executor to pass in extra transfer legs and new values of nextIterationFunding per input allocation.

• Prefunded trading now works as follows, e.g. for CC/FooCoin trading:

• User creates a committed allocation with executor “dex” with 100 CC in nextIterationFunding, and no legs specified.

• User creates a committed allocation with executor “dex” with 0 FooCoin and an emptyMap in nextIterationFunding.

• User trades 30CC for 10 FooCoin.

• dex settles by atomically calling SettlementFactory_SettleBatch on both tokens, specifying the two legs, and iteratedSettlementFunding of 70 CC and 10 FooCoin respectively.

• The result is new committed allocations with 70 CC / 10 FooCoin. The user can trade again.

• Iterated settlement requires disambiguating whether a self-transfer is incoming or outgoing. Therefore AllocationSpecification now doesn’t store a list of TransferLegs, but a list of TransferLegSides, that state whether the Allocation is on the SenderSide or ReceiverSide of the transfer.

• This allows merging of committed Allocations by adding self-transfers on both sides, one on the SenderSide and one on the ReceiverSide.

• The primary use case is to top up the deposit for prefunded trading.

• As committed state and iterated settlement apply per Allocation, there may now be cases where a venue wants to request multiple allocations for the same admin party from a single trader. To allow this, AllocationRequest has been structured to allow requesting a list of Allocations rather than just a list of TransferLegs.

• Use of ownerless Accounts to represent special operations like Burns/Mints.

• The owner field on Account is now optional.

• Special accounts are represented by `Account.owner = None`. These are intended to be used by registries to report burns and mints as transfers. For example:

• Registries can use them to allow allocations to encapsulate a burn or mint action, allowing “Delivery vs Mint” or “Delivery vs Burn” settlements.

• Or they could use them to enable trade settlement without disclosing the identity of the settlement counterparties.

• #5515 makes the API changes and demonstrates use on the TestToken.

• Better support for pausing instruments

• A global “pause” function is fairly universal in RWAs, but is currently not detectable through the token standard other than via attempted but failed transfers.

• The token metadata API was extended to expose a `paused` flag and optional `pauseInfo`, allowing wallets and other clients to detect when an instrument is paused and why.

• This was done as a backwards-compatible change to `token-metadata-v1.yaml` to allow both V1 and V2 clients to benefit from this information without needing to upgrade to a new version of the metadata API.

• See #5405 for the API changes.

Functional Interface Improvements
These improvements are minor, but change the functionality of the proposed standard slightly. These will be reflected in the CIP-0112 text.

• Remove the need for extra actors to settle V1 allocations.

• Drop the need for `extraSettlementAuthorizers` and `extraReceiptAuthorizers` to use allocations created using `V1.AllocationFactory_Allocate` in a V2 settlement.

• Motivation: the extra actors on `SettlementFactory_SettleBatch` made it impossible to use V1 allocation with privacy, which was discovered by app providers attempting to implement the compatibility mode.

• Key changes: 

• The `V2.Allocation_Settle` choice always only requires authorization from the `executors` and the instrument `admin`. Apps can thus call `V2.SettlementFactory_SettleBatch` using `executors` authority only.

• Apps need to create missing receipt allocations using their own delegation contracts from their traders. See the `TradingAppV2` implementation for an example of how to do this. Also note these of `Splice.TokenStandard.Utils.ensureIsReceiptAllocation` to check that the allocation factory call delegation is for a receipt allocation only.

• Asset owners must be aware that allocations created using `V1.AllocationFactory_Allocate` can be settled with only `executor` authority. They must only create allocations for `executors` that they trust to atomically settle trades involving their allocations.

• Introduce `AllocationRequest.originalRequestId` and `Allocation.originalAllocationId` fields, which can be used to track the same request or allocation across state updates, analogously to the `originalInstructionCid` of transfer and allocation instructions.

• Enhancements resulting from validation of account authorization in TestTokenV2

• We added support for managing jointly controlled accounts via a token standard wallet in the reference token implementation to show the power and flexibility of the new Account type and authorization model.

• The general approach is that the other party across owner and provider must use the same action to confirm their agreement to an action. The state of pending actions is tracked  in the `TransferInstruction`, `AllocationInstruction`, or `Allocation` contracts.

• This generalizes `TransferInstruction_Accept` from just the receiver to be used for anyone that needs to authorize it; e.g., the account provider of the sender might use this choice to confirm that they agree to the transfer being offered to the recipient.

• To allow this uniformly, we added a `AllocationInstruction_Accept` choice to confirm the creation of an allocation as well. 

• To also allow uniformity on the return types, we introduced a uniform `AllocationResult` for `Allocation` choices in line with the *InstructionResult types.

Minor Interface improvements
These are changes to the interfaces that don’t change functionality, but improve the interfaces in style or futureproofness. These will not be mentioned in the CIP-0112 text unless directly impacting shown code sections.

• Use `Account.id : Text` instead of `Optional Text` to ensure that wallets do not have to deal with  two different kinds of default accounts (empty string vs None). Use "" as the default account identifier.

• Improve commentary on `AllocationRequest_Accept` to call out that there is no guarantee that wallets call the choice, and thus apps must clean up allocation requests independently

• Add an `expiresAt` field to transfer instruction and allocation instruction, so that registries can report and enforce a TTL for instructions that is shorter than the `executeBefore` or the `settlementDeadline` of the underlying transfer or allocation. Registries are expected to bump that TTL on updates to the instruction, so that only long times of inactivity lead to expiry. This extra field allows for standardized garbage collection and avoids hard to remove state leakage for registries.

• Remove the `description` and `meta` fields from the `_Custom` actions, as they bloat the representation and can be delivered out of band (or in the view's overall metadata) by the registry if needed.

Improvements to Splice/Utility Functions/Sample Token(s)

These are improvements to the code-base beyond the token standard interfaces. These will not be reflected in the CIP-0112 text.

• Change default implementation of `SettlementFactory_SettleBatch` to check uniqueness of transfer leg ids to provide better safety guarantees for code that identifies legs by their ids

• add default implementations for extra observers for `SettlementFactory_SettleBatch`  for public and private assets

• Consistently use *-v2-1.0.0 for token standard v2 packages

• Change version numbers of `splice-api-token-*-v2` packages to `1.0.0` to be consistent with the existing `splice-api-featured-app-v2` package, which also has version `1.0.0`

On Mon, Apr 20, 2026 at 1:57 PM Bernhard Elsner via lists.sync.global <bernhard.elsner=digitalasset.com@...> wrote:

Dear Community,

Since originally posting this CIP draft, we received feedback and made some discoveries ourselves on the Token Standard DevNet and have been iterating based on that. The validation and iteration work can be tracked in the V2_Validation.md file. The below is largely a summary and expansion on its contents. The sections are increasingly more detailed as you go down, with all but the top-most sections targeted at those that are knees-deep in coding against the CIP-0112 draft standard.

As you can see there’s a lot going on, and I want to thank all those that engaged in validation and feedback so far. I would like to encourage everyone to provide feedback on this email thread or on the token standard devote Slack channel so it’s visible and available to the whole community.

Kind regards,

Bernhard

Functional extensions to the standard
These are proposed extensions to CIP-0112, which will get new top-level sections in the CIP-0112 text.

• We are proposing to add improved transaction history parsing to CIP-0112. There’s a PoC in the works here.
  The improvement introduces an EventLog interface, which emits standalone events as side-effect free non-consuming choices, similar to ERC-20 events.
  The rationale for this is this:
  CIP-0056 tx history parsing relies on events from the TransactionFactory and AllocationFactory interfaces with a fallback to metadata. Both have some shortcomings: Using the factory events means that observing the event means observing all consequences thereof. E.g. to show a receiver of a transfer the TransactionFactory_Transfer event, one would also have to show them the input holding pre-split. Using meta-data requires full transaction tree traversal on the client side rather than being able to rely on a list of filtered events.
  It has also been a challenge to get the cross-version-compatibility to work fully on the transaction history-parsing side. If the same factory-choice based approach was adopted in CIP-0112, and one wanted to emit both V1 and V2 events for a transfer, then the V1 choice has to call the V2 choice and vice versa. This circular dependency with the needed switching logic whether the choice is called directly or by the other version is not practical.

Functional Interface Improvements
These improvements are minor, but change the functionality of the proposed standard slightly. These will be reflected in the CIP-0112 text.

• Add an explicit AllocationRequest_Accept choice to provide a standard way for wallets to signal acceptance and provide replay protection for the creation of the corresponding allocations. Rather than apps, wallets will have the responsibility to remove AllocationRequest contracts from state. This means that apps should issue one AllocationRequest per trading party and can no longer save costs by emitting one AllocationRequest for all trading parties as was possible in CIP-0056.
• (Planned) The way CIP-0112 proposes to authorize V1 Allocations within a V2 SettleBatch call via extra extraSettlementAuthorizers (discovered from extraReceiptAuthorizers) has proven to not work as intended. Firstly, the complexity introduced is high, but more importantly, the privacy implications were that all traders of a V1 allocation end up seeing the entire V2 batch settlement, defeating a big art of the purpose of CIP-0112. Instead, V2 apps now need to create the receipt Allocations outside the settlement. This is demonstrated in the V2 trading app on the PR for this change.

Open Discussions

• We got feedback suggesting we change the type of `availableActions : Map.Map [Party] [SomeAction]` to `availableActions : Map.Map SomeAction [Party]` as Inverting the lookup direction has proven to be simpler in implementations.
• We (DA) agree, but propose to use type `Map AllocationAction [[Party]]` where the values represent disjunctive normal form. E.g. an entry `(TIA_Accept, [[Alice], [Bob], [Alice, Bob]])` indicates, that either Alice alone, Bob alone, or Alice and Bob jointly can call the Accept choice. Likely this would indicate that if Alice or Bob alone call it, the other party would afterward have to call it as well.
• The original proposers of the improvement have countered with a typed approach consisting of `type ActionsMap = Map.Map AllocationRequestAction SigType` where `data SigType = AnySig [Party] | MultiSig [Party] | FlexiSig [SigType]`, where the equivalent to the above would just be `MultiSig [Alice, Bob]`. The argument is that for many common cases, readability and expression complexity are lower. 
• We’d love to hear from the community whether there are any opinions on one versus the other. DA’s position on the above is that the disjunctive normal form strikes a good balance of expressivity and complexity and has the great advantage that authorization checks (Can Alice call this choice?) are simple list element checks (`elem alice availableActions`). 

Minor Interface improvements
These are changes to the interfaces that don’t change functionality, but improve the interfaces in style or futureproofness. These will not be mentioned in the CIP-0112 text unless directly impacting shown code sections.

• Replace ChoiceExecutionMetadata with concrete result types for AllocationRequest_Reject and AllocationRequest_Withdraw choices to prepare for an eventual future where interface definitions may be upgraded
• Use authorizerHoldingCids instead of senderHoldingCids in all V2 choice results that return holdings of the allocation authorizer. This is a pure naming change to consolidate terminology around “authoriser” in stead of “sender” for allocations.
• Reordered the HoldingV2.Account fields to put owner first for improved readability of debug output
• Return "holding change" as TextMap [ContractId Holding] where the keys are instrumentId.ids, so that callers can identify the holdings for a specific instrument without needing to fetch the holding.
• Improve commentary on V2.AllocationRequest choices
• Add choice observers to V2.TransferFactory_Transfer. This allows adding informs to the V2.TransferFactory_Transfer event, which can be used to save cost/traffic in some cases.
• Renamed _extraObserverDefaultImpl to _extraObserversDefaultImpl to reflect that it can return multiple observers
• Use Account.id : Text instead of Optional Text to ensure that wallets do not have to deal with two different kinds of default accounts (empty string vs None). Use "" as the default account identifier.

Improvements to Splice/Utility Functions/Sample Token(s)

These are improvements to the code-base beyond the token standard interfaces. These will not be reflected in the CIP-01112 text.

•  Add a new Splice.Util.TokenWallet.BatchingUtilityV2 template with choices that implement the standard logic for accepting V1 and V2 requests in a V2 wallet. This template can be used by wallets to create transfers to multiple counterparties in a view- and cost optimised way, or to accept/reject/withdraw offers in bulk.
• Test tokens for V1 and V2 are in the works here. The V2 token in particular is not yet finished, but should be done over the next two weeks.
• Replace buggy netAllocationCreditAmount with netAllocationCreditAmounts that properly distinguishes between legs of different instruments, and a map of credit amounts by instrument id.
• Export 'require' and 'isGreaterOrEqualR' and its variants from Splice.TokenStandard.Utils to simplify writing validation code in choice bodies.
• Extend token standard test infrastructure:
• Add TestTokenV1 to simulate settlement involving V1-only tokens
• Add TestTokenV2 to simulate settlement involving tokens with support for accountable holdings and multiple instruments maintained by the same admin
• Add MultiRegistry to simulate the off-ledger APIs of multiple registries in a single test environment
• Extend TradingAppV2 to support mixed version settlement of trades involving V1-only tokens, and V1/V2 tokens whose allocations are created through either a V1 wallet or a V2 wallet
• Remove redundant Splice.Testing.UtilsV2 module: use Splice.Testing.Utils instead
• Add utility functions to create metadata for V1 transaction history parsing to Splice.TokenStandard.Utils
• (Planned) Move TradingAppV2 into its own package to enable reuse in integration tests.
• (Planned) Merge splice-token-standard-test-v1 and splice-token-standard-test-v2 into a single test package, with separate modules for V1 and V2 tests.

On Thu, Apr 9, 2026 at 9:06 PM Wayne Collier via lists.sync.global <wayne.collier=digitalasset.com@...> wrote:

CIP-0112 is now in the CIP repository in Draft state.

 

https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md

--

Dr. Bernhard Elsner

Chief Product Officer / +41 76 696 70 50

Digital Asset, creators of Daml

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

--

Dr. Bernhard Elsner

Chief Product Officer / +41 76 696 70 50

Digital Asset, creators of Daml

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

--

 

	Dr. Simon Meier
	Principal Architect	simon@...
		Creators of Canton Network

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

--

 

	Dr. Simon Meier
	Principal Architect	simon@...
		Creators of Canton Network

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

 

The only thing I still see missing, is for the executor to gain visibility on the underlying locked assets.
We have some cases where an AmuletAllocation is still active on ledger, but the underlying LockedAmulet has been removed. The V2 will let us handle this case by exercising Cancel on the allocation, without needing the user's authorization. But its still a handler after the fact.
If we could see this LockedAmulet getting archived on our /updates stream, we could handle this before getting an error from the Scan API's transfer context response, effectively allowing us to cancel such allocations before we try to use them.

 

 

Hi John,

thanks for the thoughtful feedback. As for your request wrt expiry handling:

 

The only thing I still see missing, is for the executor to gain visibility on the underlying locked assets.
We have some cases where an AmuletAllocation is still active on ledger, but the underlying LockedAmulet has been removed. The V2 will let us handle this case by exercising Cancel on the allocation, without needing the user's authorization. But its still a handler after the fact.
If we could see this LockedAmulet getting archived on our /updates stream, we could handle this before getting an error from the Scan API's transfer context response, effectively allowing us to cancel such allocations before we try to use them.

 

 

The V2 interfaces expose the expiry time of an Allocation separately from the `settlementDeadline` here: https://github.com/canton-network/splice/blob/30c75481b46088792b05b2f9d910e89dfbe08040/token-standard/splice-api-token-allocation-v2/daml/Splice/Api/Token/AllocationV2.daml#L176-L185

For Amulet the lock expires at exactly the same time as the Allocation. Furthermore, the SV apps will automate the archival of the expired allocations. It seems to me that this should solve your problem of having to manage stale Allocations. Do you see it the same, or is someting missing?

 

--

 

	Dr. Simon Meier
	Principal Architect	simon@...
		Creators of Canton Network

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Tradeweb would be happy to endorse CIP-0112.

 

Best, Justin