Following @CJ42 comment there, I'm opening this issue to discuss the addition of ERC725Y key-value pairs to flag an asset contract (lsp7 & lsp8 for now) as non-transferable. This addition would be integrated into this PR: PR 682.
Why flagging an asset contract as non-transferable?
For applications to know if you're dealing with NTTs (Non-Transferable Tokens) or not, as it obviously make a big difference. Use-cases linked to NTTs are more associated with certification, and non-financial products, so you might want to display these assets a different way. Also, for a more practical reason, you want the apps & smart cotnracts to know if they can transfer an asset, so they can be adapted.
What keys to add?
I thought about 2 scenarios, one where you would have one key per standard (e.g keccak(LSP7NonTransferable) & keccak(LSP8NonTransferable)). Though, this approach might just add useless complexity. That would mean that we would need to add one key for each new standard and that applications would have to know all these keys.
So the other solution, that in my opinion is better, would be to have a shared Non-Transferable key for all the LSPs. That way, applications would only have to know that key, and no additional key would need to be created if new asset standard are created. The key could be keccak(LSPNonTransferable)
Following @CJ42 comment there, I'm opening this issue to discuss the addition of ERC725Y key-value pairs to flag an asset contract (lsp7 & lsp8 for now) as non-transferable. This addition would be integrated into this PR: PR 682.
Why flagging an asset contract as non-transferable?
For applications to know if you're dealing with NTTs (Non-Transferable Tokens) or not, as it obviously make a big difference. Use-cases linked to NTTs are more associated with certification, and non-financial products, so you might want to display these assets a different way. Also, for a more practical reason, you want the apps & smart cotnracts to know if they can transfer an asset, so they can be adapted.
What keys to add?
I thought about 2 scenarios, one where you would have one key per standard (e.g keccak(LSP7NonTransferable) & keccak(LSP8NonTransferable)). Though, this approach might just add useless complexity. That would mean that we would need to add one key for each new standard and that applications would have to know all these keys.
So the other solution, that in my opinion is better, would be to have a shared Non-Transferable key for all the LSPs. That way, applications would only have to know that key, and no additional key would need to be created if new asset standard are created. The key could be keccak(LSPNonTransferable)