NFT Capabilities

Non-Fungible Token Standard

Each token is unique with distinct ownership — the foundation of all NFT UX. Design implications: show single-item detail views with ownership info and provenance history, display unique token IDs prominently, design 1:1 transfer flows (not quantity selectors), implement approval flows for marketplace listings with clear 'Approve' vs 'Approve All' distinction. Design decisions: balance between showing technical token IDs vs friendly names, whether to expose raw contract addresses or use ENS/profiles, how much provenance history to surface without overwhelming users.

Stages: Asset Discovery & Display

Multi Token Standard

Single contract holds multiple token types (fungible and non-fungible) with batch operations. Design implications: design inventory views supporting both unique items and stackable quantities, show quantity selectors for semi-fungible tokens, enable multi-select batch transfers to save gas, display mixed collections (1/1s alongside editions) coherently. Design decisions: how to visually differentiate unique vs edition tokens, whether batch operations should be default or advanced feature, balancing simplified UI against power-user batch capabilities.

Stages: Asset Discovery & Display

ERC-721 Consecutive Transfer Extension

Batch minting/transfer events — efficiently create or move thousands of consecutive tokens in one transaction. Design implications: show batch mint/transfer notifications (e.g., 'Received tokens #1-1000'), handle large collection imports without individual events, efficient indexing of mass distributions. Design decisions: how to display large batch receipts without overwhelming, progress indicators for indexing large transfers, summarizing vs listing individual tokens.

Stages: Executing Transactions

NFT Royalty Standard

Standardized royalty info — marketplaces can query royalty percentage and recipient for any NFT. Design implications: show royalty percentage on listings (e.g., '5% creator royalty'), display royalty recipient/creator info, calculate and preview royalty amount during purchase, indicate if marketplace honors royalties. Design decisions: whether to show royalties as percentage or absolute amount, how prominently to display (affects buyer decisions), handling marketplaces that don't enforce royalties.

Stages: Asset Management

NFT Metadata Update Extension

Standardized metadata update events — platforms know when to refresh NFT images/attributes. Design implications: implement real-time metadata refresh on update events, show 'Updated' indicators, handle batch metadata updates efficiently, display metadata version/history if tracked. Design decisions: how quickly to refresh after events, caching strategies, whether to notify users of updates to owned tokens, handling frequent updates without UI flicker.

Stages: Asset Discovery & Display

Rental NFT

NFTs have separate 'owner' and 'user' roles with automatic expiration — enabling trustless rentals. Design implications: display dual ownership badges (Owner vs User), show rental expiration countdown timers, design rental listing flows with duration pickers, indicate 'rented out' status on owned items, auto-update UI when rental expires without transaction. Design decisions: how prominently to show rental status vs ownership, whether to notify users before rental expiry, handling edge cases where user tries owner-only actions.

Stages: Approving & Permissioning, Asset Management

Royalty Bearing NFT

Hierarchical on-chain royalty distribution — derivative NFTs pay royalties up the ancestry chain automatically. Design implications: show royalty tree visualization (who gets paid from this sale), display ancestor relationships, indicate derivative status, show accumulated royalty earnings. Design decisions: complexity of showing multi-level royalty splits, whether to expose full royalty hierarchy or summarize, handling deep ancestry chains in UI.

Stages: Asset Management

Rental NFT for ERC-1155

Rental system for ERC-1155 tokens with quantity-based user records and expiration. Design implications: show 'usable balance' vs 'frozen balance' separately, display rental records with amount/expiry per record, enable partial quantity rentals, design rental management dashboards showing multiple active rentals. Design decisions: how to visualize frozen vs usable tokens in inventory, complexity of supporting multiple concurrent rental records, whether to auto-consolidate expired records.

Stages: Approving & Permissioning, Asset Management

Time NFT Extension

NFTs have built-in start and end times — tokens can be time-bounded or represent time periods. Design implications: show validity period badges ('Valid: Jan 1 - Dec 31'), gray out or hide expired tokens, display countdown to activation/expiration, support time-range visualization for event tickets or subscriptions. Design decisions: whether to completely hide invalid-period tokens or show them disabled, how to handle timezone display, whether to allow splitting/merging time-bounded tokens if composable extension used.

Stages: Asset Management

NFT Hyperlink Extension

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.

Stages: Asset Discovery & Display, Specialized Interactions

Referable NFT

NFTs can reference other NFTs — creating a directed graph of relationships (remixes, derivatives, citations). Design implications: show 'References' and 'Referenced By' lists, visualize reference graph/network, indicate derivative relationships, display creation timestamps for ordering. Design decisions: graph visualization complexity, how deep to show reference chains, handling cross-contract references, attribution/citation display format.

Stages: Asset Discovery & Display, Asset Management

Context-Dependent Multi-Asset Tokens

NFTs have multiple assets (files) — different outputs based on context (PDF for readers, 3D for games, image for marketplaces). Design implications: show asset selector/tabs per NFT, display context-appropriate asset automatically, indicate available formats, allow owner to reorder asset priority. Design decisions: auto-detection of context vs manual selection, how to preview multiple assets, handling asset acceptance (propose-commit pattern), storage of multiple asset versions.

Stages: Asset Discovery & Display

Parent-Governed Nestable NFTs

NFTs can own other NFTs in parent-child hierarchies — enabling bundling, delegation, and composability. Design implications: show nested tree views of NFT hierarchies, design 'pending child' acceptance flows (propose-commit pattern), visualize bundle contents expandable within parent, indicate 'nested inside' status. Design decisions: depth limit for hierarchy display, whether dragging NFTs into others is intuitive, how to handle cross-collection nesting, showing root owner vs immediate parent.

Stages: Asset Management

No Intermediary NFT Trading

