Comprehension & Display

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.

Stages: Authentication & Identity, Reading & Understanding

ERC-137 defines the ENS registry and resolver model for looking up records such as an address for a registered name. A compatible client can resolve a name like alice.eth and show the resulting address, but registration, ownership, resolver support, network scope, and client display remain separate checks. A name does not make typos obvious or prove identity by itself.

Stages: Authentication & Identity, Asset Discovery & Display

ERC-181 provides reverse ENS records that suggest a name for an address. Before showing that name as identity, forward-resolve it and require it to match the original address on the intended network. If the lookup is missing, fails or mismatches, display the address instead.

Stages: Authentication & Identity, Asset Discovery & Display

EIP-695 defines the eth_chainId RPC method, which lets a provider report the chain ID used by the connected endpoint. A client can compare that value with its target network, while wallet support, endpoint trust, network names, and switching remain separate concerns.

Stages: Discovery & Connection, Status & Confirmation

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.

Stages: Authentication & Identity, Reading & Understanding

EIP-747 lets an app suggest an asset for a supporting wallet to track. A true wallet_watchAsset response acknowledges a valid request; it does not prove that a prompt appeared or that the token was added. Keep the token address and network visible, and let users check the wallet’s result.

Stages: Asset Discovery & Display

ERC-1046 lets a token publish a tokenURI for structured metadata. Supporting wallets can display names, descriptions and images from that document, with fallbacks when fields or the interface are missing. Contract-published metadata can still be false, stale or unsafe; it is not proof that a token is authentic.

Stages: Asset Discovery & Display

EIP-2124 defines compact fork identifiers for peer-to-peer node compatibility checks. Nodes cross-validate fork history and the next scheduled fork using the specified rules; different fork IDs can still be compatible while syncing. This is a node diagnostic signal, not an RPC network identity or cryptographic proof of a chain.

Stages: Status & Confirmation

EIP-2718 defines a typed transaction envelope: a type byte followed by a type-specific payload, plus a corresponding typed receipt envelope. Later specifications define each payload and signing rule. Clients may choose to show type-specific details, but EIP-2718 itself does not prescribe wallet UI or guarantee support for any particular type.

Stages: Status & Confirmation

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.

Stages: Asset Discovery & Display, Reading & Understanding

ERC-4804 defines web3:// URLs that compatible clients translate into read-only EVM calls. A client, extension or gateway must support the scheme and the target contract must expose an appropriate interface. The URL format alone does not provide native browser support, a universal resource-serving method or censorship-proof hosting.

Stages: Specialized Interactions

ERC-5169 lets token contracts publish script locations for compatible clients. The interface returns an array of URIs; it does not mandate TokenScript or universal wallet support. Clients must check authenticity, supported format and execution permissions before exposing script-driven actions.

Stages: Specialized Interactions

ERC-5219 defines an HTTP-like request interface for contract resources. Supporting clients pass a resource path and query parameters, then interpret the status, body and headers. A response can refer to off-chain resources, so contract hosting alone does not guarantee availability, browser compatibility or safe content.

Stages: Specialized Interactions

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.

Stages: Reading & Understanding

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.

Stages: Reading & Understanding

ERC-1191 is an opt-in variant of the ERC-55 address checksum that incorporates chain ID on adopting networks. It can catch some address-entry mistakes there. Ethereum and networks that have not adopted the variant continue to use ERC-55. A checksum does not identify the intended destination chain or replace explicit network selection.

Stages: Status & Confirmation

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.

Stages: Reading & Understanding, Approving & Permissioning

Current Monad documentation lists 300 ms blocks and a 600 ms full-finality protocol figure. Those figures describe block production and consensus, not end-to-end wallet or application completion. Show completion from the observed execution outcome and required block commitment; a speculative receipt can precede Finalized, while Verified is a later agreement on execution output.

Stages: Status & Confirmation