# ERC-7994: Purpose Bound Money Source: https://www.eipsfordesigners.com/standards/ERC-7994 Agent brief: https://www.eipsfordesigners.com/standards/ERC-7994/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-7994 Last reviewed: 2026-09-18 Last updated: 2026-09-18 | Field | Value | | --- | --- | | Status | Final | | Chain | both | | Category | DeFi Patterns | | Journey stages | Asset Management | | Detailed guide | Yes | | Official specification | https://ercs.ethereum.org/ERCS/erc-7994 | | Discussion search | https://ethereum-magicians.org/search?q=ERC-7994 | ## UX Impact ERC-7994 binds a recipient and amount to arbitrary unlock conditions and optional expiry. Use bindPurpose(), isUnlocked(), and claim(); merchant, KYC, category, receipt, and spending-limit behavior belongs to issuer-selected condition implementations, not a universal merchant directory or isValidTransfer() check. ## Summary ERC-7994 defines purpose-bound money through a binding that names a recipient, amount, unlock conditions, and optional expiry. Merchant, KYC, category, receipt, and spending-limit behavior comes from the condition implementations selected by the issuer; the standard does not provide a universal merchant directory or transfer pre-check. ## For Designers - You can show the recipient, amount, unlock conditions, and expiry of each purpose binding. - You can reflect spending limits or categories when the selected condition resolver defines them. - You can show a merchant or eligibility result only when an application condition supplies that data. ## 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: a recipient can claim a bound amount after its configured conditions unlock. - Connect flows must list wallets with names, icons, and explicit user choice. ### When to Avoid - The deployed contract has no purpose binding or condition resolver to inspect. - The flow is an ordinary transfer with no recipient claim or unlock state. - No merchant, category, receipt, KYC, or spending-limit condition is configured for the binding. - 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: A recipient claims a bound amount after its configured conditions unlock ### Corporate cards require centralized control Impact: high Old way: Visa/corporate card with bank managing restrictions New way: Issuer-selected conditions can enforce spending limits or categories ### Benefits programs can't ensure proper use Impact: high Old way: Issue vouchers, verify manually, prone to fraud New way: A condition resolver can expose merchant eligibility when the application provides it ### Grants require trust or complex escrow Impact: medium Old way: Send grant money, request receipts, manual auditing New way: The binding records whatever recipient and condition policy the issuer configures ### Can't combine spending restrictions with expiry Impact: medium Old way: Separate systems for spend categories and time limits New way: A binding can include an optional expiry alongside its configured conditions ## Anti-Patterns ### Showing restricted tokens without explaining restrictions Severity: critical Users confused why payment fails Instead: Show the binding's configured conditions, recipient, amount, and expiry; label merchant data as application-specific ### Letting users attempt invalid payments Severity: critical Wasted gas and frustrating experience Instead: Check isUnlocked(bindingId) when supported before presenting the claim action ### Not showing expiry prominently Severity: high Users lose tokens they forgot about Instead: Highlight an optional binding expiry and notify users according to the issuer's policy ### 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: Offer condition or merchant discovery only when issuer/application data supports it ## UI Components ### PurposeBoundBalance Token balance with restriction summary States: loading, loaded, restricted, expiring-soon Props: amount, symbol, conditions, expiresAt, restrictions ### PurposeConditionChecker Show the deployed condition resolver's result for a binding States: checking, valid, invalid, unknown Props: bindingId, conditions, isUnlocked ### SpendingLimitTracker Show used vs available within limits States: available, approaching-limit, at-limit Props: used, limit, period, resetsAt ### ConditionExplorer Explore issuer-provided condition or eligibility data when available States: searching, results, no-results, loading Props: bindingId, conditionType, issuerData ## Key Takeaways - ERC-7994 = tokens with built-in spending rules - Always show configured restrictions, recipient, amount, and expiry clearly - Show binding and unlock status before presenting a claim action - Provide condition or merchant discovery only when the issuer/application supplies it ## 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 configured conditions displayed clearly - Tap to inspect the resolver-provided eligibility details ### Merchant Payment Flow Pay with purpose-bound tokens at valid merchant User flow: - User at checkout - UI creates or loads the binding for the recipient and amount - Configured conditions shown with pending/unlocked state - User reviews the claim path - Recipient claims after isUnlocked(bindingId) is true ### Invalid Merchant Warning Clear feedback when tokens can't be used User flow: - User at non-eligible merchant - Binding shown as locked or not applicable - Clear explanation of the unresolved condition - Link to the issuer's condition or eligibility information - Alternative payment methods highlighted ### Expense Token with Receipt Corporate expense requiring documentation User flow: - User initiates expense payment - UI shows all requirements - Upload receipt if needed - Verify the configured condition and limits - Recipient claim proceeds when the binding unlocks ## Technical Notes ERC-7994 defines purpose bindings with a recipient, amount, an array of arbitrary UnlockCondition values, and optional expiry. The core lifecycle uses bindPurpose, isUnlocked(bindingId), and claim(bindingId); merchant, KYC, whitelist, receipt, category, and spending-limit semantics belong to the condition implementations. Do not assume an isValidTransfer selector, a universal merchant list, or an ordinary transfer flow.