Token Standard V2 DevNet is live

Announcements
23

The reset today will happen around 21:30 CEST. Apologies for the delay :person_bowing:

24

We won’t manage to deploy to Token Standard DevNet today due to technical issues, so we’re postponing the deployment to tomorrow Tuesday 8 June.

25

Still dealing with issues, postponed again to tomorrow.

26

0.6.8-snapshot.20260610.3066.0.v1faf0033 is now deployed on the Token Standard v2 DevNet. Apologies for the delay this week :person_bowing:

ATTENTION: the line canton.participants.participant.parameters.engine.contract-state-mode=NUCK MUST NOT be specified anymore, otherwise your validator will fail to startup
(this was already the case as of May 4th)

Please check the docs and download the latest release bundle.

27

Committed allocations + iterated settlement is interesting. How does Canton prevent capital from being overcommitted across multiple venues while preserving low-friction off-chain matching with on-chain settlement? Sorry if this is a basic question — could someone help explain how this works?

28

The allocation is committed to a specific settlement venue. The corresponding holdings are locked, so they cannot be committed multiple times. Thus no over-committment is possible, but you also do require sufficient capital to satisfy the capital requirements of all trading venues that you want to use concurrently.

Individual trading venues have free choice wrt how much capital they require to be committed up front though.

1 Like
29

0.6.9-snapshot.20260615.3096.0.v27548d88 is now deployed on the Token Standard v2 DevNet.

ATTENTION: the line canton.participants.participant.parameters.engine.contract-state-mode=NUCK MUST NOT be specified anymore, otherwise your validator will fail to startup
(this was already the case as of May 4th)

Please check the docs and download the latest release bundle.

30

Thanks for the clarification,rom a market structure perspective, where exactly does the economic advantage originate? If assets are locked, settlement guarantees are maintained, and venues still require dedicated commitments, what measurable inefficiency present in today’s pre-funded systems is eliminated? Is there any empirical model or simulation showing that committed allocations produce higher velocity of capital at network scale rather than simply redistributing collateral constraints?:grin:

31

The main advantage is that in V2 a batch of transfers affecting the same account is funded net, whereas in V1 each individual transfer needs to be funded on its own. See the example in the CIP specification.

1 Like
32

Thanks sir, can i ask again? if V2 efficiency is achieved through net funding across a transfer batch, under what conditions does the model converge back toward V1 behavior? For example, if offsetting flows become sparse or highly directional, is there a threshold where net funding no longer materially reduces capital requirements?

33

Would it be fair to say V2 changes the economics of settlement without expanding the settlement possibility frontier itself? If not, what transactions become feasible in V2 that were not feasible in V1?

34

Is USDCx supported on the token standard v2 devnet? We are keen to test workflows with USDCx if possible

35

0.6.10-snapshot.20260622.3187.0.vcaa7b3bf is now deployed on the Token Standard v2 DevNet. Note that this should be the last deployment to this cluster, as Token Standard v2 will be included in Splice 0.6.11.

ATTENTION: the line canton.participants.participant.parameters.engine.contract-state-mode=NUCK MUST NOT be specified anymore, otherwise your validator will fail to startup
(this was already the case as of May 4th)

Please check the docs and download the latest release bundle.

36

USDCx uses the DA registry app daml models. The app team is currently working on the integration of Token Standard v2. We don’t have a timeline yet but it will take a few more weeks before we deploy anything to devnet.

1 Like
37

thanks you - standing by to test our workflows

38

Hi, is this the right place to ask a CIP-112 v2 design/semantics question? If there is a better venue, happy to move it there.

I’m looking for clarification on committed allocations.

My current understanding is that committed = True restricts Allocation_Withdraw, but does not by itself restrict Allocation_Cancel; cancel/settle authorization is ultimately enforced by the registry implementation.

Is that the intended model?

More specifically:

  • Are committed allocations meant only for settlement/DvP-style flows, or also for longer-lived escrow-style use cases?

  • If a client needs a committed allocation that cannot be cancelled unilaterally by the authorizer/executor, is that expected to be handled as registry-specific policy?

  • Is there any standard way for a client to discover or require such a policy, or would that need a future capability/profile/extension?

  • For adding funds to an existing committed allocation, is cancel-and-reallocate the expected portable pattern, or is there a preferred lock-preserving rollover/top-up flow?

Thanks.

39

Hi @Sergey_Kisel , good questions. Please ask them either on a dedicated topic in the app dev section of the forum (feel free to tag me) or on the thread on the cip-discuss mailing list where the design of the token standard V2 was worked out.

1 Like
Current Best Practices