Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LSP7,LSP8] Non-transferable flag #231

Open
samuel-videau opened this issue Sep 12, 2023 · 1 comment
Open

[LSP7,LSP8] Non-transferable flag #231

samuel-videau opened this issue Sep 12, 2023 · 1 comment

Comments

@samuel-videau
Copy link
Contributor

samuel-videau commented Sep 12, 2023

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)

@CJ42
Copy link
Member

CJ42 commented Sep 15, 2023

We need to define the JSON schema for this data key if we want to implement it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants