You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At first glance, this reads like the function will return the URL with an alphanumeric hexadecimal string representation of the token ID (i.e., "hex format"), rather than a string representation of the integer, which is what _uint2str() does.
It uses the word "assumed" but whose assumption is this? The spec does allow clients to assume a lowercase alphanumeric hexadecimal representation of the token ID when the contracts returns an {id} placeholder, but that's not what is happening here.
The text was updated successfully, but these errors were encountered:
Good catch! Changed the comment to say integer instead of hex because of how the URIs are returned by that function, the _uint2str() does keep the integer format. To return hex format with this metadata contract implementation, one would need to implement something like a _uint2Hex2str() instead.
I think the documentation for the
ERC1155Metadata
contractsuri()
function is misleading:https://github.com/arcadeum/multi-token-standard/blob/36ebad2194d79f3cf510fcaa80738d61344ff9ab/contracts/tokens/ERC1155/ERC1155Metadata.sol#L23
At first glance, this reads like the function will return the URL with an alphanumeric hexadecimal string representation of the token ID (i.e., "hex format"), rather than a string representation of the integer, which is what
_uint2str()
does.It uses the word "assumed" but whose assumption is this? The spec does allow clients to assume a lowercase alphanumeric hexadecimal representation of the token ID when the contracts returns an
{id}
placeholder, but that's not what is happening here.The text was updated successfully, but these errors were encountered: