Runestone 与 Cenotaph：为什么一笔格式出错的 Runes 交易会烧掉代币

有用户用第三方工具发起 Runes 转账，交易确认后余额没有出现在收款地址，反而显示被销毁了，检查后发现是构造交易时多塞了一个无法识别的字段。这类事故的规则根源藏在 Runes 协议对”格式错误的账本”的处理里，下面把它拆开讲清。

Runestone：放在交易输出里的账本

和把数据刻进铭文信封不同，Runes 协议把每条协议消息写成一个特殊的交易输出，官方手册称之为 Runestone（符石）。它的锁定脚本以 OP_RETURN 开头，后接 OP_13，再跟若干数据推送，这些字节拼接起来解码成一串整数，再解析成协议指令。一笔交易最多只能有一个 Runestone；一个 Runestone 可以同时做三件事：铸造新符文、mint 已有符文、把输入里的符文余额分配给各个输出。

分配靠 edict（法令）完成：每条 edict 写明符文 ID、数量和输出编号，解析器按顺序处理，把余额指定给对应输出。所有 edict 处理完之后，还没分配完的余额默认进入第一个非 OP_RETURN 输出；Runestone 也可以带一个 pointer 字段指定别的默认输出。把代币用 edict 或 pointer 指向 OP_RETURN 输出，就是官方定义的销毁方式——这也解释了为什么”手滑”的代价可能是直接烧币。

Cenotaph：格式错误的账本长什么样

官方手册把解析失败的 Runestone 叫做 Cenotaph（衣冠冢）。触发条件包括：OP_RETURN 里出现了非纯数据推送的操作码、变长整数编码不合法、出现了协议无法识别的字段。名字起得很直白：一块立着的墓碑，纪念没埋进去的东西。

Cenotaph 的后果分三种情况。第一，这笔交易的输入里带进来的所有符文余额按销毁处理。第二，如果这笔交易试图 etch 新符文，该符文被标记为不可 mint。第三，如果这笔交易包含 mint 动作，mint 次数照常计入上限，但铸出来的代币直接烧掉。注意第三种：你以为只是失败了，实际把整个额度用掉了，还什么都没拿到。

为什么要设计成”宁可销毁”

这不是失误，而是官方文档明说的升级机制：协议将来可以给 Runestone 加入新语义，旧版本客户端不认识新字段时，如果按旧规则继续解释账本，会把代币放到错误位置，新旧解析器对余额在哪里产生分歧。统一按销毁处理，至少让所有解析器对”这些代币不再存在于常规位置”达成一致，代币不会悄悄记到某个没人认领的地址上。说白了，协议选择了失败即焚而不是失败即乱，用确定性换安全。

对普通用户意味着什么

第一，尽量用官方命令行或经过验证的钱包发起 Runes 交易，第三方拼装工具多写一个字段就可能把交易变成 Cenotaph。第二，看到不认识的新特性开关，先确认自己的客户端和所用工具版本是否支持再操作。第三，交易广播前的构造内容值得核对：edict 指向的输出编号、pointer 目标，都直接决定币最终去哪个地址。第四，万一余额”消失”，先查这笔交易是否被判为 Cenotaph，再下结论是不是被骗，多数情况是构造错误而非盗币。

动手前的版本对齐习惯

Runes 还在演进，官方手册明确说 Cenotaph 机制的意义在于：即使协议将来给 Runestone 加新语义，旧客户端也不会在“代币在哪里”这个问题上被误导。这带来一个日常习惯：升级客户端或钱包前，别急着使用新特性；升级后，先确认所用工具链的解析器版本同样支持新字段。协议升级最危险的时刻往往不是功能上线那天，而是新旧解析器在同一笔交易上各执一词的窗口期，提前把操作节奏与版本公告对齐，比事后争论谁记错了账要省事得多。 风险提示：本文仅说明协议规则与防御性操作建议，不构成投资建议。涉及代币构造与转账时请小额先行验证流程。