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 V2AbstractThis 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.ProcessDigital 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 guidelinesTo 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 GrantThere 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--
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. - toggle quoted message Show quoted textAFAIS, the initial message does not mention the PR with the proposed CIP against the repository. For the sake of completeness, here it is: https://github.com/canton-foundation/cips/pull/187On Thu, Apr 2, 2026 at 10:18 AM Bernhard Elsner via lists.sync.global <bernhard.elsner=digitalasset.com@...> wrote: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 V2AbstractThis 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.ProcessDigital 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 guidelinesTo 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 GrantThere 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--
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.--
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. - toggle quoted message Show quoted text
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.--
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. - We are proposing to add improved transaction history parsing to CIP-0112. There’s a PoC in the works here.
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
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`
- 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-apiOnce 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-upcomingAnd they should land on TokenStdDevNet next week.
- Update: all four PRs have now been merged and will be deployed on TokenStdDevNet next week.
Dear Community,
I have updated the CIP text to reflect the changes due to the community feedback and resulting additional scope. My previous two update email covered these. You can find the diff for the latest CIP text here: https://github.com/canton-foundation/cips/pull/212/changes
The Splice team has now also incorporated all these additional capabilities into the Token Standard V2 interfaces, Canton Coin Smart Contract models, reference “TestTokenV2”. They have tested the flows, including cross-version, to a degree where they are comfortable that the Token Standard V2 as defined in CIP-0112 is ready to go into the Splice code base. The token standard V2 related code is on branch https://github.com/canton-network/splice/tree/token-standard-v2-upcoming.
For the avoidance of doubt, this is not yet production code ready to be merged to main today, but represents integration work that is far enough advanced to have high confidence that the token standard V2 works as intended.
That means we think it’s ready to take this into the formal governance process. Please let us know whether you are ready to endorse/vote, or whether you need more time to evaluate and provide additional feedback.
Kind regards,
Bernhard
- Hello, this is John Antoniou, CTO of Temple Digital Group. I wanted to share our thoughts regarding Token Standard V2.This update to the token standard makes the whole flow much better. We are currently using V1 for our CLOB product and there are many functionalities missing there, which forced us to utilize a delegation contract. The V2 changes solve these missing pieces and will make the need for our delegations obsolete.More specifically, I would love to endorse this update for these specific additions:1. The Iteration API allows us to have a much better housekeeping on our ACS as it will require only 1 allocation per user.2. The ability to "grow" an allocation by adding more incoming legs, this allows our users to just grow their "deposited" trading funds without creating additional allocations (saves transactions, better for ACS)3. The ability to "settle" allocation legs directly, without the need for external contracts. This makes the token standard sufficient for actually settling funds without confirmations on the hot path of the trade.4. The ability to settle trades between more than 1 counterparty. This makes the settlements faster, saving transactions needed on V1, where we needed to do this per user pair.5. The ability for the executor to unilaterally call the Cancel choice on allocations. Helps a lot with housekeeping, especially for expired (non-amulet) allocations.6. The ability to authorize more than one party as executor. This helps a lot in certain situations, for example multiple validators for the same app, without using a multi-host party infra.This is definitely in the right direction and, speaking on behalf of Temple Digital Group, it will make our product(s) much better and faster.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-L185For 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?--
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 John,Simon gave a good answer how to deal with expiry, but I think your input may be on the other side: How do you get the Holding create arguments to populate choice context.
If so, our approach is to make the create events visible:
- Each implementation can choose to make interface choices choice visible to the executors by implementing allocation*_*ExtraObservers methods. As a consequence, the creation of the locked holdings is also visible.- Canton Coin follows the default implementation which gives visibility to the executors. I expect most assets will use those defaults.- In iterated settlement the executors observe the creation of the new holdings anyway because they submit the settlement.So by default, you as the venue/executor will always observe the create events so you can index them and use them to build choice context yourself.But note that the standard deliberately does not make any statement about the stability, ease of construction, or cacheability of choice contexts. The choice context is supposed to be an opaque implementation detail of the registry. If you choose to construct choice contexts for USDCx/USDA, or CC, you need to keep a close eye on the implementations and/or test in DevNet/TestNet to make sure you catch any changes.Bernhard - Hi Simon, thanks for your response.
Indeed, I see expired amulet allocations are getting automatically archived by the AmuletAllocation_DsoExpire choice.Is there something similar for DvpLegAllocations too? - Thanks Bernhard.That would explain how to construct the choice args without hitting the Registry/Scan APIs –thank you!Although since you guys made improvements to the registry api, we no longer have a need to do that. Its pretty fast as it is now.
