1 - there is not a ‘getOperator’ function, what is the reason of it’s removal?
2 - Would you be willing to treat tokenId as bytes32 instead of uint256? this was always a pet peeve I had with ERC721 and ERC1155. The bad side would be less backwards compatibility.
ps: it is not good to copy the whole proposal here because it can get outdated compared to the one in github
It looks like OpenSea supports either the EIP-4906MetadataUpdate(uint256) and BatchMetadataUpdate(uint256,uint256) events or the EIP-1155URI(uint256) event.
The metadata extension currently doesn’t specify a URI update event, but I would favor URI(uint256) since the spec is close to EIP-1155 as-is.
Not many reasons to change from uint256 to bytes32 tbh, I just with the original protocols used bytes32 because it makes more sense as identifiers. Totally agree with you in keeping the compatibility.
Another thing that just came to my mint, Neither ERC20 nor ERC1155 required decimals to be implemented. Was this change intentional?
Just noticed ERC-20 requires it only in the metadata extension, but ERC-1155 only mentions it in the metadata spec.
I think it would make sense to require the decimals method in the metadata extension since it defaults to one (10 ** 0), so there’s no harm in implementing the method and not explicitly setting decimals for each token id.
This is great, strong support for the idea of getting the bloat out of 1155.
I don’t love that decimals “SHOULD be ignored if not explicitly set to a non-zero value.” It’s not clear when decimals for each ID will be set, but seems likely to cause downstream problems that non-existent IDs will simply return 0, which could be used to creatively break share accounting.
I would recommend that either:
a) decimals is a consistent value across all ids on a given contract
b) the decimals mapping isn’t public, and instead uses a getter function that reverts if it’s set to zero
I like the idea of removing “SHOULD be ignored …” terminology, though I would argue against solution “a” since this may be used to wrap multiple assets of varying decimal amounts and “b” because this would require contracts to use try/catch syntax for a view method on chain. The tokenURI being fallible is a product of ERC-721’s behavior, though decimals are more often queried on-chain than token uri’s.
Also, even if the decimals should never be ignored, querying decimals for an asset that have not been explicitly set will yield zero, which resolves to n * 10 ** 0 or n * 1.
Really like this standard, and appreciate the usage of YAML definitions
My one comment is that the token URI functionality should be a separate extension from the regular token metadata, for cases where it makes sense to define normal metadata (e.g. Give the the token a name, symbol and decimals) but not URI metadata (because the different IDs represent something semi-fungible such as tokens with different classes of rights or a progressive unlock)
it is very simple, just comment in the link above that you want to include your EIP for dicussion at the next meeting and say the EIP number and the PR number
