Making failures machine-readable
A token transaction can fail because a balance is insufficient, an allowance is too small, an address is invalid, or a token does not exist. ERC-6093 defines custom errors and structured parameters for common cases. This gives wallets and applications a more consistent way to explain a failed transaction than guessing from arbitrary text strings. It supplements token interfaces rather than replacing the rules that determine whether a transfer or approval is allowed.
2 sources for this section
A useful error example
Suppose an application requests a transfer of 50 units but the owner has authorized its spender for only 20. A structured insufficient-allowance error can identify the spender, available allowance, and required amount. The interface can then explain the mismatch without implying that the owner's overall balance is too low. Amounts are still encoded in the token's base units, so the application must apply the correct decimals before showing a human-readable explanation.
2 sources for this section
Decoding is not verification of honesty
Older contracts may return different custom errors, text, no data, or unexpected values. ERC-6093 does not force existing immutable contracts to upgrade, and it does not dictate every condition under which an implementation must revert. A malicious contract can also emit a plausible error. Consumers should handle unknown failures safely and avoid treating a standardized message as proof that a token is legitimate. The standard improves interoperability; it is not an audit or an anti-fraud certification.
1 source for this section
The source notesEvidence & further reading2 sources
- ERC-6093: Custom errors for tokens Ethereum Improvement Proposals · Primary source · accessed 2026-09-21
- ERC-20: Token standard Ethereum Improvement Proposals · Primary source · accessed 2026-09-21