Consider a scenario, we are building the NFT token using DAML, where there is an issuer who mints these tokens, then transfers the ownership to say buyer_A who becomes the token owner. Now in the future, a current token owner can also sell the NFT token to some other buyerB.
Now, given the case, when the seller (current owner of token) sells the NFT token to a buyer_B then do we really required to get the signature of the token-issuer for this transaction?
If yes, Does it have something to do with how consensus is achieved and the validity of token is verified in DAML w/ Canton network?
Because I have seen this scenario/implementation in some tutorial/training videos. so would be happy if get some help to add clarity here.
@balajimoresyne
Smart contracts are immutable on the Daml ledger. Updating contract data such as the owner field on an asset contract is implemented by archiving the contract with the previous owner and creating a new contract with the new owner.
In a typical implementation of an asset smart contract, whether fungible or non-fungible, (see Wallet Sample App for reference), the role of the issuer is to ensure the integrity of the asset issue. The issuer must authorize the issuance of the asset contract. If the issuer were not a signatory on the contract, and the owner were the sole signatory, then nothing would prevent the owner from at any time creating as many asset contracts as the owner pleases. In other words such a system would allow the owner to print money. The requirement for the issuer’s authority for the creation of a new asset contract is what safeguards the asset from uncontrolled issuance.
Since asset transfer requires archiving old contract and creating new one, the issuer’s authorization is necessary for this operation. This said, the system the requires obtaining explicit consent from the issuer for every transfer would not be practical. This is where the delegation of authority through choices and their controllers comes in handy. E.g. a transfer of an NFT can be implemented as a choice on the template representing the NFT, where issuer and owner are the signatories, with the owner as the choice controller. This construct allows the owner to unilaterally exercise the choice and to have the issuer’s authorization for all the consequences of the choice (e.g. the archival of existing contract and the creation of a new one).
Does this answer your question?
Does this mean the transaction needs to be verified and signed implicitly by the issuer’s participant node?
So participant node of the issuer, acting on behalf, verifies, validates, and signs token transfer transactions in the background.
Does this mean the transaction needs to be verified and signed implicitly by the issuer’s participant node?
So participant node of the issuer, acting on behalf, verifies, validates, and signs token transfer transactions in the background.
Yes, that’s correct. By default, the participant node of the issuer needs to validate every transfer of the token.
We have other options (e.g. VIP participants [1]) for ensuring that only active contracts can be used, but in the end there must be some entity that validates every transfer. Otherwise, the seller could transfer the same token more than once.
[1] Overview and Assumptions — Daml SDK 2.7.6 documentation
(Search for “VIP”.)
1 Like