Seeing tokens, NFTs, and balances
Adopted standard, safe to implement
Final review period before adoption
Widely deployed but not yet Final
Early stage proposal, may change
Live on Monad mainnet
Under consideration for Monad
Users experience token balances as simple numbers with transfer and approval mechanics — the foundation of all DeFi. Design implications: always show token symbol + decimals-adjusted balances, display allowance amounts before swap/stake actions, implement two-step approval flows (approve then execute) or use permit for gasless approvals, show pending approval transactions distinctly. Design decisions: whether to show infinite approvals as 'Unlimited' vs actual large number, whether to prompt users to revoke old approvals, how to handle the approve-to-zero-first pattern for tokens that require it.
Category: DeFi Patterns
Users can send to 'vitalik.eth' instead of '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045' — memorable names replace error-prone addresses. Design implications: always show ENS names where available, provide autocomplete for .eth names, display both name AND resolved address for verification, show avatar/profile data from ENS records, handle subdomains gracefully. Design decisions: when to show address vs name (trust tradeoff), how to handle unregistered/expired names, whether to require re-resolution before transactions, loading states for async resolution. 910K+ active domains. ENS is a primary solution to Sending to Wrong Address (Critical severity). Showing ENS names alongside addresses is High priority for safety UX.
Category: Comprehension & Display
Any wallet address can display a human name — '0xabc...' shows as 'alice.eth' in transaction histories and dashboards. Design implications: fetch reverse records for all displayed addresses, show names in activity feeds/transaction lists, display name in connected wallet UI, cache resolved names for performance. Design decisions: fallback display when no reverse record exists (truncated address vs full), handling mismatches between forward/reverse resolution (possible impersonation), refresh frequency for cached names.
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.
Category: NFT Capabilities
DApps prompt users to add tokens with one click — no manual contract address copying. Design implications: show token add prompt with icon/name/symbol preview, verify token against known lists before suggesting, display security warnings for suspicious tokens. Design decisions: permission model (always prompt vs remember preference), how to handle spam token add requests, verification level before showing token (metadata fetch vs trust dapp), blocking malicious token suggestions.
ERC-20 tokens get rich metadata like NFTs — icons, descriptions, and images without manual token list curation. Design implications: fetch and display token images/icons from tokenURI, show descriptions in token detail views, support interop field to identify token type, handle missing/broken metadata gracefully. Design decisions: trust level for fetched metadata (SSRF risks), caching strategy for metadata, fallback displays when tokenURI fails, whether to prefer on-chain name() or metadata name.
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.
Users hold tokens with both NFT-like uniqueness (ID) and fungible-like quantities (value) within slots — think financial instruments with face values. Design implications: display three properties: token ID, slot category, and value amount, enable partial value transfers between tokens of same slot, show value decimals properly, implement slot-based filtering/grouping in portfolio views. Design decisions: whether to visualize as NFT cards with value badges or as table rows, how to handle split/merge operations UX, representing slot compatibility for transfers.
Contracts fetch offchain data transparently — ENS names can resolve from L2s or external sources without users knowing. Design implications: show loading states during offchain lookups, indicate data source in advanced views (on-chain vs gateway), handle gateway failures gracefully with retries. Design decisions: which gateways to trust (security/privacy tradeoff), timeout handling for slow gateways, whether to show users that offchain lookup occurred, caching validated responses.
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.
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.
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.
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.
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.
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).
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.
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.
Users see their true net worth across all chains in a single view — no more manually switching networks to check balances. Design implications: aggregate balances across chains into a unified portfolio display, show per-chain breakdown on expand, handle loading states for multi-chain queries, display total value in fiat. Design decisions: whether to show chain badges on individual assets or group by chain, how to handle stale data from slow chains, real-time vs periodic refresh strategy, whether to show 'available on chain X' indicators for cross-chain actions. Multi-Chain Checklist rates this Critical priority — 'True net worth in one view.' Draft status, no implementations yet, but addresses the Single-Chain Balance Display pain point.
Category: Cross-Chain
Users hold tokens that expire after a validity period — for rewards, prepaid credits, or time-limited assets. Design implications: prominently show expiration date/countdown per token epoch, display both current-epoch and total usable balance, add 'expiring soon' warnings, enable epoch-specific transfers, gray out or hide expired balances. Design decisions: how aggressively to warn about upcoming expiration, whether to auto-hide expired epochs or show them struck-through, FIFO vs user-selected epoch for spending, notification timing for expiring tokens.
Pre-check if a transaction would fail before sending — apps can query spendable balance accounting for the 10 MON reserve. Design implications: show spendable vs total balance, disable send when amount exceeds spendable, pre-validate before wallet popup, explain reserve with clear tooltips. Design decisions: whether MAX subtracts reserve + gas automatically; how to surface pre-check failures without blocking power users.
Category: Transaction Friction
Every EOA must maintain a 10 MON reserve for async execution safety. Two-layer enforcement: consensus-time (inflight tx budget) and execution-time (revert if ending balance < reserve). Undelegated accounts get one emptying transaction per ~3 blocks that bypasses the reserve; delegated accounts (EIP-7702) cannot. Design implications: show spendable vs total balance, account for reserve in MAX buttons, detect delegation status for emptying tx eligibility, handle transactions that revert after block inclusion, warn when approaching reserve threshold. Design decisions: whether to surface emptying transaction option for sub-10-MON balances vs. simply prompting to add funds.
