如果一个 NFT 项目想声明：持有者可以登录某游戏、可以领取素材、可以投票、不能转售，用什么方式最省事？ERC-6617 给了一个工程化答案：把这些许可编成一张权限表，每一位代表一件事，持有者的权限就是表上的一个号码。这份标准 2023 年 2 月登记，当前状态以仓库标注为准（登记于 Review 阶段），原文以仓库文件为准，核验时间 2026 年 8 月。
它的接口分成读写两组。读的一组回答现状：权限表有多少位、这张表叫什么和版本是什么、某个号码每一位的含义、某个人此刻有没有某位许可，以及一个容易忽略的历史查询——在过去某个区块高度上他当时有没有这个许可。写的一组负责变更：创建整张表、把某人的权限设成给定值、单独加某一位或减某一位。
设计里有三点最值得展开。第一，权限表本身按 ERC-721 管理：标准作者认为权限与 NFT 在逻辑上等价，一枚 NFT 通过一个权限号指向表上的某个号码。第二，权限是一个 256 位整数的位图：每一位代表什么，规范完全不管，由项目方在创建权限表时自己填进链上——这是整份标准最重要的留白，它只提供尺子，不规定尺子量什么。第三，改表是全局动作：对某个人调用加减某位的函数，只改他名下那条共享的权限记录；对表本身的结构调整则牵动所有人。这带来一个反直觉但重要的结论：两位持有同一权限号的持有人，此刻的许可完全相同；而他们的可感权益却可能因为另一层合约检查而不同——查权限必须同时看代币合约和权限合约两处。
把它放进现实使用，价值与风险都很清楚。价值是权利说明书从网页条款里被拽出来：过去项目方说持币即享某权益，全靠公告；换成这套接口后，权益的定义与查询都落在合约上，任何工具都能实时调用核验。风险同样来自留白：某一位到底代表什么，只有这张表自己的返回值说了算；规范与项目公告冲突时，以合约返回值为事实依据；而权限表可被创建方改写这件事，意味着链上权益的稳定性取决于谁握着改表的钥匙。
给收藏者的三句核对口诀：先读表——权限名称、版本与每一位的含义抄下来存档；再查号——对这枚 NFT 的权限号问一遍当前每一位的状态，顺手查一次历史高度上是否被改过；最后验门——到具体使用场景那一侧，看服务方有没有真的调用这套接口做门禁，表写得漂亮而门口不查表，等于没有。标准与条款冲突时，合约的返回值说了算。本文为标准机制说明，不构成任何投资建议。
再把两个常被混淆的概念分一次。下架是指列表不再展示，不等于资产从链上消失，也不自动意味着代币不可转；不可转移是指合约层面的限制，和平台的展示决定是两个系统的决定。有人把平台下架误读为项目死亡，也有人因为合约可转就以为平台一定在展示，两边都错在混层。正确的读法是先问平台层：列表还在不在、搜索能不能命中、详情页状态；再问合约层：能不能转、有没有权限锁；两个答案拼起来才是真实状态。把这两个问题固定成检查顺序，看任何项目都能在三分钟内定位它到底处在哪个象限，不会被别人的一句话带节奏。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。