Membuka halaman seterusnya.
Memaparkan bab seterusnya…
Psst… sesuaikan cara membaca Anda.
Fon dan tema tersedia di Tampilan. Keselesaan mata anda juga penting.
Memaparkan bab seterusnya…
A standard vocabulary of custom error types for common ERC-20, ERC-721, and ERC-1155 token failures.
Menyemak sokongan bacaan suara pada pelayar ini…
Bacaan ini kini tersedia dalam bahasa Inggeris. Antara muka menggunakan bahasa pilihan anda.
Baca teks asal bahasa Inggeris →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.