ERC-7994: Purpose-Bound ERC-20 with Conditional Unlock

Extends ERC-20 with programmable restrictions, enabling transfers based on multiple unlock conditions as defined in EIP-7291.

Metadata

Status: DraftStandards Track: ERCCreated: 2025-07-29

Authors

Anushka Yadav (@64anushka), Akash Kothawade (@akash3927), Atishek Singh (@atisheksingh)

Requires

EIP-20, EIP-7291

Links

GitHub page Discussion on Ethereum Magicians

Abstract

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.

Motivation

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:

Scholarships requiring the recipient to be KYC-verified, under 25 years of age, and registered at a university.
NGO aid to be used only for food and medicine, after a specific unlock date.
Payroll tokens that unlock monthly and only for whitelisted vendors (e.g., banks, healthcare providers).

This proposal generalizes and formalizes such use cases by layering unlocking conditions on top of the ERC-20 standard.

Specification

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.

Interface

The IPurposeBoundERC20 interface defines the standard for programmable token transfers that are conditional. Each transfer, referred to as a purpose binding, includes:

A recipient and amount.
A set of UnlockCondition objects, each consisting of a conditionType (like "TIME", "KYC", or "WHITELIST") and conditionData used to evaluate the condition.
An optional 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.

Rationale

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

Reference Implementation

Security Considerations

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.