ERC1155 uri function doesn't use the tokenID?

Which is the point on having a uri method that recieves an id as parameter, but cause of id substitution mechanism it doesn’t makes absolutely anything with it??

     * @dev See {IERC1155MetadataURI-uri}.
     * This implementation returns the same URI for *all* token types. It relies
     * on the token type ID substitution mechanism
     *[defined in the EIP].
     * Clients calling this function must replace the `\{id\}` substring with the
     * actual token type ID.
    function uri(uint256) external view override returns (string memory) {
        return _uri;

Seems like uri should be just a single getter method without any parameter as the uri is the same for all token ids. What’s more, this also allows for having a setUri public method (with access control) and changing the base of all token types base URL or endpoint, so I like having a single uri for the entire contract

Finally, is another method that needs to be called forcefully with an argument with no practical reason. Similar case as _data argument when executing mint funtion on erc1155 too. Those arguments coud be usefull if we modify the implementation, but as default they just creates confution.

My doubt could be expressed also in this way: if uri method is already expecting id as an argument, then why the standard doesn’t implement id substitution onchain? which is the advantage of having such a important behavior relying on each client? It could be arguable that this kind of delegation forces clients to know too much about erc1155 internals and provides no much improvements in return.

1 Like

Hi @rtraba,

The uri function is defined in the EIP in an optional metadata extension

function uri(uint256 _id) external view returns (string memory);


Which is why it must take a tokenID parameter to be compliant with the EIP.

The OpenZeppelin Contracts ERC1155 implementation only supports a single URI for the entire contract, and contract deployers can make use of the client {id} substitution.

A different implementation could have a URI per token, e.g. using a mapping to obtain the URI for each tokenID.

The differences you are seeing is the OpenZeppelin Contracts implementation complying with the EIP.

String manipulation onchain is limited and can be expensive in terms of gas.

It reduces the gas cost, as a single URI can be used for the entire contract, reducing the amount of storage required.

A different implementation could have a URI per token, e.g. using a mapping to obtain the URI for each tokenID.

However right now it’s not possible to extend OpenZeppelin implementation and override uri(uint256) to be able to achieve this.

Extending @openzeppelin/contracts/token/ERC1155/ERC1155.sol and trying to override uri(uint256 _id) throws a compilation Error:
TypeError: Trying to override non-virtual function. Did you forget to add "virtual"?

Is this the expected behavior? Shouldn’t OpenZeppelin implementation let us change the default behavior of one uri per contract? It seems counter productive to have to create a copy of the OZ ERC1155 implementation just to be able to have one uri per TokenID, when adding one virtual to the implementation would make this more flexible

1 Like

Hi @dievardump,

This is the current behavior. There is an open issue (and discussion) to make functions such as uri virtual. You can add your use case to the issue, along with any other functions that you would need made virtual.