代币先绑目的再领取：ERC-7994 目的绑定与条件解锁

链上发钱最难的不是发，而是“发得出去、按约定花得掉、没达条件拿不走”。线性归属合约与多签分期解决了时间轴，但满足业务条件的解锁（“对方完成认证后才能领”“白名单事件发生后才放”）各家都写自己的土办法。ERC-7994 目的绑定的条件解锁 ERC-20（Purpose-Bound ERC-20 with Conditional Unlock）给出统一接口。标准状态为 Final，创建于 2025 年 7 月 29 日，依赖 ERC-20 与 ERC-7291。

一笔绑定的四个要素

核心数据结构叫“目的绑定”（purpose binding）：收件人 recipient、数量 amount、一组 UnlockCondition，外加可选的 expiry 时间戳。每个条件由类型（conditionType）与数据（conditionData）成对表达，文档举例的类型包括 TIME、KYC、WHITELIST——分别是时间门槛、“完成认证声明的凭证”、白名单证明（示例数据提到 Merkle 根）。接口层三把钥匙：bindPurpose(recipient, amount, conditions, expiry) 把锁扣上并返回一个 bindingId；claim(...) 让收款人在全部条件满足时真正拿到代币；isUnlocked(...) 查询这笔绑定当前是否已可领。文档点名的适用场景：合规转账、拨款与资助、链上薪酬与带门槛的返佣。

对照传统锁仓合约：ERC-4626 一类处理“份额怎么记账”，7994 处理“领取之前要不要先满足某个事实”，两者互补而非竞争；与 7818 的“到期作废”方向相反，7994 的默认方向是“条件满足即生效”，expiry 更像领取截止日而非销毁开关。

谁定义“条件满足”

这是读者最需要警觉的结构性问题。UnlockCondition 里只放了类型标签与数据，如何判定满足是合约实现者的自由裁量：TIME 用区块时间戳还是预言机喂时、KYC 认哪个签发方的凭证、WHITELIST 的 Merkle 根由谁公布与更新。评估一笔目的绑定，实际是在评估它的条件评估器——评估代码的可信度、升级路径与签发方私钥。一个只写“KYC 完成即领”却不公布评估合约地址的绑定，与一纸中心化托管合同相比没有任何链上约束优势。

另一个常被误读的点：expiry 是领取截止，不是自动退回承诺。过期未领的资金留在合约里、可被发起方回收、还是永久锁住，标准没有写成硬规定，读具体实现才知道回收语义——这是绑定条款谈判时值得写明白的字段。

给参与人的核验顺序

如果你是被绑定的一方：先拿到 bindingId，用 isUnlocked 与事件确认绑定真实存在；再逐条核对自己被挂上的条件类型与参数——KYC 类条件务必确认签发方身份与验证页面域名，链上条件验证不要求你交出证件原件照片，任何索要身份证正反面原图的“验证通过即可领取”页面按钓鱼处理；临近 expiry 尽早走 claim，别把领取操作压到最后一刻赌 gas。如果你是发放方：绑定不解决接收地址真实性——recipient 填错地址等于把一份“迟早可领”的债权送人，绑定前先向对方索要可验证的地址归属；conditionData 里不要嵌任何未发布的秘密参数，链上数据是公开的。

标准把“有目的的钱”变成一组可组合、可索引的合约状态，但目的本身仍是人与合同的约定。协议只保证一件事：没满足它写下的条件，谁都领不走；它从不保证另一件事：它写下的条件等于你们谈好的条件。

给审计者的补充自查：绑定事件历史里，同一 recipient 是否存在多份互斥绑定——反复改条件重发通常意味着发放条款在单方面漂移；claim 成功交易中的条件评估由哪个地址或合约给出；expiry 的分布是否高度集中——大量绑定同日到期，往往是活动策略要变的先兆，持有人群值得在到期前把 claim 流程走通一遍而不是等到截止日挤兑 gas。

这份记录还是免费的尽调素材：绑定事件里的条件类型分布、expiry 的疏密节奏（大量同日到期意味着活动策略可能收紧）、claim 成功交易由哪个地址确认条件，三条都该出现在你评估项目的清单上。 最后提醒：本文讲解锁机制，不构成投资建议或合规意见；领取、绑定代币前请核对合约地址、条件评估器与有效期，争议以合同与链上记录为准。