在链上管理铭文的人迟早会撞上一个问题：同一个钱包里既有能正常花掉的比特币，又有不能乱动的铭文输出，钱包选币时一旦把带铭文的输出当普通余额花掉，藏品就永久损失了。ord 的钱包子命令为此准备了一组分工明确的工具，wallet split、cardinals 与 balances 各管一段，完整走一遍能把 ord 钱包的账本模型看通透。
先建立模型。ord 钱包的账本视角与普通比特币钱包不同：每个输出同时携带两层信息——里面有多少可花的纯比特币，以及载着哪些铭文或代币。一个输出哪怕金额很小，只要载着铭文，就是不能随意当零钱花动的对象；反过来，纯比特币的输出被称为不带任何附加资产的输出，可以安全参与选币。理解了这个双层视角，才明白后面所有命令的存在意义。
wallet cardinals 命令负责清点：遍历钱包全部未花费输出，把载有铭文或 Runes 代币的输出剔除，返回一份干净的纯比特币输出清单，每条带输出点与金额。日常场景是钱包里小额输出堆积、转账费率高时，先看这份清单决定要不要合并整理，避免把整理交易打到铭文输出上。它的输出结构里只有输出点和聪值两个字段，简单到一目了然——这份简洁恰恰说明工具的职责边界：只识别，不动钱。
wallet split 命令处理复杂分配。它读取一个 YAML 配置文件，在文件里声明要创建的每一个输出的比特币金额、要分配的 Runes 代币数量，工具据此构造一笔多路输出交易。典型用法两类：一是拆分那些金额太大不便直接使用的纯比特币输出，让后续转账灵活些；二是一笔交易向成百上千个地址分发代币。文档明确当前版本的 split 不支持把铭文指定给输出——铭文的去向只能靠控制聪的移动间接实现，这与它面向纯资产整理的定位一致，写配置文件时别指望它能安排铭文归属。示例命令形如 ord wallet split —fee-rate 21 —splits splits.yaml，费率与配置路径都显式给出，方便脚本化。
配套的核对命令是 wallet balances：按类别汇总钱包里的比特币、铭文与代币余额，作为交易前后的对账基准。稳妥的操作节奏是三步：改账之前先跑一次 balances 留存快照，再跑 cardinals 确认要动的输出不携带任何附加资产，配置文件交给 split 后先看工具打印的预览再广播；交易确认后再跑一次 balances，前后差值应与预期完全一致。任何一格对不上，立即停止后续操作、回到链上逐笔排查。
几个常见误区值得点名。第一，把 split 当成整理铭文的工具——它的 YAML 没有为铭文指定输出的能力，铭文搬家要走 ord send 或让接收方控制目标地址。第二，以为 cardinals 列出的输出一定可以随便花：如果某个输出虽然纯比特币但太小，低于网络的粉尘线，组进交易照样会被拒绝。第三，忘了 split 是活期构造：费率参数直接决定交易能否在拥堵时确认，照抄文档示例的 21 聪每虚拟字节前应先查当前费率行情。第四，YAML 写错时 split 的报错未必指向具体行，先用极小金额的样例配置试跑一次，比通读手册更能定位问题。
把这套命令放回语境：ord 钱包本质是一台带资产感知功能的节点钱包，split、cardinals、balances 只是它把账本透明性递给用户的几个窗口。窗口后面，规则始终是同一条——聪的去向决定铭文的去向，动手之前先把每一个输出的属性看清楚，比任何事后恢复都便宜。
补充一个运维视角：上述命令都运行在你自己的机器上，账本真相来自本地 ord 索引与你连接的比特币节点，这意味着排障时先检查索引同步状态与节点连通性，再怀疑钱包余额本身。钱包名多个版本还可用 —name 区分，批量操作时用显式的钱包名与网络参数，避免测试网与主网混用的低级事故——这也是官方文档反复示范用默认名加参数、而非依赖上下文的原因。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。