Interpreting what you're being asked to do
Stable specification; check network and product support
Open for peer review; implementation support varies
Early proposal that may change
ERC-55 encodes a checksum in the capitalization of an EVM address. A client that validates the checksum can catch many accidental edits, although checksum-valid text is not proof that the recipient is correct and all-lowercase or all-uppercase input needs separate handling.
Category: Comprehension & Display
ERC-191 defines an envelope for signed data with a version byte and version-specific payload. It prevents a signed message from being parsed as a legacy transaction, but replay resistance and authorization safety still require domain/intent binding and application checks.
Category: Security & Trust
EIP-712 standardizes hashing and signing for typed structured data. A supporting wallet can render fields such as an amount, deadline, and verifying contract more readably than an opaque digest, but the EIP does not require every wallet to display fields or provide replay protection. The app and verifier must bind the message and enforce its own safety rules.
ERC-3668 defines a client lookup protocol in which a contract can return gateway URLs and a client can fetch offchain data, then submit the response for contract verification. This can make ENS or other records resolve through gateways, but clients still need support, privacy disclosure, timeout/retry handling, and a trust policy for the source.
ERC-5267 adds eip712Domain(), a contract interface that publishes the fields and values used by its EIP-712 signing domain. Compatible applications can retrieve and validate the domain before showing a typed-data request; the interface is optional and is not a safety, trust, replay, or wallet-rendering certificate.
ERC-6093 defines optional standard custom errors for ERC-20, ERC-721 and ERC-1155 contracts. A compatible error can help explain a failure, but unknown errors and ordinary revert strings remain possible. Treat decoded values as reported context and check the actual token, spender and state before suggesting another approval or transaction.
ERC-7751 standardizes wrapped errors so participating contracts can report nested failure context. Clients can display the reported layers in plain language, but the chain can be incomplete or inaccurate. Verify state or simulation evidence before asserting a root cause or offering a recovery transaction.
ERC-7930 defines a versioned, length-prefixed binary envelope for chain-specific account identifiers. Pair it with a human-readable companion such as ERC-7828 or a CAIP-350 display profile when showing chain context to users; the ERC-7930 wire format is not itself a user-facing prefix string.
Category: Cross-Chain
ERC-7730 defines JSON descriptors and context rules that compatible clients can use to format calldata, EIP-712 messages, and UserOperations into readable summaries. Descriptor distribution, registry curation, client support, and source trust remain separate; a descriptor match does not prove that an action or publisher is safe.
