When Solidity v0.8.4 introduced the ability to define custom errors, developers gained a better way to handle transactions that revert. However, at present, there is no industry standard for defining the most common error messages such as InvalidSender or InsufficientBalance. Standardized errors allow users to expect a more consistent experience across applications or testing environments, while exposing pertinent arguments and overall reducing the need to store expensive revert strings in the deployment bytecode.
Given the value of standardized error messages for both users and developers, we have submitted EIP-6093, which proposes a list of standard errors to be used for the common token types (ERC-20, ERC-721, and ERC-1155).
This EIP seeks to improve developer experience because clearer error messages make it easier to catch errors and present them to the user. It’s an improvement for the end user for the very same reasons — in addition to the gas savings afforded by custom errors, standardized error messages mean users can know what to expect and how to interpret the messages that they see. Based on the success of this proposal, future versions of OpenZeppelin Contracts will feature custom Solidity errors.
The security implications of this EIP relate to clarity in errors and gas estimations. It also translates into better readability, less error-prone UIs and a more contextualized developer experience.
As stated in Solidity’s v0.8.4 release, the use of custom errors can reduce runtime and deployment costs. You can view sample benchmarks here comparing the cost of throwing an error with custom errors following the standard versus with traditional revert strings. The gas savings comes from the fact that the revert string is stored in the deployment bytecode, while in the case of a custom error, only the 4-bytes selector of the error is stored.
The main benefit behind standard error messages for the end user’s experience can be illustrated in the contrast between the following screenshots.
Here is what the user sees prior to the adoption of custom error messages:
This is not very helpful, and the user can’t be blamed for being unsure as to how they should proceed. But, it’s not the fault of the wallet provider. The capability simply wasn’t there.
The adoption of a standard allows developers to better account for the well-identified cases in which the common ERC tokens can fail, such as insufficient balance or trying to transfer an ERC-721 token to an address that cannot receive it.
Here is an example of what the user could see after the implementation of standard custom error messages:
For many years, OpenZeppelin has actively supported the ecosystem via the EIP process. We’d love to get feedback from the community about the usefulness and applicability of EIP-6093 so that we can explore ways to expand this convention to additional use cases where it can add value to the ecosystem.
If you’re a developer building your own dapp, metaverse, DeFi protocol, or other blockchain project be sure to check out our open-source contract libraries to securely scale your Web3 development.