TON 生态里的藏品元数据有一套自己的写法，标准编号 TEP-64，标题叫”非同质化代币与半同质化代币的元数据”。它和以太坊那边只约定一个 tokenURI 字符串返回任意 JSON 的做法不同——TEP-64 规定了具体的字段名和两种存放位置，钱包和市场靠这套约定统一解析展示。按标准文本（2022 年 2 月 10 日创建，状态 Active），创作者要做的第一步是把描述代币的 JSON 文件按标准组织好，第二步选择存放路径：内容小就整个塞进智能合约数据里（on-chain），内容大就传到网络能访问的存储（off-chain），然后在合约里放一个指向它的方法。
先说存放。标准明确：若元数据体积不超过 70 字节，建议直接内嵌进合约数据；否则上传到网络存储，由 NFT 合约的 get_nft_data 这类接口返回一个可获取该 JSON 的地址。这个 70 字节的门槛是它最常被讨论的设计——链内元数据意味着图片不能放进来，但文字、属性、短链接可以永久躺在合约里，理论上比任何 HTTP 链接都长寿；链外元数据则和 ERC-721 一样承受网关失效、文件被删的风险。标准没有承诺链外链接的持久性，这一点写文档时不能替它美化。
再说字段。JSON 顶层有 name（代币名称）、description（描述）、image（图像内容的 URL）、image_data（图像的原始 blob，用于直接内嵌图像）、image_content_type、external_url（引导用户查看项目网站或图像的链接）、attributes（属性数组，每个元素含 trait_type、value、display_type，枚举类型还支持 type 字段）、content（URL，指向 NFT 代表的非图像内容）、content_type、metadata（URL 或 blob，指向其他元数据），以及 additional_json——一个允许额外属性、必须按 JSON 解析的口袋字段。半同质化的 TEP-89 在这套结构上追加数量字段。值得留意的是属性数组里 display_type 的用途：它告诉前端这个值该按数值、日期还是别的格式渲染，避免把时间戳渲染成裸整数。
这套标准落进实际工具链的方式值得普通用户了解一层。TON 的钱包读取某枚藏品时，走的是”合约方法返回指针、指针再指向 JSON”的链路；如果项目方把 JSON 放在自己域名下的服务器上，域名的所有权就是这条展示链的单点故障——域名过期或被转移，钱包里的图就可能变灰。反过来，把图像用 blob 放进 IPFS 类内容寻址存储、JSON 里只留内容哈希，是标准支持且更抗腐蚀的做法。判断一个 TON 项目的元数据耐用性，看三处就够了：get_nft_data 返回的 JSON 地址落在谁的域名上、image 字段指向 HTTP 还是 IPFS、有没有用 image_data 内嵌小图。
给收藏者的核对清单可以压缩成三步。第一步，在链上查询工具里调用藏品的数据方法，把返回的 JSON 原文抓下来，确认 name、image、attributes 与你在市场页看到的一致——市场页面是二次渲染，JSON 原文才是一手数据。第二步，检查 image 与 content 指向的地址协议：https:// 开头的内容寻址哈希相对稳，指向具体域名的链接问一句”这个域名归谁、续费到什么时候”。第三步，attributes 里的字段名拼写是否规范，因为跨应用的稀有度统计全靠 trait_type 字符串精确匹配，项目方随手写成 Background color 和市场期望的 background 就对不上。
和以太坊生态对照着记最省力：tokenURI 相当于 TON 的 get_nft_data，两者的可验证性都取决于指针指向的内容会不会变；TEP-64 多给出的是明确的字段表、70 字节内嵌建议和 blob 内嵌选项。标准管的是”说明书怎么写”，作品版权、图片会不会消失、项目还能活多久，仍然要自己逐项确认。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。