CIP-0056 Canton Network Token Standards
Hi, all
I've been working on the Global Synchronizer team at Digital Asset for a couple of years, and now I'm working on financial modeling. I've worked on Amulet and several other aspects of Splice, and on a lot of the governance design.
As Hashnote, Brale, SocGen and others have begun to issue assets on the Global Synchronizer, and Copper and Dfns have added secure wallet support for Canton Coin, we’ve reached an ecosystem scale that needs standards that will make all Canton-native assets compatible and exchangeable. We’ll all benefit if it’s easy for any Canton-native wallet to display and transfer any standard-compliant asset.
I’ve made several steps toward a proposed standard, in collaboration with Matteo Limberto, who also works in financial modeling at Digital Asset.
Before sharing a proposal for the standard itself, I’d like to share our overall thinking here, and get your input.
Matteo and I believe the standard needs to consider the following three kinds of applications:
asset registries: which are used by registrars to manage the ownership records of CN tokens. For example, Amulet as the app backing Canton Coin, or Digital Asset’s tokenization utility backing USYC on Canton.
wallets and custody solutions: which are used by investors to manage their CN token holdings across multiple registry apps. For example, DFNS, Copper, HydraX, or future retail oriented wallets.
apps: Any other services which interact with tokenized assets on-chain.
We believe the main purpose of the standard should be to provide tightly scoped APIs that cleanly decouple the implementation and evolution of these three kinds of apps and thereby reduce friction and foster network growth.
We believe that at the UX level, the standard should allow the implementation of a universal wallet that empowers investors to do the following:
Display current and past holdings of all their Canton Network assets together with the total supply of the assets as reported by their registries.
Initiate bilateral, free-of-payment transfers of these holdings.
Monitor the progress of these transfers.
Review, approve and reject asset allocations requested by trading apps to atomically settle on-ledger DvP obligations.
While the first two functionalities are well-known from the crypto space, the latter two are inspired by traditional finance:
Item 3 caters to the fact that not all transfers can be completed atomically, as additional checks and approvals can be required by regulation (e.g., KYC or OFAC checks). Tracking the progress of such transfers on-ledger removes uncertainty.
Item 4 caters to the fact that TradFi typically does not settle trades atomically at the time when they are matched, but post-trade within a pre-agreed time-window. While DLT can and will reduce the time-window for settlement, it is unlikely that it will completely change the overall workflow, as that is too deeply embedded in current regulation or the ways of working of current financial institutions.
This also highlights the overall philosophy behind the standard’s design, which is to provide clean DLT-ready APIs that allow the existing processes used for Real-World Assets (RWAs) today to be lifted to DLT. Thereby focusing on the needs of apps using RWAs today, and giving them the privacy guarantees and the controls required to work with RWAs in a regulatory compliant way.
Does that match what you would expect a Canton Network token standard to focus on? And what do you think about the approach and design philosophy we are proposing?
Looking forward to your feedback,
Simon Meier
--
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.- I think a unified token standard is the right direction and will make building applications that deal with a variety of assets easier.I would like to highlight the "past holdings" part of the intended UX as an area where it would be possible to raise the bar relative to other DLT APIs. Accounting for on-ledger assets is a frequent pain point, especially in cases where balances need to be known as of the end of a particular reporting period. It is often necessary to get the current balance and a superset of the relevant transactions from the API then filter and walk back transactions to the date of interest. I think this would be a good use case to include in the API design and would allow universal wallet implementations to be a one site solution for the wallet and custody app user base.Excited to hear more details as you work them out!Matt FranczakBrale
- Hi Matt,On Thu, Jan 23, 2025 at 8:28 PM Matt Franczak via lists.sync.global <matt=brale.xyz@...> wrote:I think a unified token standard is the right direction and will make building applications that deal with a variety of assets easier.Thanks, that's great to hear! Things are progressing well on our side, and I should be able to share both the presentation and code I alluded to in my first mail this week.I would like to highlight the "past holdings" part of the intended UX as an area where it would be possible to raise the bar relative to other DLT APIs. Accounting for on-ledger assets is a frequent pain point, especially in cases where balances need to be known as of the end of a particular reporting period. It is often necessary to get the current balance and a superset of the relevant transactions from the API then filter and walk back transactions to the date of interest. I think this would be a good use case to include in the API design and would allow universal wallet implementations to be a one site solution for the wallet and custody app user base.Ah that's an interesting point. My expectation is that wallets do have to ingest the transaction history of a user from a node that host's the user's party, as Canton's privacy support is built such that a user's data is by default only available on their node.That said: the Participant Query Store (PQS), which we use to build the operational data stores backing Daml applications, has built-in support (docs) for reading consistent, historic snapshots of a user's ACS, which includes their holdings. So, I'd recommend using the PQS to address your need for consistent as-of snapshots.Kind regards,Simon
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
Hi all,
I’m happy to share with you this presentation that explains our draft for the Canton Network token standard, whose code we just open-sourced here: https://github.com/digital-asset/cn-token-standard-proposal
It would be great if you could have a look at the presentation and code to understand that draft and provide feedback.
I suggest you start with the presentation before diving into the code. It also contains a clear description of the current state and the next steps for making this an actual standard. I’d also be happy to run interested parties through the presentation in a Zoom call. Feel free to ping me with your availability here or at simon@... for an invite.
I look forward to working together to shape a CIP defining the first version of a CN token standard.
Kind regards,
Simon Meier
On Wed, Jan 15, 2025 at 3:06 PM Simon Meier <simon@...> wrote:Hi, all
I've been working on the Global Synchronizer team at Digital Asset for a couple of years, and now I'm working on financial modeling. I've worked on Amulet and several other aspects of Splice, and on a lot of the governance design.
As Hashnote, Brale, SocGen and others have begun to issue assets on the Global Synchronizer, and Copper and Dfns have added secure wallet support for Canton Coin, we’ve reached an ecosystem scale that needs standards that will make all Canton-native assets compatible and exchangeable. We’ll all benefit if it’s easy for any Canton-native wallet to display and transfer any standard-compliant asset.
I’ve made several steps toward a proposed standard, in collaboration with Matteo Limberto, who also works in financial modeling at Digital Asset.
Before sharing a proposal for the standard itself, I’d like to share our overall thinking here, and get your input.
Matteo and I believe the standard needs to consider the following three kinds of applications:
asset registries: which are used by registrars to manage the ownership records of CN tokens. For example, Amulet as the app backing Canton Coin, or Digital Asset’s tokenization utility backing USYC on Canton.
wallets and custody solutions: which are used by investors to manage their CN token holdings across multiple registry apps. For example, DFNS, Copper, HydraX, or future retail oriented wallets.
apps: Any other services which interact with tokenized assets on-chain.
We believe the main purpose of the standard should be to provide tightly scoped APIs that cleanly decouple the implementation and evolution of these three kinds of apps and thereby reduce friction and foster network growth.
We believe that at the UX level, the standard should allow the implementation of a universal wallet that empowers investors to do the following:
Display current and past holdings of all their Canton Network assets together with the total supply of the assets as reported by their registries.
Initiate bilateral, free-of-payment transfers of these holdings.
Monitor the progress of these transfers.
Review, approve and reject asset allocations requested by trading apps to atomically settle on-ledger DvP obligations.
While the first two functionalities are well-known from the crypto space, the latter two are inspired by traditional finance:
Item 3 caters to the fact that not all transfers can be completed atomically, as additional checks and approvals can be required by regulation (e.g., KYC or OFAC checks). Tracking the progress of such transfers on-ledger removes uncertainty.
Item 4 caters to the fact that TradFi typically does not settle trades atomically at the time when they are matched, but post-trade within a pre-agreed time-window. While DLT can and will reduce the time-window for settlement, it is unlikely that it will completely change the overall workflow, as that is too deeply embedded in current regulation or the ways of working of current financial institutions.
This also highlights the overall philosophy behind the standard’s design, which is to provide clean DLT-ready APIs that allow the existing processes used for Real-World Assets (RWAs) today to be lifted to DLT. Thereby focusing on the needs of apps using RWAs today, and giving them the privacy guarantees and the controls required to work with RWAs in a regulatory compliant way.
Does that match what you would expect a Canton Network token standard to focus on? And what do you think about the approach and design philosophy we are proposing?
Looking forward to your feedback,
Simon Meier
----
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
Simon, thank you.
CN token standard is a good step forward. Is there an analysis/consideration around the proposed design’s relation/impact on the target Canton Network usage and fees?
Best,
Pinar
From: cip-discuss@... <cip-discuss@...> on behalf of Simon Meier via lists.sync.global <simon=digitalasset.com@...>
Date: Tuesday, January 28, 2025 at 9:30 PM
To: cip-discuss@... <cip-discuss@...>
Cc: Matteo Limberto <matteo.limberto@...>, Wayne Collier <wayne.collier@...>, Ratko Veprek <ratko@...>, Bernhard Elsner <bernhard.elsner@...>
Subject: Re: [cip-discuss] Towards Canton Network Token StandardsYou don't often get email from simon=digitalasset.com@.... Learn why this is important
Hi all,
I’m happy to share with you this presentation that explains our draft for the Canton Network token standard, whose code we just open-sourced here: https://github.com/digital-asset/cn-token-standard-proposal
It would be great if you could have a look at the presentation and code to understand that draft and provide feedback.
I suggest you start with the presentation before diving into the code. It also contains a clear description of the current state and the next steps for making this an actual standard. I’d also be happy to run interested parties through the presentation in a Zoom call. Feel free to ping me with your availability here or at simon@... for an invite.
I look forward to working together to shape a CIP defining the first version of a CN token standard.
Kind regards,
Simon Meier
On Wed, Jan 15, 2025 at 3:06 PM Simon Meier <simon@...> wrote:Hi, all
I've been working on the Global Synchronizer team at Digital Asset for a couple of years, and now I'm working on financial modeling. I've worked on Amulet and several other aspects of Splice, and on a lot of the governance design.
As Hashnote, Brale, SocGen and others have begun to issue assets on the Global Synchronizer, and Copper and Dfns have added secure wallet support for Canton Coin, we’ve reached an ecosystem scale that needs standards that will make all Canton-native assets compatible and exchangeable. We’ll all benefit if it’s easy for any Canton-native wallet to display and transfer any standard-compliant asset.
I’ve made several steps toward a proposed standard, in collaboration with Matteo Limberto, who also works in financial modeling at Digital Asset.
Before sharing a proposal for the standard itself, I’d like to share our overall thinking here, and get your input.
Matteo and I believe the standard needs to consider the following three kinds of applications:
- asset registries: which are used by registrars to manage the ownership records of CN tokens. For example, Amulet as the app backing Canton Coin, or Digital Asset’s tokenization utility backing USYC on Canton.
- wallets and custody solutions: which are used by investors to manage their CN token holdings across multiple registry apps. For example, DFNS, Copper, HydraX, or future retail oriented wallets.
- apps: Any other services which interact with tokenized assets on-chain.
We believe the main purpose of the standard should be to provide tightly scoped APIs that cleanly decouple the implementation and evolution of these three kinds of apps and thereby reduce friction and foster network growth.
We believe that at the UX level, the standard should allow the implementation of a universal wallet that empowers investors to do the following:
- Display current and past holdings of all their Canton Network assets together with the total supply of the assets as reported by their registries.
- Initiate bilateral, free-of-payment transfers of these holdings.
- Monitor the progress of these transfers.
- Review, approve and reject asset allocations requested by trading apps to atomically settle on-ledger DvP obligations.
While the first two functionalities are well-known from the crypto space, the latter two are inspired by traditional finance:
- Item 3 caters to the fact that not all transfers can be completed atomically, as additional checks and approvals can be required by regulation (e.g., KYC or OFAC checks). Tracking the progress of such transfers on-ledger removes uncertainty.
- Item 4 caters to the fact that TradFi typically does not settle trades atomically at the time when they are matched, but post-trade within a pre-agreed time-window. While DLT can and will reduce the time-window for settlement, it is unlikely that it will completely change the overall workflow, as that is too deeply embedded in current regulation or the ways of working of current financial institutions.
This also highlights the overall philosophy behind the standard’s design, which is to provide clean DLT-ready APIs that allow the existing processes used for Real-World Assets (RWAs) today to be lifted to DLT. Thereby focusing on the needs of apps using RWAs today, and giving them the privacy guarantees and the controls required to work with RWAs in a regulatory compliant way.
Does that match what you would expect a Canton Network token standard to focus on? And what do you think about the approach and design philosophy we are proposing?
Looking forward to your feedback,
Simon Meier
--
--
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 Pinar,
CN token standard is a good step forward. Is there an analysis/consideration around the proposed design’s relation/impact on the target Canton Network usage and fees?
Good question! The design is optimized to use traffic cost-effectively: in particular it ensures that doing transfers or DvP settlement using the standard does not require more Daml transactions when using the standard compared to using registry-specific workflows. You can see that registries can allow their users to do a free-of-payment transfer using a single Daml transaction; and a DvP leg settlement using two Daml transactions (one to allocate the assets, and a second one to transfer them as part of the actual DvP settlement).Secondly, when comparing the actual transaction structure of free-of-payment transfers for CC initiated via the standard vs. the ones initiated using the CC templates and choices directly one notices that there is little overhead as the structure matches. I haven't measured the precise over-head, but I expect there to be some (~ 10%) due to the more generic encoding of a CC TransferContext (code) as a CN token standard ChoiceContext (code). I expect overheads for other token registries to be similar.Does that help? Any particular concerns you'd like me to address?Kind regards,Simon
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 textHi,We are happy to announce a new snapshot of the token standard proposal. Development is now continuing in the splice repository, currently under the canton-3.3 branch https://github.com/hyperledger-labs/splice/tree/canton-3.3/token-standard. The existing repository at https://github.com/digital-asset/cn-token-standard-proposal will be archived and is no longer updated.
Reference the changelog https://github.com/hyperledger-labs/splice/blob/canton-3.3/token-standard/CHANGELOG.md for all changes since the original announcement.We expect to publish weekly updates to that branch and will continuously update the changelog.There is also an early test network available called token-std-devnet that you can use until devnet supports the token standard. Please refer to the instructions at https://github.com/hyperledger-labs/splice/blob/canton-3.3/token-standard/README.md#testing for how to do local testing as well as how to access token-std-devnet.On Wed, Jan 15, 2025 at 3:07 PM Simon Meier via lists.sync.global <simon=digitalasset.com@...> wrote:Hi, all
I've been working on the Global Synchronizer team at Digital Asset for a couple of years, and now I'm working on financial modeling. I've worked on Amulet and several other aspects of Splice, and on a lot of the governance design.
As Hashnote, Brale, SocGen and others have begun to issue assets on the Global Synchronizer, and Copper and Dfns have added secure wallet support for Canton Coin, we’ve reached an ecosystem scale that needs standards that will make all Canton-native assets compatible and exchangeable. We’ll all benefit if it’s easy for any Canton-native wallet to display and transfer any standard-compliant asset.
I’ve made several steps toward a proposed standard, in collaboration with Matteo Limberto, who also works in financial modeling at Digital Asset.
Before sharing a proposal for the standard itself, I’d like to share our overall thinking here, and get your input.
Matteo and I believe the standard needs to consider the following three kinds of applications:
asset registries: which are used by registrars to manage the ownership records of CN tokens. For example, Amulet as the app backing Canton Coin, or Digital Asset’s tokenization utility backing USYC on Canton.
wallets and custody solutions: which are used by investors to manage their CN token holdings across multiple registry apps. For example, DFNS, Copper, HydraX, or future retail oriented wallets.
apps: Any other services which interact with tokenized assets on-chain.
We believe the main purpose of the standard should be to provide tightly scoped APIs that cleanly decouple the implementation and evolution of these three kinds of apps and thereby reduce friction and foster network growth.
We believe that at the UX level, the standard should allow the implementation of a universal wallet that empowers investors to do the following:
Display current and past holdings of all their Canton Network assets together with the total supply of the assets as reported by their registries.
Initiate bilateral, free-of-payment transfers of these holdings.
Monitor the progress of these transfers.
Review, approve and reject asset allocations requested by trading apps to atomically settle on-ledger DvP obligations.
While the first two functionalities are well-known from the crypto space, the latter two are inspired by traditional finance:
Item 3 caters to the fact that not all transfers can be completed atomically, as additional checks and approvals can be required by regulation (e.g., KYC or OFAC checks). Tracking the progress of such transfers on-ledger removes uncertainty.
Item 4 caters to the fact that TradFi typically does not settle trades atomically at the time when they are matched, but post-trade within a pre-agreed time-window. While DLT can and will reduce the time-window for settlement, it is unlikely that it will completely change the overall workflow, as that is too deeply embedded in current regulation or the ways of working of current financial institutions.
This also highlights the overall philosophy behind the standard’s design, which is to provide clean DLT-ready APIs that allow the existing processes used for Real-World Assets (RWAs) today to be lifted to DLT. Thereby focusing on the needs of apps using RWAs today, and giving them the privacy guarantees and the controls required to work with RWAs in a regulatory compliant way.
Does that match what you would expect a Canton Network token standard to focus on? And what do you think about the approach and design philosophy we are proposing?
Looking forward to your feedback,
Simon Meier
--
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.--Moritz KieferArchitect - Canton NetworkDigital 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. - Simon Meier:
Can you clarify whether you plan to propose the standards as a single CIP, or multiple?
The CIP (or CIPs) do not need to include the code, just a specification. I'm unclear whether it would be best to approve all the elements of the token standard as a single CIP, or as multiple, but I'm inclined toward hoping it can be a single CIP with the separate standards sections called out in the Specification. - toggle quoted message Show quoted textHi Wayne,good question. The current plan is to write a single CIP encompassing all the token APIs explained in the presentation. That might change, for example, if we find that the validation of the different APIs progresses at a vastly different pace. However, so far a single CIP is the plan.Kind regards,Simon MeierOn Fri, Feb 28, 2025 at 6:47 PM Wayne Collier via lists.sync.global <wayne.collier=digitalasset.com@...> wrote:Simon Meier:
Can you clarify whether you plan to propose the standards as a single CIP, or multiple?
The CIP (or CIPs) do not need to include the code, just a specification. I'm unclear whether it would be best to approve all the elements of the token standard as a single CIP, or as multiple, but I'm inclined toward hoping it can be a single CIP with the separate standards sections called out in the Specification.--
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. - Dear all,please find here the CIP proposing a Canton Network token standard: https://github.com/global-synchronizer-foundation/cips/pull/45/filesI'm looking forward to receiving your feedback, and ultimately getting jointly to the point where we can see this live on MainNet.Kind regards,Simon MeierPS: The https://github.com/hyperledger-labs/splice/tree/canton-3.3/token-standard branch has been updated with the most recent changes developed while writing the CIP. Likewise, the token-std-devnet mentioned by Moritz in his previous message has been updated with the most recent changes. As before: refer to the instructions at https://github.com/hyperledger-labs/splice/blob/canton-3.3/token-standard/README.md#testing for how to do local testing as well as how to access token-std-devnet.
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. - HelloPlease find the CIP-0056: Canton Network Token Standard updated at the PR https://github.com/global-synchronizer-foundation/cips/pull/45.DA is the sponsor.
In order to move to a vote we are requesting a Super Validator Node Owner to endorse the CIP.Anyone SV Node Owner willing to endorse or changes needed? - toggle quoted message Show quoted text
C7/7RIDGE is happy to endorse this CIP
Veronica
V E R O N I C A A U G U S T S S O N
/
P A R T N E R
7RIDGE IS A PRIVATE MARKETS ASSET MANAGER INVESTED IN TRANSFORMATIVE TECHNOLOGY FOR FINANCIAL SERVICES TO POWER THE GLOBAL ECONOMY
Signature for V e r o n i c a A u g u s t s s o n
From: cip-discuss@... <cip-discuss@...> On Behalf Of DrAmandaLMartin via lists.sync.global
Sent: Wednesday, 19 March 2025 22:10
To: cip-discuss@...
Subject: Re: [cip-discuss] CIP-0056 Canton Network Token StandardsHello
Please find the CIP-0056: Canton Network Token Standard updated at the PR https://github.com/global-synchronizer-foundation/cips/pull/45.
DA is the sponsor.
In order to move to a vote we are requesting a Super Validator Node Owner to endorse the CIP.Anyone SV Node Owner willing to endorse or changes needed?
- toggle quoted message Show quoted textHi all,just wanted to close out this thread by calling out that:
- the CIP for the token standard was accepted on 2025-03-31
- the Splice 0.4.0 release includes the release of the token standard
- concretely, it defines both the APIs specified in the CIP and implements them in Amulet
- for additional information see, https://github.com/hyperledger-labs/splice/tree/main/token-standard#readme
Kind regards,Simon MeierOn Tue, Mar 18, 2025 at 7:23 AM Simon Meier <simon@...> wrote:Dear all,please find here the CIP proposing a Canton Network token standard: https://github.com/global-synchronizer-foundation/cips/pull/45/filesI'm looking forward to receiving your feedback, and ultimately getting jointly to the point where we can see this live on MainNet.Kind regards,Simon MeierPS: The https://github.com/hyperledger-labs/splice/tree/canton-3.3/token-standard branch has been updated with the most recent changes developed while writing the CIP. Likewise, the token-std-devnet mentioned by Moritz in his previous message has been updated with the most recent changes. As before: refer to the instructions at https://github.com/hyperledger-labs/splice/blob/canton-3.3/token-standard/README.md#testing for how to do local testing as well as how to access token-std-devnet.--
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.
