#baby $BABY 批量进入Bitcoin，看起来只是把几笔交易合成一笔；在TBV里，它更像一次对状态管理能力的测试。
我在参数页翻到“maxHtlcOutputCount”时，才注意到当前公开测试网的一笔批量Pre-PegIn交易最多放10个HTLC输出。多个Vault可以共用一笔Bitcoin交易，但每个输出仍保留自己的Vault状态和退出条件。对只开一个Vault的人，这个限制很远；对连续建立多笔抵押的人，它直接决定进入成本和操作节奏。
麻烦会出现在确认之后。用户不能只盯着一条交易哈希，还要分别确认每个Vault的ACK、激活和可借状态。假设手续费突然上升，或者某个输出的设置没有按时完成，批量带来的效率不会自动变成同步体验：运营方要处理一组状态，用户要承担等待和判断成本。省下的交易组织成本，可能又从界面和客服环节流了出去。
这也是我看TBV批量设计时更在意的地方。它优化了“怎么一次放进去”，却没有替用户消除多个Vault之间的管理差异。@BabylonLabs_io 后面如果公开批量Pre-PegIn的失败重试和单个Vault状态变化，才更容易判断它是在降低使用成本，还是把复杂度转移给用户。$BABY 的TBV叙事，最终要经得起这种细节追问。
我在参数页翻到“maxHtlcOutputCount”时，才注意到当前公开测试网的一笔批量Pre-PegIn交易最多放10个HTLC输出。多个Vault可以共用一笔Bitcoin交易，但每个输出仍保留自己的Vault状态和退出条件。对只开一个Vault的人，这个限制很远；对连续建立多笔抵押的人，它直接决定进入成本和操作节奏。
麻烦会出现在确认之后。用户不能只盯着一条交易哈希，还要分别确认每个Vault的ACK、激活和可借状态。假设手续费突然上升，或者某个输出的设置没有按时完成，批量带来的效率不会自动变成同步体验：运营方要处理一组状态，用户要承担等待和判断成本。省下的交易组织成本，可能又从界面和客服环节流了出去。
这也是我看TBV批量设计时更在意的地方。它优化了“怎么一次放进去”，却没有替用户消除多个Vault之间的管理差异。@BabylonLabs_io 后面如果公开批量Pre-PegIn的失败重试和单个Vault状态变化，才更容易判断它是在降低使用成本，还是把复杂度转移给用户。$BABY 的TBV叙事，最终要经得起这种细节追问。