讨论铭文时，几乎所有教程都会先讲”附着”：一段内容被写进交易，索引器把它挂到某个聪上，此后这个聪走到哪个输出，铭文就跟到哪里。转账、挂单、找回，全部围绕”载带聪”展开。但在 ord 手册的字段表里，有一个容易被跳过的条目：tag 66，官方对它的说明只有一个短语——unbinds inscription，解绑铭文。
先复习一下字段的形状。每条铭文在信封脚本里由若干”字段”加一个可选正文组成，每个字段是两个数据推入：一个标签编号、一个值。手册目前列出的已定义字段共十三个，标签编号从 1（内容类型）、2（指针）、3（父件）一直到 17、19，再加上 66 和 255。大多数常见字段是”往里加信息”：指定内容类型、指向别的输出、引用父铭文。tag 66 反其道而行：它不给铭文新增归属，而是取消归属——这条铭文成立、有编号、内容完整，但不与任何一枚聪绑定。
“不绑定聪”听起来抽象，落到操作上很具体。铭文转账的前提是它坐在某个 UTXO 的某枚聪上，钱包才能把它当作价值单位一起搬走；一旦没有载带聪，“转给某人”这个动作就失去了抓手——没有聪，就没有依附的输出坐标。指针字段的文档从侧面印证了这一点：使用偶数标签的旧动机，正是让旧版本把铭文视为”未绑定”，而不是错误地把它指派给输入的第一聪。可见在索引器的设计里，“未绑定”是一种被明确承认的状态，而非报错。
对索引器来说，未绑定铭文依然是可查询的链上对象：它有交易号加序号组成的 ID，有按揭示顺序排出的编号，有内容哈希。缺的只是”sat 与 satpoint”这一栏的常规值。用 ord 命令行或 JSON-API 查询时，这类铭文的表现以软件版本的实际输出为准——手册定义语义，具体字段返回什么、钱包怎么展示，仍要在自己那台索引节点上核对，不同版本对这个较新特性的支持进度也可能不一致。
为什么会有人想主动制造一条不指向第一聪的铭文？指针文档给出的用例很实在：一笔交易想同时刻多条铭文时，如果全部默认落在输入第一聪，它们会挤在同一枚聪上堆叠；给其中几条各配一个指针，就能让它们分别落在不同输出、不同聪上，账目清爽。这也解释了为什么指针用偶数标签——指针文档写得很清楚：使用偶数标签，是为了让旧版本的 ord 把这条铭文视为未绑定，而不是错误地把它指派给输入的第一聪。
与”拥挤”相对的另一个方向是”游离”。多条铭文同坐一枚聪时，转账会把整摞一起搬走，拆不开；而未绑定铭文连这层捆绑都没有——它不属于任何一枚聪，也就不会被任何一次聪的搬运顺带带走。你可以把它理解成索引系统里的一类特殊户口：有身份登记（ID、编号、内容），没有户籍地址（sat）。手册同时强调，重刻（reinscription）只是在同一枚聪上追加新铭文，不会改动原有铭文；可见”谁在聪上”这笔账，索引器记得极其保守——追加可以，改写不存在，解绑则是字段语义明确批准的唯一例外。
最需要警惕的是一种想当然：把”查得到”当成”转得走”。普通钱包和市场的转账流程假设铭文有载带聪，遇到未绑定铭文，有的会直接过滤，有的会报错，也有的界面显示为空。反过来，卖家如果在没确认索引状态的情况下承诺”这枚铭文可以正常发货”，纠纷往往就出在这里。稳妥的做法是发货前用节点或可信索引器把该铭文的 satpoint 字段查一遍，把查询结果连同编号一起留档。
为什么要有人主动解绑？手册没有替用户规定动机，常见的解释方向是把铭文当纯存档：内容永久留在链上、编号永久存在，但不参与”随聪搬家”的流通逻辑。这与你是否看好它的价值无关，只是一种把记录与流通分开的选择。理解 tag 66 的价值在于它提醒所有人：铭文世界里的”归属”不是天然的，是索引器按字段规则算出来的账。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。