NFT 的用途能写进合约吗：ERC-6785 的 utilityUri 与修改历史

场景

很多人买 NFT 时看到“权益清单”：白名单资格、实体商品兑换、某工具访问权。这些承诺大多只写在项目网站和社交帖子里，哪天官网改版、域名到期、 Discord 解散，权益说明就找不回来了。ERC-6785（ERC-721 Utilities Information Extension，2023 年提出，仍是草案）尝试解决“说明消失”和“历史不清”两件事：把每项权益的说明文档地址写进合约，并且记录改过几次。

标准怎么写的

接口很小，三个函数加一个事件：

• setUtilityUri：给某个编号设置新的权益说明 URI（空字符串表示没有权益）。标准建议这个能力限制给提供权益的一方，可能是创作者也可能是别人。
• utilityUriOf：查询某编号当前的权益说明 URI。
• utilityHistoryOf：返回该编号权益 URI 的全部变更历史。
• UpdateUtility 事件：当 URI 被修改时记录编号与新的 URI。

规则上有两处刻意的严谨：UpdateUtility 事件不仅要在调用 setUtilityUri 时发出，任何导致权益变化的场合（比如批量更新）也必须发出；utilityHistoryOf 必须如实反映所有变更，无论是走哪个入口改的。接口标识是 ed231d73，通过 supportsInterface 查询。

元数据侧，标准给了一份在 ERC-721 元数据 JSON 基础上扩展的模式：utilities 对象里要求有 type（这是什么类型的权益）、description（简要说明）和 t&c（条款链接），可选的还有描述属性的键值数组与 expiry——注意有效期是从铸造时开始计、以秒为单位。也就是说，权益过没过期是能从铸造时间加 expiry 算出来的一个数字，不是靠公告记忆。

标准文档在动机部分也点明了为什么要做这件事：依赖第三方平台查询自己 NFT 的权益，可能招来诈骗与钓鱼。

它能说明什么、不能说明什么

能说明：某编号当前挂着的权益说明是哪个文档；这个说明改过几次、每次是什么（历史由实现方记录，最终以链上事件与状态为准）。

不能说明：权益是否兑现。标准只负责把说明和变更历史搬上链，兑现仍是项目方的义务；utilityUri 指向的文档多半在站外，那份文档本身还能不能被访问，合约并不担保。

买 NFT 前可以问的三个问题

第一，项目合约是否实现了这个扩展（或者至少提供可查的权益说明地址）。第二，权益 URI 的历史长什么样，改过几次，有没有把承诺改窄。第三，若元数据里有 expiry 字段，用它反推权益到期时间，把它当作条款的一部分而不是文案装饰。

需要提醒：这条标准目前仍是草案，实现合约不多，实现质量也取决于实现方是否如实记录历史。看不到相关字段只说明项目没接这个扩展，不代表它没有权益，也不代表它有；两边的信息来源都要另外核验。

元数据里的 utilities 字段

标准在 ERC-721 的元数据 JSON 模式上叠加了一个 utilities 对象，其中三项是必填：type 说明这是什么类型的权益，description 给一句简要说明，t&c 指向条款文本。两项选填：properties 是任意键值对的数组，用来描述权益的属性；expiry 是一个以秒计的数值，表示权益自铸造起的有效时长。把必填和选填摆在一起看，设计意图很清楚：让“权益是什么、条款在哪、什么时候过期”这三件事在每个编号的元数据里都有固定位置，而不是散落在公告里。image、name、description 这些老字段照旧继承 ERC-721 的定义与显示建议。设置侧还有一条约定：setUtilityUri 的空字符串表示该编号没有关联权益——查询返回空串时，正确的解读是“明确没有”，不是“还没设置”，两者在事件历史里可以区分。

顺带对齐两个容易混的概念。其一，utilityUri 指向的是一份说明文档的地址，不是权益本身；权益的兑现依赖项目方的服务与条款，这份 URI 只负责让说明可寻。其二，utilityHistoryOf 返回的历史是变更轨迹，回答“改过几次、每次指向哪里”；它不回答“这些说明当时算不算数”，后者仍属于项目条款与共识的范畴。把接口能力与契约义务分开，读这条标准就不会期待过高。

风险提示：本文为标准机制科普，不构成任何投资建议；权益兑现依赖项目方履约，任何权益说明都不构成收益承诺。