This ERC extends the concept introduced in ERC-7291 by enabling ERC-20-compatible tokens to carry multi-condition unlocking constraints, combining temporal, identity, and usage restrictions into a programmable structure. It aims to support controlled disbursement of tokens where funds are only accessible under predefined, auditable, and verifiable conditions.
ERC-7291 introduced purpose-bound money by restricting how and where tokens can be spent. However, many real-world applications require multiple conditions to be satisfied simultaneously before tokens can be used. Examples include:
This proposal generalizes and formalizes such use cases by layering unlocking conditions on top of the ERC-20 standard.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.
The IPurposeBoundERC20 interface defines the standard for programmable token transfers that are conditional. Each transfer, referred to as a purpose binding, includes:
recipient and amount.UnlockCondition objects, each consisting of a conditionType (like "TIME", "KYC", or "WHITELIST") and conditionData used to evaluate the condition.expiry timestamp after which the transfer can no longer be claimed.The interface provides the following functions:
bindPurpose(...): Locks a specified amount of tokens to a recipient with defined conditions.claim(...): Allows the recipient to claim the tokens once all conditions are fulfilled.isUnlocked(...): Returns whether all associated conditions have been satisfied.This enables flexible, composable transfer mechanisms for various use cases including compliance, grants, payroll, and more.
Flexibility: Conditions are modular and extensible.
Composability: Can be integrated into DAOs, payroll, education, and compliance tokens.
Security: Off-chain verification (e.g., KYC) backed by on-chain proofs (e.g., Merkle roots).
Condition-checking mechanisms (e.g., Merkle roots, timestamps) must be secure against tampering.
The claim() function must ensure atomic verification of all conditions.
Replay attacks must be mitigated using unique binding IDs and expiration fields.
Copyright and related rights waived via CC0.