Closed fyrchik closed 1 month ago
Related to #1883. It'd be nice for SupportedStandards
to have some meaningful interpretation, a contract specifying "NEP-11" there could actually mean any of the three interfaces mentioned above (or combination of them), so some kind of convention is needed for various subsets of standards (that should probably also be specified in NEPs, like "contract implementing non-divisible NFT interface SHOULD specify NEP-11/Non-divisible
in its SupportedStandards
).
Divisible NFT Non-divisible NFT
They should be checked by calling decimal()
of the contract.
Method for receiving NEP-11 tokens
The receiver contract should not add NEP-11
to its manifest. We can check whether a contract contains the onNEP11Payment
method to determine whether it supports receiving NEP-11 assets.
They should be checked by calling decimal() of the contract.
It's easy for a node to do that (as in #1883), but can be non-trivial for compiler. Compiler is not supposed to execute the contract, yet it can (and in case of neo-go does) check for standard compliance.
We can check whether a contract contains the onNEP11Payment
This works, but at the same I think it can be useful to have this specified in SupportedStandards
.
Compilers don't care about SupportedStandards
. They should use the abi of the contract.
I doubt we'll ever solve divisible/non-divisible (at least if we're not replacing NEP-11), but we are much better now with receiver methods defined in NEP-26 and NEP-27, so closing this one.
Summary or problem description Currently
supportedStandards
field in manifest specifies standards which manifest supports. However, for example, NFT PR https://github.com/neo-project/proposals/pull/130/files actually defines 3 interfaces:Do you have any solution you want to propose? Be more specific (may be change
supportedStandards
tosupportedInterfaces
). Something likeNEP-11/Divisible
orNEP-11/Payable
etc. This way it is more descriptive and checks can be easily enforced during compilation or contract deployment.Neo Version