Đang lật trang.
Đang mở chương tiếp theo…
Này… tạo phong cách đọc riêng nhé.
Phông chữ và chủ đề nằm trong Giao diện. Hãy chọn điều dễ chịu cho mắt.
Đang mở chương tiếp theo…
A standard vocabulary of custom error types for common ERC-20, ERC-721, and ERC-1155 token failures.
Đang kiểm tra khả năng đọc thành tiếng của trình duyệt…
Bài đọc này hiện có bằng tiếng Anh. Giao diện sử dụng ngôn ngữ bạn đã chọn.
Đọc bản gốc tiếng Anh →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.