-
Notifications
You must be signed in to change notification settings - Fork 28
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
Transfer approval for contracts should (probably) be based on the contract package hash #215
Comments
& perhaps this was intentional? It could make sense that you wouldn’t want to leave approval with a contract that is changing its rules. |
I didn't realize this PR exists, seems that this is already being considered - #99 |
We have considered this for 1.5 as a modality with the option to use package hash and/or contract hash. However, there are security concerns with using package hash that should be discussed. Will add an agenda item to the CEP-78 advancement meeting. |
Hi @sfeast, thanks for your report. I merged a PR adding to give the ability for get_verified_caller() to return the package if caller is a contract. Then I added boolean modalities to allow packages to mint / transfer - approve - revoke if they are operator for a token. As you noticed, those options defaults to false and we leave this decision to the collection owner if it wants to allow automatic whitelisting / approvals of versioned contracts. Those modalities can be opt in on upgrade, however one needs to use set_variables entry point to switch them off, upgrades only allowing to switch those options on. |
When giving transfer approval to a contract, the current CEP-78 implementation requires the token owner to provide the contract's version hash versus its package hash. The problem is that if the approved contract is upgraded then its version hash will change & token owners will need to re-approve the contract.
get_verified_caller appears to be the source of this issue.
The text was updated successfully, but these errors were encountered: