Specialized Interactions

Users hold NFT tickets/passes that can be 'used' or 'consumed' — once consumed, the token is burned or marked used (like tearing a concert ticket).

Category: Gaming & Composability

ERC-4400 records a consumer identity for an NFT without changing ownership. The consumer is not automatically an owner, operator, or approved transfer address; the consuming app defines which actions, if any, that role permits.

Category: Gaming & Composability

ERC-4519 links an NFT to a physical asset address and defines mutual authentication with the owner or user. It does not require NFC or another particular transport; the implementation chooses the channel, key provisioning, and trust process for physical collectibles, devices, and other assets.

Category: Physical & Real World

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.

Category: Comprehension & Display

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.

Category: Comprehension & Display

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.

Category: Comprehension & Display

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

Category: NFT Capabilities

Users receive NFT receipts for purchases containing a structured JSON schema for vendor info, line items, prices, tax, and serial numbers. The NFT ownership and metadata URI are on-chain references; receipt JSON may live off-chain and should expose its source and availability.

Category: Physical & Real World

Users can redeem the same NFT for multiple different perks across different campaigns — a concert ticket NFT might be redeemable for entry, merchandise, and a meet-and-greet separately.

Category: Physical & Real World

ERC-7007 extends ERC-721 with AIGC data and verification interfaces. addAigcData binds prompt, aigcData, and proof to a token, while verify checks the combination through a chosen zkML or opML verifier. Model commitments, prompt confidentiality, proof storage, and creator disclosures depend on the implementation and storage design.

Category: Security & Trust

ERC-7409 is the Final successor to ERC-6381 for public NFT emotes, using string-based emoji encoding that supports multi-codepoint and skin-tone variants. Existing ERC-6381 collections may remain usable; new integrations should prefer ERC-7409 and show wallet activity separately from unique-human sentiment.

Category: Social & Messaging

ERC-7439 extends ERC-721 with ticket status, signature, expiry, and role-gated state changes intended to restrict transfers to authorized accounts. Its interface does not define ticket prices, resale caps, fees, reseller addresses, or a universal marketplace router; those policies must be read from the deployed implementation.

Category: Security & Trust

Users holding physical-asset-backed NFTs can inspect issuer-declared real-world details: who issued it, who holds the physical item, where it's stored, legal terms, and declared value. Verify those claims separately before presenting them as trusted.

Category: Physical & Real World

ERC-7627 defines encrypted on-chain messaging with public-key registration, algorithm metadata, session IDs, and message events. It provides updatePublicKey, sendMessage, and getUserPublicKey; key derivation, private-key recovery, inbox enumeration, and event indexing remain integration responsibilities.

Category: Identity & Privacy

ERC-7857 defines private metadata and proof-based data operations for AI-agent assets. It does not inherit ERC-721, although an implementation may add ERC-721; actual functional data stays off-chain while hashes and sealed keys can be on-chain. Transfer, cloning, and usage authorization use verifier proofs and may involve a sealed executor, so access is not automatically owner-only and ERC-8001 integration is separate.

Category: AI & Agents

ERC-8001 defines a coordination lifecycle in which an initiator proposes an intent, participants accept, and a ready coordination may be executed or cancelled. Execution data is opaque to the coordination interface and returns success/result; the standard does not guarantee atomic effects. Expiry becomes a status, but cancellation still requires an explicit cancelCoordination transaction.

Category: AI & Agents