把 NFT 借给别人用但不改户主：ERC-7695 的场景与所有权委托

NFT 租赁最尴尬的设计是“把藏品转给对方用”：所有权过户那一刻，租金与押金之外的一切保障都落到链下的合同和信任上，藏品的真实控制权已经不在出借人手里。ERC-7695 换了个思路：户主不变，使用权分层。这份提案在 ethereum/ERCs 仓库标注为 Draft，2024 年 4 月 2 日创建，基于 ERC-721 与 ERC-165，核心概念叫“所有权委托”（Ownership Delegation）和“场景”（Context）。

场景是谁定义的小社会

Context 由 Controller 创建，每个场景绑定一个 detachingDuration 参数——从这个场景 detach（摘除）藏品需要等待的时长，全局上限由合约的 maxDetachingDuration 给出，getContext 可以查回任意场景的控制者与时长。一枚 NFT 可以被挂进一个或多个场景，挂入时发出 ContextAttached 事件——同一枚藏品可以同时被多个场景引用、各自记录各自的使用关系，这正是它与“转给单一租客”模式的根本差别。场景里的“使用者”由 ContextUserAssigned 事件指定，被点名的人可以在场景内使用这枚 NFT，但拿不到转移它的权限；想退出场景，先发 ContextDetachmentRequested，等待期走完才发 ContextDetached。场景还能单独锁定某枚代币，状态变化写进 ContextLockUpdated；场景参数更新则发 ContextUpdated。

这套事件流水值得留意：谁在什么时候被指定为使用者、什么时候请求退出、锁没锁，全部有链上时间戳。纠纷时你不需要证明“他说借给我了”，只需要指着一串事件说“协议里约定的状态曾是这样”。委托方向另一组事件：委托开始（OwnershipDelegationStarted）、受托人接受（OwnershipDelegationAccepted）、委托终止（OwnershipDelegationStopped）——委托带截止时间，接受环节意味着受托人可以拒绝一个不想接的借用关系。

它解决什么、没许诺什么

它把“使用权与所有权分离”从各协议自造轮子变成可互认的接口：一个游戏资产场景里，租家用道具而永远拿不到转移权限；一个工具型 NFT 场景里，多人按座位分配使用记录。它没有许诺租金收益，也没有规定押金如何托管——这些仍然在场景之外。也不要把场景机制和 ERC-4907 一类租赁接口混为一谈：ERC-7695 强调 Controller 定义规则、支持多场景挂载与 detach 等待期，模型更像“多社区挂名”而不是简单的到期租用。

使用前逐条核对

作为出借方：确认合约真的实现了该接口（ERC-165 探测一下），查 maxDetachingDuration 与目标场景的实际等待期——detach 时长越短，意味着对方理论上越快把资产从场景摘走，这直接影响你在纠纷里的缓冲时间。作为租用方：确认自己是被 ContextUserAssigned 事件点名的人，而不是只听信对方“我把你加进去了”的口头说法；同时理解 User 权限只在场景内有效，藏品转卖后你的使用权命运取决于场景与实现的约定。

常见误区

误区一：把委托当转让的反面教材——委托到期自动收回的前提是实现正确执行了终止逻辑，Draft 阶段的实现务必看审计。误区二：认为户主永远高枕无忧。场景机制保护的是户主地址不变，但场景规则本身由 Controller 定义，若 Controller 是你不信任的平台，规则解释权就在别人手里。误区三：忽略锁定事件的作用，把锁当成装饰。ContextLockUpdated 在场景层面给出的“此物当前不可动用”状态，对挂单和出借决策都是硬信息，漏看它就会在错误的时间挂出错误的资产。还有一个新手常见困惑值得单独回答：这份标准和直接签一份链下租借合同相比强在哪？答案是时间戳与可组合性——事件流水不依赖任何一方的记性，其他合约也能读取委托与场景状态来决定逻辑；但它替代不了合同本身，租金、押金、损坏赔偿这些条款仍然要写在现实法律文件里，链上机制只是让“谁在何时能用什么”有据可查。对普通读者，这份标准最值得记住的是一条原则：凡是需要“暂时给别人用”的数字资产，先问链上有没有留下可查的使用记录，再问收益多少。本文不构成投资建议。