#baby $BABY 私が重視したのは「2種類の期限切れ、2種類の責任、同一の元本払い戻しの導線」だったので、それを実際の運用手順のリプレイに近い形へ再構成しました：
私は現在の公開テストネットにおける建て替え（建庫）の手順を時系列に並べてみたところ、最も混同しやすいのは「どれくらい待つか」ではなく、「約24時間で期限切れ」と「約48時間で期限切れ」のどちらが、結局誰のアクション未完なのか、という点でした。2つのケースはいずれも最終的に金庫（Vault）が期限切れになりますが、費用の結果は異なります。
通常、Pre-PegIn はまず Bitcoin Signet などで 12 件の確認を待ち、だいたい 120 分かかります。オフチェーンの署名と参加者確認は同時に進むため、ドキュメント上の推定どおり、完全な建庫まで約2時間です。
第1の期限切れは ACK の段階で起きます。必要な参加者が約24時間以内に準備を完了できていない場合、プロトコル側の処理が通っていないことを意味し、テストネットの建庫手数料は自動的に返金されます。ユーザーのBTCが消えるわけではありません。いったん Pre-PegIn の出力に一時的に停止しており、払い戻しの時間ロックが開くのを待つだけです。第2のケースは異なります。オフチェーン側の準備がすでに完了し、状態も Verified に入っているのに、ユーザーが作成後約48時間以内に能動的に起動（アクティベート）しなかった場合です。このとき金庫も期限切れになりますが、すでに前段の調整作業が発生しているため、建庫手数料は返金されません。損失になるのはテスト費用であって、BTCの元本ではありません。
現在の tRefund は 3日間に設定されています。時間ロックが期限切れになったあと、ユーザーは元の Bitcoin 鍵で署名するだけで、あらかじめ用意された払い戻しルートに沿って BTC を取り戻せます。Vault Provider やその他の参加者の協力は不要です。なお、この3日間は意図的な引き延ばしではなく、まず通常の起動ウィンドウが終わるのを待ち、「同じBTCが同時に『建庫を続行する』と『早期に払い戻す』という2つの競合する導線を持つ」事態を避けるためです。
@BabylonLabs_io は責任分担が非常に明確です。システム側が準備できていなければ返金し、ユーザーが最後のステップを完了していなければ返金しない。ただし元本は、片側の出口から一方的に回収できるよう保持されます。フロントエンドが本当に表示すべきなのは、単に「期限切れ」だけではなく、ユーザーがどの段階で止まっているのか、費用が返るのか返らないのか、どれくらいで回収できるのか、次に何を署名すべきかです。#baby $BABY
私は現在の公開テストネットにおける建て替え（建庫）の手順を時系列に並べてみたところ、最も混同しやすいのは「どれくらい待つか」ではなく、「約24時間で期限切れ」と「約48時間で期限切れ」のどちらが、結局誰のアクション未完なのか、という点でした。2つのケースはいずれも最終的に金庫（Vault）が期限切れになりますが、費用の結果は異なります。
通常、Pre-PegIn はまず Bitcoin Signet などで 12 件の確認を待ち、だいたい 120 分かかります。オフチェーンの署名と参加者確認は同時に進むため、ドキュメント上の推定どおり、完全な建庫まで約2時間です。
第1の期限切れは ACK の段階で起きます。必要な参加者が約24時間以内に準備を完了できていない場合、プロトコル側の処理が通っていないことを意味し、テストネットの建庫手数料は自動的に返金されます。ユーザーのBTCが消えるわけではありません。いったん Pre-PegIn の出力に一時的に停止しており、払い戻しの時間ロックが開くのを待つだけです。第2のケースは異なります。オフチェーン側の準備がすでに完了し、状態も Verified に入っているのに、ユーザーが作成後約48時間以内に能動的に起動（アクティベート）しなかった場合です。このとき金庫も期限切れになりますが、すでに前段の調整作業が発生しているため、建庫手数料は返金されません。損失になるのはテスト費用であって、BTCの元本ではありません。
現在の tRefund は 3日間に設定されています。時間ロックが期限切れになったあと、ユーザーは元の Bitcoin 鍵で署名するだけで、あらかじめ用意された払い戻しルートに沿って BTC を取り戻せます。Vault Provider やその他の参加者の協力は不要です。なお、この3日間は意図的な引き延ばしではなく、まず通常の起動ウィンドウが終わるのを待ち、「同じBTCが同時に『建庫を続行する』と『早期に払い戻す』という2つの競合する導線を持つ」事態を避けるためです。
@BabylonLabs_io は責任分担が非常に明確です。システム側が準備できていなければ返金し、ユーザーが最後のステップを完了していなければ返金しない。ただし元本は、片側の出口から一方的に回収できるよう保持されます。フロントエンドが本当に表示すべきなのは、単に「期限切れ」だけではなく、ユーザーがどの段階で止まっているのか、費用が返るのか返らないのか、どれくらいで回収できるのか、次に何を署名すべきかです。#baby $BABY