盲盒类 NFT 最常见的信任问题不是”开出来的稀有度不对”，而是”你根本无法验证”：内容列表存在项目方的服务器里，揭示时后端换一张图，用户无从察觉。TON 生态为此定了一个叫 TEP-122 的标准，直译”链上 NFT 揭示”，标准文本 2022 年创建、状态 Active。它的一句话主张是：揭示这件事的输入数据必须在链上可查询，应用不需要、也不应该依赖一个私有后端来告诉你”还剩下什么”。
标准给合约加了两类只读接口。第一类是 get_reveal_data，查询它可以直接拿到”剩余可揭示的 NFT 信息”——按标准示例，返回结构里带一个 items_left 数组，逐项列出奖池里每种待揭示藏品的类型与剩余数量。第二类是 get_reveal_mode，回答”现在能不能揭示”：奖池还有剩余才能揭示，剩零就处于不可揭示状态。配合 TEP-62 的藏品查询方法，一个第三方钱包不必请求任何项目方 API，就能自己算出奖池构成、已揭示进度和当前状态，把揭示从一个”信我”动作变成”看链”动作。
和以太坊世界对照能看得更清楚。以太坊上常见的”链上盲盒”做法要么把属性哈希提前进链（reveal 时提交原文对哈希），要么用随机数驱动属性分配；TEP-122 走的是第三条路：让奖池本身成为链上可读状态。它解决的主要矛盾是”揭示前后池子内容会不会被偷偷调整”——池子逐项列在合约里，每揭示一枚，对应计数在链上减一，市场对剩余概率的实时估算就有了公开分母。标准文档自己也强调了这一点：揭示机制的设计目标就是让应用在项目方网站宕机时依然能展示”还有多少没开、各类型剩几枚”。
对参与盲盒的用户，这套接口能核三件事。第一，进池前先查 get_reveal_data，把列表和营销页公布的概率表对一遍——两边的稀有度分级对不上，问题不言自明。第二，算自己的条件概率：池子里稀有款还剩多少、总剩余多少，是”抽中概率”的真实分母；这个分母随每一笔链上揭示实时变化，任何截图宣传的固定概率都不如当场查一次链。第三，确认揭示交易的目标合约就是你买盒的那个合约，TEP-122 应用通常还会把”该用哪个合约地址查询”编码进 NFT 的数据里，钱包解析时若发现合约对不上就直接中止。
也要写清这套标准的边界。它管的是”奖池透明与揭示状态可查”，不保证随机性公平——揭示顺序由谁触发、每笔揭示如何映射到池内具体某一枚，仍取决于项目实现；若项目用固定顺序揭示，先抽和后抽的条件概率结构就完全不同，这是读 items_left 时应顺带推断的。它也管不到揭示之后的事：开出来的藏品元数据是否遵守 TEP-64、图片存在哪里，是另一个独立问题。一个常见误区是把”有 get_reveal_data”当成”这项目公平”，实际上接口只是让验证成为可能，验证本身还得有人做。市场页面展示”剩余 X 枚”和链上查询结果不一致时，以链上为准——这正是标准存在的意义。
给内容创作者一侧补充一句：设计揭示类项目时，把奖池一次性或分批写入链上，接受”池子策略对全网透明”的代价，是采纳这个标准的实质。想保留临场调整池子的空间，就不要宣称支持 TEP-122——两者互斥。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。