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.