Asset Discovery & Display

ERC-20 defines a common interface for fungible token balances, transfers, and approvals. A client can integrate a token through these functions, but metadata methods, return values, fee behavior, and compatibility depend on the deployed contract.

Category: DeFi Patterns

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.

Category: Comprehension & 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.

Category: Comprehension & Display

ERC-721 defines non-fungible tokens (NFTs). Unlike ERC-20 where every token is identical, each ERC-721 token has a unique ID. This enables digital art, collectibles, game items, membership passes, and anything where each item is distinct. It specifies ownership, transfers, approvals, and an optional metadata extension — the foundation of the NFT ecosystem.

Category: NFT Capabilities

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.

Category: Comprehension & 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.

Category: Comprehension & Display

ERC-1155 defines balances by account and token ID, allowing one contract to represent fungible quantities and unique items. Its batch transfer moves multiple IDs and amounts to one recipient in a transaction. Clients still need receiver handling, metadata and indexing support; actual fees depend on the transaction and network.

Category: NFT Capabilities

ERC-3525 creates "semi-fungible tokens" - NFT-like positions with both an ID (uniqueness) and a value (quantity). This can model bonds, invoices, DeFi positions, and structured products where unique tokens also represent amounts.

Category: DeFi Patterns

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.

Category: Comprehension & Display

ERC-4906 is an optional metadata update extension. Its MetadataUpdate and BatchMetadataUpdate events signal JSON metadata changes so indexers can refresh, while collections without the extension still need a fallback refresh policy.

Category: NFT Capabilities

NFTs have authorized hyperlink slots — owners grant addresses permission to set links on their tokens.

Category: NFT Capabilities

NFTs can reference other NFTs — creating a directed graph of relationships (remixes, derivatives, citations).

Category: NFT Capabilities

NFTs have multiple assets (files) — different outputs based on context (PDF for readers, 3D for games, image for marketplaces).

Category: NFT Capabilities

Filesystem-like hierarchical NFTs — tokens have parent/child relationships like folders and files.

Category: NFT Capabilities

Streamlined multi-token with granular per-token-type approvals and no mandatory callbacks — simpler than ERC-1155.

Category: NFT Capabilities

EIP-7251 raises Ethereum's validator maximum effective balance to 2048 ETH while keeping the 32 ETH minimum activation balance. Validators with a 0x02 compounding withdrawal credential can earn rewards above 32 ETH, top up in flexible amounts, and participate in consolidation flows; the credential, validator state, queues, and network activation determine which controls are available.

Category: DeFi Patterns

ERC-7401 is the Final successor to ERC-6059 for parent-governed NFT nesting. It preserves the nesting model while correcting the interface identifier; compatible collections can expose accepted and pending children, and products should verify the target implementation before promising transfer or extraction behavior.

Category: NFT Capabilities

ERC-7631 links an ERC-20 base and ERC-721 mirror pair and standardizes how the relationship is queried. Synchronization, minting, ratios, and transfer policy remain implementation-specific; optional skip-NFT methods may be unavailable.

Category: NFT Capabilities

ERC-7818 adds expiration timestamps to ERC-20 token batches. Applications can show when each batch expires and apply the deployed contract's transfer and spending rules; FIFO selection and burn/recycle behavior are optional implementation choices.

Category: DeFi Patterns

ERC-7943 defines uRWA interfaces for transfer eligibility, frozen balances, and privileged enforcement actions across ERC-20, ERC-721, ERC-1155, and ERC-6909 assets. Concrete implementations such as CMTA's CMTAT-ACE integration expose these controls, but the standard does not define a universal compliance policy, legal reason, authority, or wallet UI; applications must feature-detect the base and uRWA interfaces and show the actual contract policy.

Category: Physical & Real World

MIP-4 adds a precompile at 0x1001 with dippedIntoReserve(), which returns an ABI-encoded bool describing whether the current execution state has dipped into reserve across all accounts touched by the transaction. It is an in-execution contract check, not a reserve-amount query or a wallet preflight for an arbitrary unsigned transaction.

Category: Transaction Friction

ERC-5114 defines an immutable soulbound badge binding to a specific NFT and content-addressable badge metadata. It does not define an issuer registry, revocation function, identity verification, or validity status; show those as separate issuer or application policy when present.

Category: Identity & Privacy

ERC-6551 defines a registry that computes deterministic token-bound account addresses for NFTs and can deploy them as smart-contract accounts. A deployed or counterfactual account can hold assets, but each NFT may have multiple accounts across implementations, registries, chains, and salts; sale contents must be rechecked at settlement.

Category: NFT Capabilities

ERC-7811 defines wallet_getAssets for a wallet to report an account's assets, grouped by EIP-155 chain ID with optional filters. An application may build a cross-chain portfolio or net-worth view from those reports, but valuation, aggregation, stale-data policy, and bridged-asset deduplication remain application responsibilities.

Category: Cross-Chain

Monad's Reserve Balance mechanism coordinates consensus-time inflight gas budgets with execution-time ending-balance checks. The current system parameter is user_reserve_balance = 10 MON, but outcomes depend on lagged and starting balances, gas and value spend, delegation, recent activity, and emptying eligibility. It is not a universal balance-minus-10-MON formula or an upfront deposit.

Category: Transaction Friction