Token Standard V2 DevNet is live
Dear community,
as explained by @bernhard in his announcement of the work on a token standard v2, DA stood up a “Token Standard V2 DevNet”, which is a temporary testing network aimed exclusively at organizations involved in validating the V2 token standard.
Use this guide to connect a fresh validator node to this network: TOKEN_STANDARD_V2_DEVNET.md
Watch this forum post to stay up to date on deployments and ask questions.
We will reset & redeploy the Token Standard V2 DevNet on Tuesday 7 exceptionally (instead of Monday 6, which is a holiday).
I will then also post the new splice version to use.
Starting reset&deploy of next version to Token Standard DevNet, will add another message once it’s done.
0.6.0-snapshot.20260407.2423.0.v98974cc3 is now deployed on the Token Standard v2 DevNet.
Heads-up: this week’s reset&deploy of the Token Standard DevNet will happen on Wednesday, as we’re awaiting Canton changes we want to include.
Starting reset&deploy of next version to Token Standard DevNet, will add another message once it’s done.
0.6.0-snapshot.20260415.2530.0.v13acc4fb is now deployed on the Token Standard v2 DevNet.
Please check the updated docs and download the latest release bundle.
Monday is a holiday in Zürich, so Token Standard DevNet will be reset & upgraded on Tuesday 21.
We won’t manage to deploy to Token Standard DevNet today due to technical issues, so we’re postponing the deployment to tomorrow Wednesday 22 April.
0.6.0-snapshot.20260422.2626.0.v5aaef00e is now deployed on the Token Standard v2 DevNet.
Please check the docs and download the latest release bundle.
root@Canton-Dev:~/splice-node/docker-compose/validator# docker pull ghcr.io/digital-asset/decentralized-canton-sync-dev/canton-participant:0.6.0-snapshot.20260422.2626.0.v5aaef00e
Error response from daemon: error from registry: denied
denied
I can’t pull it because it requires access. Could you grant me permission? GitHub username: tinhdowoss
Thank you!
@TinhDo
Try with:
docker pull ghcr.io/digital-asset/decentralized-canton-sync-dev/docker/canton-participant:0.6.0-snapshot.20260422.2626.0.v5aaef00e
Let me know if that works for you and I’ll update the docs.
Thank you, sir, it’s working fine now.
0.6.1-snapshot.20260427.2678.0.v86ff9ad5 is now deployed on the Token Standard v2 DevNet.
Please check the docs and download the latest release bundle.
0.6.3-snapshot.20260504.2741.0.v681c5054 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
Please check the docs and download the latest release bundle.
0.6.4-snapshot.20260511.2808.0.vc0dc7ce8 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.
0.6.5-snapshot.20260518.2872.0.vb91de5d4 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.
25th May is a Holiday, so the Token Standard v2 DevNet deployment will happen on the 26th.
0.6.5-snapshot.20260526.2931.0.ve28a6722 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.
0.6.7-snapshot.20260601.2982.0.v4f51a471 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.
The reset today will happen around 21:30 CEST. Apologies for the delay 
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.
Still dealing with issues, postponed again to tomorrow.
0.6.8-snapshot.20260610.3066.0.v1faf0033 is now deployed on the Token Standard v2 DevNet. Apologies for the delay this week
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.
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?
adhexzzz: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?
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.
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.
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?
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.
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?
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?
Is USDCx supported on the token standard v2 devnet? We are keen to test workflows with USDCx if possible
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.
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.
thanks you - standing by to test our workflows
Hi, is this the right place to ask a CIP-0112 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.
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.
Now that Token Standard V2 is available in (regular) DevNet, I will be taking down the “Token Standard V2 DevNet” tomorrow July 21.
Let me know if anyone has any objections.
Thank you for your cooperation in testing Token Standard v2!
Token Standard V2 DevNet is now deleted, use regular DevNet instead.
