Hi there Support,
We have been discussing the transfer of NFT ownership and are seeking your input on whether it’s possible to prevent a transfer from taking place within the transfer function. Specifically, we are interested in exploring the idea of imposing certain requirements that must be fulfilled before the transfer can proceed, effectively blocking the current owner from transferring the NFT to a new owner until those conditions are met.
Thanks in advance for your help.
Yes, that is certainly possible.
The transfer function can in principle always reject the transfer (for example for a soul bound token), or it can impose additional restrictions. There is nothing in CIS2 that mandates that the owner must be able to transfer their token unconditionally.
For example adding requirements for royalties would be a natural additional thing to require.
Does that answer your question? Otherwise maybe give an example of something like what you would like to achieve, and we can provide more details.
Thank you for your message. We have multiple use cases for this particular feature. Among them is a scenario where the owner provides a specific string that the transfer function uses to determine whether to accept or reject the transfer. Please note that it is crucial to ensure that the string used cannot be retrieved from the contract or its history after the transfer has either succeeded or failed. How can we achieve this?
Our primary strategy for this scenario is to implement a function that allows for setting the string, and within the transfer functions, we will reset the string. To ensure that the string remains secure, we can encrypt it within the set function. Even if someone gains access to the history of the string, they will not be able to decipher its meaning, and the value stored in the history cannot be used directly.
Just a quick follow-up query - if a value is passed as a parameter to a smart contract function without directly altering the contract’s state, does the passed value still get stored on the blockchain?
Example. The value 4 is passed to the smart contract in a function call, a contract state is multiplied by that value (4). Is the fact that the value 4 was passed stored on the blockchain? or only the new value of the state
A transaction is sent around in the network and anyone receiving the information can store this, so you cannot rely on this alone to pass secrets. You could encrypt the information, but the smart contract cannot decrypt the information without it becoming public, since you cannot provide the smart contract with the key without exposing the key publicly.
Also, the CIS-2 transfer allows for including additional arbitrary data, which you can use instead of first setting the string. However, this data will be public visible like the rest of the transaction, so it might not be what you need.
To clarify, the value (4) passed in the transaction will not be visible once the state has been changed, unless someone explicit is storing it?
Not sure what you mean by visible.
The node provided by Concordium will store it, since other nodes might need this information to catch up to the chain. You should not put secrets directly in a transaction.
Just to clarify, is it correct to say that the scenario mentioned above cannot be achieved?
This one:
We have multiple use cases for this particular feature. Among them is a scenario where the owner provides a specific string that the transfer function uses to determine whether to accept or reject the transfer. Please note that it is crucial to ensure that the string used cannot be retrieved from the contract or its history after the transfer has either succeeded or failed. How can we achieve this?
You cannot prevent this string from being available after sending it to the chain. So it cannot be achieved like this.
Depending on the details of your use case, we can maybe find a way to achieve what you want without needing this. But you will have to provide the use case.
Thank you for your message. I will need to consult with my team before providing a final answer. It’s possible that we may only need to block the first transfer, which should suffice as the string in question has not been sent before. I’ll be in touch with more information after our internal discussions.
Instead of just a string used signed messages.
Sender can sign using a Private key whoes public key is already known to the contract.
coupled with a nonce maintained in chain. a single signature can only be used once.
Yes, thanks. This was the solution we ended up using