Asset Management

Atomic Swap Contract

Users perform trustless cross-party token swaps using HTLC-based atomic swaps — also functions as American Call Options. Design implications: show swap timeline with initiate/participate/redeem/refund stages, display timelock countdowns for each phase, show premium amount for option-like behavior, guide through the multi-step swap process. Design decisions: how to communicate the optionality risk to counterparty, representing the secret/secretHash mechanism simply, whether to frame as 'swap' or 'option' based on use case.

Category: DeFi Patterns

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.

Category: NFT Capabilities

Abstract Storage Bonds

Users hold complex bond instruments with multiple classes and nonces — each representing different maturity conditions and metadata. Design implications: display bond class/nonce hierarchy, show maturity conditions per bond series, implement batch operations UI for efficiency, display on-chain metadata (coupon rates, redemption conditions). Design decisions: how to simplify the class/nonce abstraction for retail users, whether to group by maturity date or class, representing the difference between issue and redeem actions.

Category: DeFi Patterns

T-REX (Regulated Exchanges)

Security tokens enforce compliance at transfer — only verified investors can hold, automatic checks against regulations. Design implications: show verification status prominently, guide through KYC/identity verification, display transfer eligibility before attempting. Design decisions: how to handle failed compliance checks — educational messaging, clear next steps for verification, balance regulatory requirements with user frustration.

Category: Identity & Privacy

Tokenized Vaults

Users deposit assets into yield-generating vaults and receive shares representing their proportional ownership — standardized DeFi yield. Design implications: show both share balance AND underlying asset value side-by-side, display real-time APY/yield earned, use previewDeposit/previewRedeem to show exact conversion rates before transactions, indicate deposit/withdrawal limits via maxDeposit/maxWithdraw, show fees transparently (entry/exit/management). Design decisions: whether to default UI to 'assets' or 'shares' view, how to represent slippage between preview and actual execution, whether to show historical yield vs projected yield, handling vaults with transfer restrictions.

Category: DeFi Patterns

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.

Category: NFT Capabilities

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.

Category: NFT Capabilities

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.

Category: NFT Capabilities

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.

Category: NFT Capabilities

Soulbound Badge

Badges bound to other NFTs (not wallets) — achievements tied to your PFP, credentials attached to identity NFT. Design implications: show badge hierarchy (which NFT owns which badges), display nested ownership, indicate badge permanence. Design decisions: how deep to visualize badge chains — could be complex graphs, need to handle loops, balance completeness with comprehension.

Category: Identity & Privacy

Minimal Soulbound NFTs

Tokens marked as 'locked' cannot be transferred — minimal soulbound implementation for credentials, memberships, achievements. Design implications: show 'Soulbound' or 'Non-transferable' badge, hide/disable transfer buttons, explain permanence clearly. Design decisions: whether to show soulbound tokens in trading contexts at all — filter out or display with clear 'Not for Sale' status.

Category: Identity & Privacy

Consensual Soulbound Tokens

Soulbound tokens require recipient consent before minting and have predetermined burn rules (issuer-only, owner-only, both, neither). Design implications: show consent flow before accepting SBT, display burn authority clearly, add 'Request Burn' action where applicable. Design decisions: how to present burn authority — affects user understanding of permanence, recovery options if keys lost.

Category: Identity & Privacy

Refundable Tokens

NFT/token purchases include refund windows like traditional e-commerce — buyers can return within deadline. Design implications: show 'Refundable until [date]' badge on listings, add 'Request Refund' button in owned items, display refund countdown timer. Design decisions: whether refund status affects resale UI — should refundable items show different on marketplaces, how to handle partial refund eligibility.

Category: Security & Trust

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.

Category: NFT Capabilities

Refundable Fungible Token

Token sales use escrow with built-in refund mechanism — funds locked until conditions met, buyers protected from rugpulls. Design implications: show escrow status (Funded/Running/Success/Failed), display refund eligibility, visualize lock period timeline. Design decisions: how much escrow complexity to expose — show full state machine or simplified status, balance transparency with cognitive load.

