How will a Daml asset work with secondary markets - Centralized Exchange or a DeFi protocol ? We can assume that there could be 50 primary asset issuers with each one defining the characteristics of an asset (for ex: bond) and the associated smart contracts differently. If the asset registry is maintained only by the issuer of an asset, the secondary market protocols have to program and interact with each such asset issuer. How would this work on execution and settlement using stablecoins/CBDC?
1 Like
I’m not sure I understand the question; it seems way too generic to answer. I’ll try anyway.
Ultimately, a Daml network is a separate “system” which can, at a very high level of abstraction, be thought of roughly as a single, shared database (with high privacy) between various disparate legal entities. If there’s another system that needs to work with the same data, the best path forward is to connect it to the same database — i.e. make it join the Daml network — so you can avoid all sorts of synchronization issues.
If that’s not an option and you require that new system to have its own, separate database, then you’re back to the same kind of interop between systems that any two systems have: you’ll have to write some code that talks to both APIs and transfers relevant data between them. (And possibly deal with reconciliation at that level.)
There may be better / more precise answers if your question could be made a little bit more specific. But there’s no magic: if you want to have two separate databases containing the same data, you’ll need something in-between that transfers state changes between them.
(I’m using “database” in the broadest possible sense here: something that holds data in some form.)
Let me expand a bit on how we think about assets in a Daml Network.
You are correct that if each primary asset issuer implements their own asset representation and business logic around the instrument, you’d need custom settlement code (ie. DvP templates) for each pair of traded assets to facilitate secondary trading.
To remediate this all asset registries should be using a common asset model to represent holdings (you can think of this similar to an ERC-20 for Daml). That way you can write settlement code that works across all registires that are based on said asset model.
Now with respect to different financial instruments being traded and each requiring its own smart contracts to encode its evolution over time, the pattern to follow is to separate the representation of an asset holding (ie. I hold 10 units of X) from the actual implementation of what I’m holding (ie. what is X and how does it behave). This way your settlement code still works across different financial instruments, as your holding only references the instrument by an id, and is not tighly coupled to it.
Our first iteration on implementing such a model can be found here, and is freely usable as open-source code. You can find it being used in action in this codebase.
However, we are working on a major revamp of this library and will be releasing and annoucing this in the coming weeks. So stay tuned, make sure to be subscribed to our newsletter, and watch this space.
As to your question specifically on stablecoins / CBDCs, it depends:
- If the stablecoin / CBDC lives on a Daml ledger you can use the patterns / libraries described my previous answer
- If the stablecoin / CBDC lives on a different ledger with smart contract capabilities, you can implement atomic settlement using HTLC (Hashed timelock contract)
- If you interact with traditional payment rails (eg. current central or commercial bank cash) you have to give up atomicity, but you could still implement DvP-style settlement, eg. using a delivery-upon-cash-receipt mechanism