持有 Runes 代币的个人和企业账户，经常遇到一类朴素的工程需求：手里一个 UTXO 上挂着一笔代币余额和若干聪，要一次性分给十几个地址，有的还要顺带分点比特币。逐笔转账要付十几次基础费，还容易出现找零混乱。ord 为此提供了一条专门的命令：ord wallet split，配合 --fee-rate 设定费率、--splits 指定一份 YAML 配置，把”一条链上记录拆成多条”写成声明式的清单。
配置文件 splits.yaml 的结构在官方示例里非常直白：顶层一个 outputs 列表，每项三个字段。address 是接收地址；value 是这个输出分到的比特币金额，可以省略——省略时 ord 自动给该地址类型的最小非尘埃值，避免新输出因太小而进不了普通钱包；runes 是这个输出分到的代币映射，键是符文名（可以带官方间隔符，如 UNCOMMON•GOODS），值是数量，且数量尊重该符文的 divisibility 精度设定，示例里甚至直接写 22.5 这样的小数，由协议换算成最小单位。同一条交易里可以给 A 地址 10 聪加 1234 个某币，给 B 地址只留最低尘埃和另一种币 22.5 个，一次上链全部完成。
对铭文持有者，split 的边界比它的能力更重要：官方文档明确说明，该命令目前不允许把铭文分配到输出——它拆分的是比特币与 Runes 的账本载体，不是 Ordinals 铭文本体。想移动铭文，仍然要按铭文的规则走普通转账，让铭文跟着它所依附的聪一起搬家。把两者混在一句话里宣传的工具，值得先读它的签名请求再点确认。
典型的使用画面有三类。第一是”开渠道、备热钱包”前的 UTXO 整理：把一个大输出拆成多个常用面值，后续转账不必每次产生一堆找零。第二是代币分发：社区要给贡献者名单空投 Runes，一份 YAML 列好地址与数量，比手工逐笔省掉绝大部分重复基础费。第三是账户分层：冷钱包里把同一枚代币按用途切成几个独立输出，将来按输出整体转出让记账边界更清楚。
需要注意的细节也不少。拆出的每个输出都会永久进入 UTXO 集合，过度碎片化以后还得再花钱合并；分币的总量不能超过输入侧可分配余额，否则交易失败；YAML 里地址写错，等于把分好的输出直接寄错门。稳妥流程是：先在配置文件里核对地址、金额、符文名三个字段，用低费率发一笔含全部输出结构的小额测试，确认钱包与区块浏览器都能正确识别各输出，再执行正式的拆分清单。
执行链条上，split 和普通转账没有魔法差别：钱包选输入、按清单造输出、算一次手续费、签成一笔广播。清单里没写 value 的输出，会被自动垫到该地址类型的最小非尘埃值，这一条帮了大忙也埋了坑——帮的是你不必为每种地址背常量，坑是你可能没意识到自己往十几个地址各送了一笔比特币。符文数量的小数会按该符文的 divisibility 换算成最小单位入账，写了代币清单却没带足够比特币时，钱包仍要为新增输出付邮资，这些都是点击执行前能算出来、执行后没法撤回的账。另一个工程细节是输入选择：想拆哪个输出上的 Runes 和聪，得靠钱包已有的选币逻辑，历史碎输出多的钱包，一笔 split 可能顺手合并了不少旧 UTXO，手续费因此比理论值高，属正常现象而非错误。正式拆分前，拿清单的十分之一规模试跑一笔，观察每个输出的落点与余额，再上全量。
还有一个容易忽视的组合技：split 的清单模式与批量空投的名单管理天然契合。社区常见的做法是把贡献者名单维护成一张表格，用脚本生成 splits.yaml 后先做三重校验——地址长度与类型是否混入了其它链格式、符文数量加总是否等于钱包可分配余额、每个地址至少带不带够用的比特币邮资。校验通过再上链。等这份清单真的执行完，回执里每个输出的归属一目了然，复盘时不需要任何额外记录，这就是”声明式配置”作为操作纪律的价值：账本之外的那份 YAML，本身就是审计材料。 本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。