Category: Security & Trust

Transferable Vesting NFT

Users hold NFTs representing vesting schedules that can be traded — unlocking liquidity for locked tokens. Design implications: show vesting curve visualization (linear/cliff/exponential), display claimable vs locked amounts, add 'Claim' action for vested tokens, show vesting end date and total allocation, enable NFT transfer/listing while maintaining vesting data. Design decisions: pricing display for secondary markets (discount to fully-vested value), whether to show implied discount rate, how to communicate that buying a vesting NFT means inheriting the vesting schedule.

Category: DeFi Patterns

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.

Category: NFT Capabilities

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.

Category: NFT Capabilities

Guard of NFT/SBT

NFT owners can set a 'guard' address that controls transfers — enables anti-theft (cold wallet guard), lending collateral, SBT recovery. Design implications: show 'Protected by Guard' indicator, display guard expiry, add guard management UI for setting/removing. Design decisions: how to communicate transfer restrictions — warning when guard active, explain why transfer button disabled, guard vs owner permission clarity.

Category: Security & Trust

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.

Category: NFT Capabilities

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.

Category: NFT Capabilities

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.

Category: NFT Capabilities

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).

Category: NFT Capabilities

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.

Category: NFT Capabilities

Financial Bonds

Users hold traditional financial bonds on-chain with familiar terms — ISIN, coupon rate, maturity date, denomination, principal. Design implications: use familiar bond terminology (coupon, maturity, ISIN), display denomination-based minimum amounts, show coupon payment schedules, enable principal/interest tracking, support callable/puttable/convertible bond variants. Design decisions: whether to show yields in basis points or percentages, how to display accrued interest, representing cross-chain bond operations for multi-chain deployments.

Category: DeFi Patterns

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.

Category: NFT Capabilities

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.

Category: NFT Capabilities

Native Asset ERC-4626 Vault

Users can deposit native ETH directly into 4626-compatible vaults without wrapping to WETH first — simpler onboarding for liquid staking. Design implications: show ETH balance directly in vault deposit UI, use msg.value for deposits (no approval step needed), handle excess ETH refunds gracefully, display the special 0xEeee...EEeE address as 'ETH' not an address. Design decisions: whether to offer WETH alternative path, how to communicate the gas cost difference vs WETH vaults, handling the edge case where assets parameter may be ignored in favor of msg.value.

Category: DeFi Patterns

Asynchronous ERC-4626 Vaults

Users request deposits/withdrawals that process asynchronously over time — necessary for RWA, cross-chain, and illiquid strategies. Design implications: design three-state UI (Pending → Claimable → Claimed), show estimated wait times, display pending request status prominently, add 'Claim' button that appears when requests become claimable, remove instant preview quotes (previewDeposit/Redeem revert). Design decisions: whether to show queue position, how to communicate yield accrual during pending state, whether to allow request cancellation if protocol supports it, notification strategy for when claims become available.

Category: DeFi Patterns

Multi-Asset ERC-4626 Vaults

Users interact with vaults supporting multiple entry assets for the same share token — like LP tokens or multi-collateral vaults. Design implications: show asset selector dropdown for deposit, display all supported entry points with their respective rates, use share() method to show the common output token, implement vault() lookup on share token for discovery. Design decisions: whether to recommend optimal entry asset based on rates/liquidity, how to represent the relationship between multiple vault contracts and single share token, handling different deposit limits per asset.

Category: DeFi Patterns

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).

Category: NFT Capabilities

Expirable ERC-20

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.

Category: DeFi Patterns

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.

Category: NFT Capabilities

Purpose Bound Money

Users receive tokens locked until multiple conditions are met — time, KYC, whitelist, or custom requirements. Design implications: show all unlock conditions as a checklist, display which conditions are satisfied vs pending, show expiry date if set, indicate claim eligibility clearly, design condition-specific UI (KYC verification link, time countdown). Design decisions: how to handle partially-met conditions, whether to show locked funds in main balance or separate, progressive disclosure of complex condition requirements, notification when all conditions met.

Category: DeFi Patterns