Built-in marketplace functionality — list, buy, and sell NFTs directly from the contract without intermediary. Design implications: show 'List for Sale' directly in wallet UI, display listing price/expiry on owned tokens, enable direct purchase without marketplace approval, show benchmarkPrice for royalty calculation. Design decisions: whether to compete with external marketplaces in UI, simplicity of direct listing vs marketplace features, handling multiple payment tokens.

Stages: Asset Management

Hierarchical NFTs

Filesystem-like hierarchical NFTs — tokens have parent/child relationships like folders and files. Design implications: show folder tree navigation, display breadcrumb paths, enable create-under-parent flows, indicate root vs leaf tokens, show children count. Design decisions: max depth visualization, whether to support drag-drop reorganization, handling permission inheritance in hierarchy, folder vs file visual treatment.

Stages: Asset Discovery & Display, Asset Management

Composable NFTs with Equippable Parts

NFTs can equip other NFTs into defined slots using a Catalog system — true on-chain composability. Design implications: show equippable slots on NFTs (e.g., 'Weapon Slot: Empty'), design drag-drop equip interfaces, display composed NFT preview combining base + equipped assets, catalog browsing for compatible equipment. Design decisions: real-time vs on-save composition rendering, how to show slot compatibility constraints, inventory vs equipped views, handling unequip gas costs.

Stages: Asset Management

Minimal Transferable Detection

Tokens can be non-transferable (soulbound) or have transfer restrictions — verifiable on-chain. Design implications: show clear 'Non-Transferable' or 'Soulbound' badges, hide/disable transfer buttons for locked tokens, differentiate mintable vs burnable vs transferable states, display restriction reason if available. Design decisions: whether to show transfer button at all for soulbound tokens, how to explain why transfer fails, visual treatment of soulbound vs tradeable tokens in same wallet.

Stages: Asset Management

Minimal Multi-Token Interface

Streamlined multi-token with granular per-token-type approvals and no mandatory callbacks — simpler than ERC-1155. Design implications: show per-token-type allowance amounts (like ERC-20), remove batch transfer UI complexity if not needed, design approval UIs that distinguish 'approve specific amount' from 'operator access to all'. Design decisions: whether to expose the simpler approval model to users or abstract it, tradeoff between gas savings (no callbacks) vs safety checks that callbacks provided.

Stages: Asset Discovery & Display

Lockable Extension for ERC-721

NFTs can be locked in owner's wallet — usable but non-transferable until unlocked. Design implications: show 'Locked' status badge with locker address, enable lock/unlock flows with locker assignment, indicate locked tokens differently from transferable ones, show who can unlock. Design decisions: how to explain lock vs soulbound difference, whether locked tokens appear in marketplace listings, transferAndLock flow complexity, safety messaging about cold wallet as unlocker.

Stages: Asset Management

Parent-Governed NFT Nesting

Improved NFT nesting standard (supersedes ERC-6059) — NFTs own NFTs with parent-governed control. Design implications: same as ERC-6059 plus cleaner interfaces — tree visualizations, child acceptance flows, bundle management, transfer-with-children behavior. Design decisions: whether to show full ancestry path, how to indicate pending vs accepted children, UX for transferring parent (children follow automatically), visual hierarchy depth limits.

Stages: Asset Management

Non-Fungible Token Roles

Multiple custom roles (not just user/owner) can be assigned to NFTs with expiration and custom data. Design implications: display role badges per NFT (e.g., 'Manager', 'Tenant', 'Beneficiary'), show role assignment/revocation flows, visualize role hierarchies and permissions, design role marketplace for granting/revoking. Design decisions: how many roles to display before truncating, whether to show technical role IDs or friendly names, complexity of multi-role management UI vs simplified views.

Stages: Approving & Permissioning, Asset Management

Non-fungible Token Bound Accounts

NFTs have their own wallet addresses — tokens can own assets, sign messages, and interact with dApps. Design implications: show 'Token Bound Account' with address and contained assets, enable NFT-as-wallet interactions, display nested inventory inside NFT, indicate TBA-enabled tokens. Design decisions: how to visualize 'wallet inside NFT' concept, whether to expose TBA address or abstract it, complexity of NFT-initiated transactions, handling ownership transfers (assets follow NFT). 🟢 Widely deployed (tokenbound.org registry live).

Stages: Asset Discovery & Display, Asset Management

Dual Nature Token Pair

Paired ERC-20 and ERC-721 tokens that sync — buying fungible tokens auto-mints NFTs proportionally. Design implications: show linked token pairs together, indicate NFT skip status, display 'X tokens = Y NFTs' conversion ratio, toggle for skip-NFT preference. Design decisions: whether to surface the dual nature prominently or abstract it, explaining skip-NFT for gas savings vs collectibility, handling marketplace display of both representations.

Stages: Asset Discovery & Display

Limited Transfer Count NFT

NFTs have maximum transfer count — after N transfers, token becomes non-transferable or burns. Design implications: show 'Transfers Remaining: 3/5' counter prominently, warn before final transfer, indicate transfer-exhausted tokens, display transfer history count. Design decisions: whether to show transfer limit upfront during purchase, how alarming the 'last transfer' warning should be, treatment of exhausted tokens (greyed vs hidden vs special badge).

Stages: Asset Management

Expirable NFTs and SBTs

NFTs and SBTs have built-in expiration (block-based or time-based) — tokens become invalid automatically. Design implications: show expiration countdown prominently, display 'Expired' badge on invalid tokens, filter views by active/expired status, indicate expiry type (blocks vs timestamp). Design decisions: whether expired tokens remain visible or get hidden, renewal flow if supported, how to communicate 'expired but still owned' status, handling epoch-based batch expiration.

Stages: Asset Management