La page se tourne.
Le prochain chapitre arrive…
Psst… appropriez-vous votre lecture.
Polices et thèmes se trouvent dans Apparence. Vos yeux ont aussi leur mot à dire.
Le prochain chapitre arrive…
A standard vocabulary of custom error types for common ERC-20, ERC-721, and ERC-1155 token failures.
Vérification de la lecture vocale du navigateur…
Cette lecture est actuellement disponible en anglais. L’interface utilise la langue choisie.
Lire l’original anglais →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.
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.
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.