EIP-6093: Custom errors for commonly-used tokens

Hello community,

Since the introduction custom errors in Solidity in v0.8.4, there’s now a more expressive and gas-efficient way of reverting changes during a transaction.

Given this new addition, we’re proposing a list of standard errors to be used for the standard tokens (ERC20, ERC721, and ERC1155), so the clients and implementers can expect an insightful and structured way from a transaction error.

4 Likes

This is a very good initiative. For the curious out here, it will be interesting to have a reference of the bytecode savings for switching from old revert strings (for example in ERC20) to error messages.

In the Rationale section for domain; perhaps the contract name itself could be suggested to help with the compiler DeclarationError in situations where the ErrorPrefix and Subject are the same.

2 Likes

This is a very good initiative. For the curious out here, it will be interesting to have a reference of the bytecode savings for switching from old revert strings (for example in ERC20) to error messages.

Thanks for your comments! Actually, I just made a quick repo test for comparing the gas savings.

You can find them here.

Look at the differences between custom errors and short strings vs long strings, which are the majority of the cases

TLDR is that EIP-6093’s custom errors are better in gas usage than general revert strings unless for reverts with empty strings.

In the Rationale section for domain ; perhaps the contract name itself could be suggested to help with the compiler DeclarationError in situations where the ErrorPrefix and Subject are the same.

I see what you mean. Although it can solve the DeclarationError, it’ll also change the error selector depending on the contract name, and that might affect standardization overall (eg. Metamask would need to know the contract name just to calculate the selector and show a proper error message in the UI).

What do you think?

Very nice report on the gas savings.

In my opinion, the change to custom errors should become the norm on new deployments of these common token implementations.

Assuming this makes its way to an OpenZeppelin implementation, would this change be implemented directly in the existing token contracts, for instance: ERC20, or would it be within the ./extensions folder?

We aim to implement these changes in OpenZeppelin Contracts for the next 5.0 version, so yes, it’s expected to make into OZ’s ERC20 implementation.

Also, the same rationale is going to be used for other errors, see this discussion.

1 Like