EIP logoEIPs for Designers
Skip to content
EIP logoEIPs for Designers
Navigate
HomeBy ProblemBy JourneyAll StandardsUse with AI
Links
Official EIP SpecsMonadMonad FoundationAboutContactPrivacy
System
137 StandardsUpdated 8 Sept 2026

Built by the Monad Foundation.

By ProblemBy Journey
Home/By Journey/Stage 10
10

Specialized Interactions

Physical items, AI, social, gaming

17 standards at this stage·Covers 8 categories
Final

Adopted standard, safe to implement

Last Call

Final review period before adoption

Review

Widely deployed but not yet Final

Draft

Early stage proposal, may change

Active

Live on Monad mainnet

Proposed

Under consideration for Monad

Session

Consumable Interface

Ethereum
ERC-2135FinalAccepted and stable

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). Design implications: show clear 'consumable' badge on eligible NFTs, design prominent 'Use/Redeem' button, display consumption history and remaining uses, show who can consume (owner vs delegated consumer). Design decisions: whether consumption is reversible (affects undo UI), how to visualize partially consumed multi-use tokens, confirmation flow strength for irreversible consumption, showing consumed tokens in wallet (grayed out vs hidden).

Category: Gaming & Composability

Session

Consumable NFT Extension

Ethereum
ERC-4400FinalAccepted and stable

Users can assign a 'consumer' to their NFT who can use it without owning it — like lending your metaverse land to a builder while keeping ownership. Design implications: show separate 'owner' and 'consumer' roles on NFT detail pages, design 'Assign Consumer' action distinct from transfer, display consumer address/ENS with clear role label, show 'You are consumer' vs 'You are owner' states. Design decisions: whether to show consumer history, how to handle consumer permissions expiration (if implemented), UX for revoking consumer access, visualizing the owner-consumer relationship in collection views.

Category: Gaming & Composability

Verify request

NFTs Tied to Physical Assets

Ethereum
ERC-4519FinalAccepted and stable

Users own NFTs cryptographically tied to physical IoT devices — the device itself has an Ethereum address and must authenticate with the owner before it can be used. Design implications: show device authentication status (waitingForOwner → engagedWithOwner → engagedWithUser), design pairing flow UI, display physical asset address alongside owner address, show timeout warnings if device hasn't checked in. Design decisions: how technical to make the key exchange UI, whether to visualize the mutual authentication handshake, handling authentication failures gracefully, UX for transferring ownership (requires re-authentication).

Category: Physical & Real World

Link item

Web3 URL to EVM Call

Ethereum
ERC-4804FinalAccepted and stable

Access blockchain data via URLs like 'web3://uniswap.eth/swap' — browsers can render on-chain content directly. Design implications: support web3:// URL scheme in address bars, display on-chain HTML/SVG content natively, show ENS-based URLs alongside traditional links, handle cross-chain URLs with chainid syntax. Design decisions: security model for executing on-chain content, how to display web3:// URLs to users unfamiliar with the concept, fallback when content fails to load, gateway vs native resolution.

Category: Comprehension & Display

Review request

Client Script URI (TokenScript)

Ethereum
EIP-5169FinalAccepted and stable

Tokens can link to official scripts/mini-dapps — wallets auto-discover functionality like 'Mint', 'Stake', or smart-lock controls. Design implications: fetch and display scriptURI-linked functionality, show available token actions dynamically, indicate script authenticity/source, sandbox script execution. Design decisions: trust model for token-linked scripts (massive security surface), user consent before running scripts, how to present discovered functionality vs built-in features, handling script updates/versioning.

Category: Comprehension & Display

Link item

Contract Resource Requests

Ethereum
ERC-5219FinalAccepted and stable

Smart contracts serve web content directly — fully decentralized frontends without centralized hosting. Design implications: render contract-served HTML/CSS/JS in app frames, show content source (contract address), handle HTTP-like status codes and redirects from contracts. Design decisions: sandboxing/security for contract-served content, performance expectations vs traditional hosting, how to indicate decentralized vs centralized content to users, caching strategies for immutable content.

Category: Comprehension & Display

Collection

NFT Hyperlink Extension

Ethereum
ERC-5489FinalAccepted and stable

NFTs have authorized hyperlink slots — owners grant addresses permission to set links on their tokens. Design implications: show attached hyperlinks on NFT display, indicate slot authorization status, design slot management UI (authorize/revoke addresses), display link metadata (icon, description, target). Design decisions: how prominently to show attached links (ad-like), trust indicators for link destinations, multiple slots management complexity, authorization flow UX.

Category: NFT Capabilities

Link item

Digital Receipt NFTs

Ethereum
ERC-5570FinalAccepted and stable

Users receive NFT receipts for purchases containing structured transaction data — vendor info, line items, prices, tax, serial numbers — all on-chain and parseable by financial software. Design implications: render receipt metadata as formatted document view, show vendor branding (logo, contact), display itemized list with quantities/prices/tax, provide print/export functionality, show digital signature verification. Design decisions: how receipt-like vs NFT-like to make the display, handling PII privacy (encryption indicators), whether to integrate with accounting software exports, mobile-friendly receipt viewing.

