DeFi Patterns

Token Standard

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.

Stages: Asset Discovery & Display

Transient Storage Opcodes

Transactions use cheaper temporary storage that persists only within the transaction — invisible to users but enables lower gas costs. Design implications: not directly user-facing, but enables cheaper reentrancy-protected swaps, lower gas estimates for complex multi-step transactions, simpler single-tx approval patterns. Design decisions: when to show gas savings from transient storage vs traditional storage, whether to surface this as a 'gas optimized' badge on protocols using it, no direct UI needed but affects gas estimation accuracy.

Stages: Gas & Fees

Flash Loans

Users (typically developers/arbitrageurs) borrow tokens with zero collateral, use them within a single transaction, then repay with fee — enabling complex DeFi strategies. Design implications: show maxFlashLoan available per token, display flashFee upfront, this is primarily a developer/power-user feature — most retail UIs won't expose it directly, but aggregators might use it under the hood. Design decisions: whether to expose flash loan functionality in consumer UI at all, how to explain the atomic single-transaction constraint, whether to show protocol's flash loan usage in transaction breakdowns.

Stages: Executing Transactions

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.

Stages: Asset Management

Semi-Fungible Token

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.

Stages: Asset Discovery & Display

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.

Stages: Asset Management

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.

Stages: Asset Management

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.

Stages: 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.

Stages: Asset Management

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.

Stages: Asset Management

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.

Stages: Asset Management

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.

Stages: Asset Management

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.

Stages: Asset Discovery & Display, Asset Management

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.

Stages: Asset Management