#baby $BABY 大量进入比特币，看起来只是把几笔交易合成为一笔；在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叙事，最终要经得起这种细节追问。