Category: Physical & Real World

Collection

Public NFT Emote Repository

Ethereum
ERC-6381FinalAccepted and stable

Users can react to any NFT with emoji (like social media reactions) — reactions are stored on-chain in a public repository, enabling social signals around NFT value and desirability. Design implications: show emoji reaction counts on NFT cards, design emoji picker for reacting, display top reactions and total counts, show 'you reacted' state for user's own reactions, enable bulk reactions across multiple NFTs. Design decisions: which emojis to feature prominently, whether to show who reacted (privacy vs transparency), handling presigned reactions for gasless UX, reaction count display (exact vs abbreviated), emoji display consistency across platforms.

Category: Social & Messaging

Link item

Multi-redeemable NFTs

Ethereum
ERC-6672FinalAccepted and stable

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. Design implications: show list of available redemptions per NFT with status (available/redeemed/shipping), display operator-specific redemption flows, design redemption history view, show which campaigns/operators have active redemptions. Design decisions: how to organize multiple redemptions visually, whether to show redemption status progression (redeemed → paid → shipping), handling operator-specific metadata display, UX for discovering new redemption opportunities.

Category: Physical & Real World

Agent task

Verifiable AI-Generated Content Token

Ethereum
ERC-7007DraftEarly stage proposal

AI-generated NFTs include cryptographic proof linking output to specific model and prompt — verifiable provenance for AI art. Design implications: show 'AI-Generated' label with model info, display original prompt, add 'Verify Proof' button. Design decisions: how prominent to make AI disclosure — regulatory requirements vs aesthetic concerns, whether to filter/highlight AI content separately.

Category: Security & Trust

Reactions

Public NFT Emote Repository V2

Ethereum
ERC-7409FinalAccepted and stable

Users can react to any NFT with full Unicode emoji support including skin tones and variations — supersedes ERC-6381 with string-based emoji encoding for future compatibility. Design implications: same as ERC-6381 but with full emoji picker including skin tone variants, handle variable-length emoji rendering, show diverse emoji options. Design decisions: whether to group emoji variants or show individually, handling emoji that render differently across devices, search/filter in expanded emoji set, backwards compatibility display for collections using both standards.

Category: Social & Messaging

Reactions

Prevent Ticket Touting

Ethereum
ERC-7439DraftEarly stage proposal

Event tickets can only be transferred through authorized resellers — prevents scalping, enables price caps on secondary sales. Design implications: show 'Official Resale Only' indicator, direct to authorized resale channels, display ticket status (Sold/Resell/Void/Redeemed). Design decisions: how to handle unauthorized transfer attempts — educational messaging about why blocked, clear path to legitimate resale options.

Category: Security & Trust

Link item

Physical Asset Redemption

Ethereum
ERC-7578FinalAccepted and stable

Users holding physical-asset-backed NFTs can see verified real-world details: who issued it, who holds the physical item, where it's stored, legal terms, and declared value. Design implications: display token issuer, asset holder, storage location as structured fields, link to legal terms (IPFS), show jurisdiction and declared value prominently, design verification badges for issuer reputation. Design decisions: how much legal info to surface upfront vs expandable sections, whether to show issuer verification status, formatting currency/value display, handling missing optional fields gracefully.

Category: Physical & Real World

Collection

Secure Messaging Protocol

Ethereum
ERC-7627DraftEarly stage proposal

End-to-end encrypted messaging between wallet addresses — private on-chain communication with session support. Design implications: show encryption status indicator, display message history by session, add public key registration flow. Design decisions: key management UX — how to handle key rotation, session organization, balance security (key expiry) with convenience (persistent conversations).

Category: Identity & Privacy

Collection

AI Agents NFT with Private Metadata

Ethereum
ERC-7857DraftEarly stage proposal

Users own AI agent NFTs where the valuable data (model weights, memory, personality) is private and encrypted — transferring the NFT securely transfers the encrypted agent data with verified handoff. Design implications: show agent capabilities/description publicly, indicate private metadata exists without revealing it, design secure transfer flow with proof verification, display data ownership proofs, show authorized users who can run the agent. Design decisions: how to visualize TEE vs ZKP verification status, UX for cloning agents (vs full transfer), managing authorized users list, handling transfer failures in proof verification, showing sealed key delivery status.

Category: AI & Agents

Agent task

Agent Coordination Framework

Ethereum
ERC-8001DraftEarly stage proposal

Users (or their AI agents) coordinate multi-party actions on-chain — an initiator proposes an intent, all required participants sign acceptances, then the coordinated action executes atomically. Design implications: show coordination status flow (Proposed → Ready → Executed), display participant list with acceptance status checkmarks, show intent expiry countdown, design acceptance signing flow for participants. Design decisions: how to present coordination to non-technical users, visualizing multi-party consent gathering, handling partial acceptance states, showing coordination type/purpose clearly, timeout and cancellation flows.

Category: AI & Agents

Previous
Asset Management
Next
Infrastructure