# EIP-7994: Purpose Bound Money Source: https://www.eipsfordesigners.com/standards/EIP-7994 Agent brief: https://www.eipsfordesigners.com/standards/EIP-7994/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-7994 Last reviewed: 2026-04-05 Last updated: 2026-04-05 | Field | Value | | --- | --- | | Status | Draft | | Chain | both | | Category | DeFi Patterns | | Journey stages | Asset Management | | Detailed guide | Yes | | Official specification | https://eips.ethereum.org/EIPS/eip-7994 | | Discussion search | https://ethereum-magicians.org/search?q=EIP-7994 | ## UX Impact 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. ## Summary EIP-7994 creates "purpose-bound money"—tokens that can only be spent at approved merchants or for specific purposes. Think corporate expense cards, food stamps, or student stipends as tokens. The issuer defines where and how tokens can be used, ensuring funds go exactly where intended. Perfect for grants, benefits programs, corporate expenses, and any scenario requiring spending restrictions. ## For Designers - You can design UI that delivers tokens only work at approved merchants/purposes. - You can design UI that delivers on-chain rules enforce spending limits and categories. - You can design UI that delivers smart contract enforces valid merchant list. ## Applicability ### When to Use - Your product addresses: no way to restrict how tokens are spent. - Your product addresses: corporate cards require centralized control. - The flow should deliver: tokens only work at approved merchants/purposes. - Connect flows must list wallets with names, icons, and explicit user choice. ### When to Avoid - Always show valid merchants/categories alongside balance. - Pre-check validity, disable payment button if invalid. - Highlight expiring tokens, send notifications. - No token balances, swaps, lending, or yield flows appear in the product. ## Problems It Solves ### No way to restrict how tokens are spent Impact: critical Old way: Send tokens, hope recipient uses them correctly New way: Tokens only work at approved merchants/purposes ### Corporate cards require centralized control Impact: high Old way: Visa/corporate card with bank managing restrictions New way: On-chain rules enforce spending limits and categories ### Benefits programs can't ensure proper use Impact: high Old way: Issue vouchers, verify manually, prone to fraud New way: Smart contract enforces valid merchant list ### Grants require trust or complex escrow Impact: medium Old way: Send grant money, request receipts, manual auditing New way: Tokens only spendable on approved categories ### Can't combine spending restrictions with expiry Impact: medium Old way: Separate systems for spend categories and time limits New way: Token encodes both: "Food only, expires Dec 31" ## Anti-Patterns ### Showing restricted tokens without explaining restrictions Severity: critical Users confused why payment fails Instead: Always show valid merchants/categories alongside balance ### Letting users attempt invalid payments Severity: critical Wasted gas and frustrating experience Instead: Pre-check validity, disable payment button if invalid ### Not showing expiry prominently Severity: high Users lose tokens they forgot about Instead: Highlight expiring tokens, send notifications ### Hiding spending limits until exceeded Severity: high Surprise rejections damage trust Instead: Show limit progress: "320/500 monthly remaining" ### No way to find valid merchants Severity: medium Users have tokens but don't know where to spend them Instead: Merchant directory searchable by token type ## UI Components ### PurposeBoundBalance Token balance with restriction summary States: loading, loaded, restricted, expiring-soon Props: amount, symbol, validMerchants, expiresAt, restrictions ### MerchantValidityChecker Real-time check if token valid at merchant States: checking, valid, invalid, unknown Props: tokenId, merchantAddress, category ### SpendingLimitTracker Show used vs available within limits States: available, approaching-limit, at-limit Props: used, limit, period, resetsAt ### MerchantDirectorySearch Find valid merchants for a token type States: searching, results, no-results, loading Props: tokenType, location, categories ## On Monad ### Validity Checking Ethereum: On-chain validity checks may be slow/expensive Monad: Fast, cheap checks enable real-time validation Design implication: Can check validity as user browses checkout ### Payment Speed Ethereum: Purpose-bound payment may take 15+ seconds Monad: Sub-second finality for instant purchase confirmation Design implication: Receipt/confirmation appears immediately ### Limit Updates Ethereum: Checking remaining limits may lag Monad: Real-time limit updates after each purchase Design implication: Dashboard shows live spending progress ### Batch Payments Ethereum: Multiple items might need separate constraint checks Monad: Parallel verification for complex carts Design implication: Can validate entire cart at once ## Key Takeaways - EIP-7994 = tokens with built-in spending rules - Always show restrictions, valid merchants, and expiry clearly - Pre-validate before attempting payment - Provide merchant discovery for restricted tokens - On Monad: leverage fast finality for instant validity checks ## UX Patterns ### Purpose-Bound Wallet View Show tokens with their spending restrictions User flow: - User opens wallet - UI separates regular vs purpose-bound tokens - Each restricted token shows its constraints - Expiry and limits displayed clearly - Tap to see valid merchants Mockup registry key: `concept/tx-status` (React UI on the live standard page). ### Merchant Payment Flow Pay with purpose-bound tokens at valid merchant User flow: - User at checkout - UI checks which tokens valid at this merchant - Purpose-bound tokens shown with validity indicator - User selects appropriate token type - Payment succeeds if constraints satisfied Mockup registry key: `generic/balance-display` (React UI on the live standard page). ### Invalid Merchant Warning Clear feedback when tokens can't be used User flow: - User at non-eligible merchant - Purpose-bound token shown as invalid - Clear explanation of why - Link to find valid merchants - Alternative payment methods highlighted Mockup registry key: `concept/verify-safety` (React UI on the live standard page). ### Expense Token with Receipt Corporate expense requiring documentation User flow: - User initiates expense payment - UI shows all requirements - Upload receipt if needed - Verify category and limits - Payment processed with documentation Mockup registry key: `concept/tx-status` (React UI on the live standard page). ## Technical Notes EIP-7994 defines purpose-bound tokens with isValidTransfer(from, to, amount, purpose) checks. The contract stores valid merchants/categories, spending limits, and expiry. Transfers only succeed if the recipient (merchant) is approved for the token's purpose. Additional metadata can require documentation (receipts) via off-chain attestation.