批量刻写是铭文发行从”一件一件手工点”走向工程化的关键一步。ord 官方文档为它准备了一份输入文件：batch.yaml（示例文件在 ord 仓库根目录），配合命令 ord wallet batch --fee-rate 21 --batch batch.yaml 使用。读懂这份文件，基本就读懂了批量铸造的全部可调参数。
文件顶层首先是 mode，决定这一批铭文落在哪里，官方示例注释列出四种：same-sat（全部刻在同一枚聪上）、satpoints（分别刻到指定输出坐标的第一聪上）、separate-outputs（每个铭文占一个独立的最小邮资输出）、shared-output（多个铭文共享一个输出、按 postage 切分）。批量之所以可行，靠的是封套里的 pointer 字段：一次揭示交易的多个输入可以各携带铭文，解析器按顺序把它们分配到不同聪上；对合集来说，还可以把同一个父铭文传进揭示交易，让多个子铭文在同一笔交易里共享父级。
与分配相关的顶层字段还有：parents（父铭文 ID 列表，声明这批铭文的合集归属）、postage（分给每个铭文的聪数量，即每枚铭文自带的”邮资”）、reinscribe: true（允许在已有铭文的聪上追加）、sat（只能与 same-sat 搭配，指定目标聪号）。
inscriptions 列表逐项描述每个文件：file 是内容路径；delegate 让这枚铭文把展示内容指向另一枚；destination 指定收款地址——不写时 ord 会用钱包新地址，写了就等于把铸出来的铭文直接刻进别人的地址，这是”替别人铸”的标准做法；title 与 traits 写入铭文的结构化属性卡；metadata 是自由 CBOR 元数据；metaprotocol 是协议标识字符串（官方示例为 DOPEPROTOCOL-42069）；gallery 则声明这枚铭文是一个展册、逐项列出被收录的铭文 ID。文件里还可以带一个 etching 段，在同一次操作中刻一枚 Runes 代币：名称、divisibility 可分精度、premine 预挖量、symbol 显示符号、terms（单次铸造量 amount、次数上限 cap、按绝对高度或相对高度划定的窗口），以及总量约束——supply 必须等于 premine 加 cap 乘 amount；turbo: true 表示接受协议未来的额外改动。
新手要注意三点。第一，destination 一旦填错，铭文直接落在别人地址上，找回需要对方主动转回。第二，postage 决定每枚铭文自带的聪额，过小会让铭文依附的输出接近尘埃值，转手时受费率与钱包选币影响。第三，批量文件里写的都是共识前的”意图”，最终以链上揭示交易为准，发布前应先用浏览器核对父铭文 ID 与目标地址。
把文件交给机器执行之前，人还要替它做三轮核对。第一轮核对意图：这份 batch 里的 parents 是不是你想挂的合集父铭文，destination 有没有填成自己的地址；第二轮核对钱：postage 乘以数量会锁走多少聪，fee-rate 在当前 mempool 里能不能进块，一批几十个文件在高峰期会拆成几笔提交交易、揭示阶段还要再付一次，这些成本都发生在点击执行之前；第三轮核对版本：批量文件的字段随 ord 版本演进，老教程里的键名在新版可能改名或删除，执行前用当前版本的帮助页对一遍键列表，比在报错里逐条试错便宜得多。批量铸造的工程量恰恰在这些看似无聊的清单上——它放大每一处小错的后果，也放大每一处小心的收益。
顺带澄清一个新手常问的边界：批量文件解决的是”铸造阶段的编排”，不是”托管”。整批执行完成后，铭文散落在 destination 或钱包地址里，与一次一枚手工铸没有任何结构差异——没有统一的合集合约、没有批量回滚，失败的处理也是逐笔的。所以严肃发行方通常把 batch 文件连同生成哈希一起归档进版本库，把它当作发行说明书保存：日后有人追问这批藏品的邮资、父铭文与收款地址，答案就在这份 YAML 里。
还要提醒一句发布节奏上的事：批量执行会一次性把多笔提交与揭示打进内存池，费率波动时同一批文件可能出现”提交已确认、揭示滞留”的中间态，父铭文在这段窗口里仍显示未创建子级，属于正常现象而非铸造失败。稳妥做法是避开费率尖峰分批投放，把一份大 batch 拆成两三个小文件串行执行，既便于逐批核对链上结果，也避免整批揭示被卡在同一高度集体等待。发行前把预期输出清单导出存档，执行后逐项打钩，这份笨功夫就是批量时代最低成本的审计。 本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。