Babylon Labs 的 TBV 测试网上线后，有一项设计被频繁提及：一笔 Bitcoin 交易可以批量打包最多 10 个 HTLC 输出。表面看，这无非是把手续费“砍到十分之一”——毕竟省去了分别广播父交易的 Gas 消耗。
但如果你只看到“省钱”，就完全误解了这组设计的真正意图。
批量交易的本质，不是把 10 个用户的 BTC 塞进一个池子里共担风险。恰恰相反——每个输出仍然对应一个完全独立的 Vault，拥有各自的 UTXO、各自的预签交易图、各自的退出路径。10 个 HTLC 输出 = 10 个独立保险箱，只是刚好装进了同一个快递袋。运费确实降低了，但每份保单仍需单独签署、单独核验、单独理赔。
这背后的安全哲学很明确：效率可以共享，风险绝不能 pooling。
链下协调与备份负担并未因为“打包”而减轻。创建时，Vault Provider 需要收集各方签名并批量提交以太坊；即便 VP 离线，用户也可从链上获取签名完成 PegIn。但若 VP 拒绝配合赎回，用户仍必须依赖自持的 WOTS 密钥和 claim artifacts 自助操作。批量交易压缩的是费用，不是安全流程。
这就像把多份独立保单装进一个快递袋——运费降低了，但每份保单的签署、核保、理赔流程一点都没简化。你不能因为包裹合并在一个袋子里，就认为它们共享同一个保额。$BABY
在我看来，@BabylonLabs_io 这主网上线后，比起“省了多少钱”，我更关注三组数据：批量规模的实际分布、签名的完整完成率、以及 VP 离线时用户的自主接管速度。这三项指标，才是判断这套“批量但不 pooling”的设计，运维摩擦是否真的抵消费用优势的关键依据。
技术可以优化成本，但安全从来不接受团购。
#baby $BABY
但如果你只看到“省钱”，就完全误解了这组设计的真正意图。
批量交易的本质，不是把 10 个用户的 BTC 塞进一个池子里共担风险。恰恰相反——每个输出仍然对应一个完全独立的 Vault，拥有各自的 UTXO、各自的预签交易图、各自的退出路径。10 个 HTLC 输出 = 10 个独立保险箱，只是刚好装进了同一个快递袋。运费确实降低了，但每份保单仍需单独签署、单独核验、单独理赔。
这背后的安全哲学很明确：效率可以共享，风险绝不能 pooling。
链下协调与备份负担并未因为“打包”而减轻。创建时，Vault Provider 需要收集各方签名并批量提交以太坊；即便 VP 离线，用户也可从链上获取签名完成 PegIn。但若 VP 拒绝配合赎回，用户仍必须依赖自持的 WOTS 密钥和 claim artifacts 自助操作。批量交易压缩的是费用，不是安全流程。
这就像把多份独立保单装进一个快递袋——运费降低了，但每份保单的签署、核保、理赔流程一点都没简化。你不能因为包裹合并在一个袋子里，就认为它们共享同一个保额。$BABY
在我看来，@BabylonLabs_io 这主网上线后，比起“省了多少钱”，我更关注三组数据：批量规模的实际分布、签名的完整完成率、以及 VP 离线时用户的自主接管速度。这三项指标，才是判断这套“批量但不 pooling”的设计，运维摩擦是否真的抵消费用优势的关键依据。
技术可以优化成本，但安全从来不接受团购。
#baby $BABY