#baby $BABY 大量のBitcoinへの投入は、単にいくつかの取引を1つにまとめ直しているだけに見えますが、TBVでは状態管理能力に対するテストのように振る舞います。
パラメータのページで「maxHtlcOutputCount」を見つけたとき、現在公開されているテストネットでは、1回のバッチPre-PegIn取引に最大10個のHTLC出力しか入れられないことに気づきました。複数のVaultは1つのBitcoin取引を共用できますが、各出力にはそれぞれ独自のVault状態と退出条件が保持されます。Vaultを1つだけ開く人にとってはこの制限は遠い話ですが、連続して複数の担保を作る人にとっては、参入コストと運用のリズムを直接左右します。
厄介なのは確認後に出てきます。ユーザーは取引ハッシュ1本にだけ注目するのではなく、各VaultのACK、アクティブ化、そして借り入れ可能状態をそれぞれ確認しなければなりません。仮に手数料が突然上昇したり、ある出力の設定が期限どおりに完了しなかったりすると、バッチによる効率が自動的に同期的な体験へと変わるわけではありません。運営側は一連の状態を扱う必要があり、ユーザー側は待機と判断のコストを負担します。取引を組むコストを節約しても、その削減分が結局、UIやサポート（カスタマーサポート）の工程に流れてしまう可能性があります。
だからこそ、私がTBVのバッチ設計を見るときに特に気にしているのはこの点です。TBVは「どう一度に投入するか」を最適化していますが、ユーザーに対して複数Vault間の管理差異を解消するわけではありません。@BabylonLabs_io の後に、公開されるバッチPre-PegInの失敗リトライや、単一Vaultの状態変化の挙動が示されたとき、それが利用コストを下げているのか、それとも複雑さをユーザーへ移しているだけなのかをより判断しやすくなるでしょう。$BABY のTBVに関する物語は、最終的にこのような細部への追及に耐えられる必要があります。