Erc1551 on opensea

Support Contracts
1

In the ERC1551 spec we are told:

" The uri can include the string {id} which clients must replace with the actual token ID, in lowercase hexadecimal (with no 0x prefix) and leading zero padded to 64 hex characters."

When I tried this (ie renamed uri files with the id changed to a 64 hex value without the 0x) opensea could not find the meta file. It worked fine when the files were just standard decimal Anyone else seeing this issue?

Also in this case is the 'client' mentioned if the definition above referring to the web3 app. So in this case its actually opensea. So when opensea asks for the URI from the contract it actually gets back https://baseuri/10.png and then it goes out to look for https://baseuri/0000...00a.png

Thanks

2

What does your contract look like? What URI value are you setting?

The "client" is OpenSea in this case, yes. When it asks for the URI, if you're using {id} it would get back some value like https://baseuri/{id}.json (note that this is a JSON file!), and it will then fetch for example https://baseuri/00...0a.png.

3

I have the standard public uri function in my erc15551 contract, which if called with "10" as a token id for example will return ipfs://baseUri/10.json. It test this in Remix. Nothing fancy there.

Now if I have a file loaded on the ipfs network as:
ipfs://baseUri/000000000000000000000000000000000000000000000000000000000000000a.json

then opensea will not find it. Rather it goes and looks for a file ipfs://baseUri/10.json.

I cant really explain it any other way. It suggest to me that opensea isn't doing the translation of return token decimal id to hex id

I am running on the polygon mumbai test net.

4

If your contract returns .../10.json then that's what OpenSea will go and fetch. There is no translation!

Maybe the {id} syntax has been confusing you, but ERC1155 allows you to set a URI like this: "https://example.com/{id}.json". If the URI contains the "{id}" substring, the client will replace that part of the string with the hex encoded id.

5

thanks for your help here and I am obviously missing something obvious but yes my contract returns like you say https://example.com/{id}.json so if I call the solidity function with argument of the token id I want the uri for, say 10, this it will return https://example.com/10.json. So yes typically you would expect the client to go and fetch that exact json but the erc1155 spec (and opensea) are telling us that this should be translated to the hex version and hence the fetch a filename with the hexName. And if that's not the case at what point is the id translated to hex?? Or is our solidity program function supposed to return the id already translated to hex? Not even sure how you would do that in solidity.

edit.....oh you mean it literally means your contract should return {id} and you shouldn't dynamically pass back the token number instead??

edit 2....no that still doesn't make sense. Having looked at the opensea docs they also guide you to use:

function tokenURI(uint256 _tokenId) public view returns (string) {
  return Strings.strConcat(
      baseTokenURI(),
      Strings.uint2str(_tokenId)
  );
}

....which is just how I am returning the my uri

6

Yes that's what I meant!

The OpenSea docs snippet you shared is about ERC721. But even for ERC1155, if you want you can choose to dynamically return a URI with the token number. The use of "{id}" is optional.

7

well I tried that and it still didn't seem to work. Have you actually done this? I am going to try it on the rinkby testnet, instead of matic on mumbai, to see if there is anything going on there and if that fails I am just moving forward in using the way that works. (upload files with normal decimal id numbers and returning a dynamic uri).