ERC-2615：一枚藏品两本账，抵押与租赁写进合约

一套抵押给银行、同时租给别人住的房子，链上怎么表达？普通 ERC-721 只有一个 ownerOf，回答不了“房东是谁、住客是谁、银行有多少留置权”三件事。ERC-2615（ethereum/ERCs 仓库，状态 Stagnant，2020 年 4 月创建）给 NFT 装上了房地产式的登记簿：所有权、使用权、担保权益各记各的。

双账户与权利清单

合约把持有人拆成两本账：ownerOf 记“产权人”，userOf 记“使用人”，于是 balanceOfOwner 与 balanceOfUser、safeTransferOwner 与 safeTransferUser 成对出现，产权转账和使用权移交是两条独立通道，事件也分开（TransferOwner、TransferUser）。在此之上叠两种可授权的权利：lien（担保权益）用 setLien 登记、approveLien 让债权人确认、getCurrentLien 查当前值、revokeLien 在债务了结后清除；tenantRight（居住/使用权利）用同构的一组函数 setTenantRight、approveTenantRight、getCurrentTenantRight、revokeTenantRight 管理。itemURI 挂资产文件，totalNumberOfItems 数总数，接口检测走 ERC-165。

这套记账能表达什么真实局面

想象一栋 token 化的房产：产权记在投资人钱包；银行作为抵押权人，在 lien 字段里挂上未偿余额；租客持有 tenantRight 覆盖租期。三方状态都写在同一份合约里，任何工具查询都得到同一答案，谁单方面改状态都会留下事件痕迹。这正是提案者对标“抵押加租赁”的意图。

它没有解决的部分

三层权利的查询剧本

给想实地核验 ERC-2615 式资产的读者一段剧本。第一幕查产权与使用权：对合约依次调 ownerOf 与 userOf，两个地址不同则存在使用权分离，再翻 TransferOwner 与 TransferUser 两条事件流，看分离是从铸造就设计好的，还是中途操作的。第二幕查留置：getCurrentLien 返回当前担保权益数值，非零说明这枚资产在合约口径里抵给了人——继续追 LienSet 与 LienApproval 事件确认债权人坐标与金额变更历史，把 approveLien 那一步的确认交易当作债权关系的链上凭证。第三幕查租约：getCurrentTenantRight 加 TenantRightSet 事件给出住客权利的登记轨迹。剧本演完，你手里是一份“同一资产三重权利”的链上时间线。但请记得剧本的边界：它读到的每一个数字都是合约内自报的口径，真实的债权文件、租约细则、违约定义全在链下法律文书里，链上记录与法律现实任何一处脱节，都意味着这枚 RWA 代币的治理还有暗账要查。

一个常见误区：把接口当市场

误区在于认为“合约支持抵押接口，就能像房产登记处一样对抗所有债权人”。事实是链上 lien 只约束这套合约内部的转账与查询，资产若同时存在线下抵押登记，两份记录谁优先要看法律安排与司法辖区，接口不会替你做权利顺位排序。另一个常见误读是把 userOf 当租赁凭证本身：它只是合约里的一格地址字段，租金、押金、违约条款都在别处。把 2615 式合约读成一本“正在生效的公共登记簿”之前，先确认它背后有配套的法律实体与登记流程，否则它更像一份自愿记账的草稿。

把这层关系想清楚，读者对 RWA 叙事会多一分清醒：链上合约的优雅记账与线下法律的强制执行是两套系统，代币化房产的真正难点从来在后者，接口只是把前者的账算整齐了而已。

要把丑话说全：状态 Stagnant 意味着它从未成为市场默认语言，真实借贷协议各写各的抵押合约；lien 的数值只是合约内数字，和链上债权凭证（贷款合约地址、余额预言机）怎么绑定，标准不管；清盘逻辑——违约后产权人可否被强制变更——提案给了函数骨架但没有法律层定义。用它核对真实资产时，先确认发行方是否真按接口落库，再确认 lien 数字背后的债权文件与审计路径，最后看违约条款在哪份法律文本里。它说明合约可以同时表达多重权利，不能替代任何一地不动产权属登记。本文不构成投资建议。