業界全体にまたがるブリッジ設計やバルブ（ウォレット）設計は、答えにくい質問に対応しなければなりません。つまり、誰も処理を完了させないままになった場合、あるいは証明が一度も届かなかった場合、ロックされた資金はどうなるのか？ 多くのシステムはこの点に不十分にしか対応できず、資金が手動介入待ちの状態で滞留したり、最悪の場合、単に失われたりします。

Babylon のホワイトペーパーは、バルブ自身の論理の中に明確な答えを組み込みます。指定された目的を完了するための有効な証明を、誰も提出しないままタイムアウト・ウィンドウが経過すると、ロックされたビットコインは自動的に解除され、当初の預け入れ者へ返還されます。つまり、救済（レスキュー）トランザクションも、基盤（ファウンデーション）側の介入も不要です。このデフォルトは、オペレーターが、バルブが作成されたときに設定された正確な条件と一致する、特定の対応するイベントを能動的に立証した場合にのみ変更されます。実際にその出来事が起きていることを意味します。したがって、受動的な経路と能動的な経路は、対称的というよりは、設計上構造的に異なります。

受動的な「何もしない」デフォルトを組み込むことには、現実のコストが伴います。正当な請求が完了できるほど十分に長いタイムアウト・ウィンドウを指定するための工学的な工夫が必要です。ただし、資本が不必要にアイドル状態で長く滞留しないようにもする必要があり、これは一度だけ解決して終わりではなく、ユースケースごとに調整されます。自動的な返還が一切ない設計では、能動的な紛争（ディスピュート）メカニズムへの比重が高まり、より早く構築できる可能性はありますが、その代わり、預け入れ者は他者が正しくかつ迅速に行動することに依存することになります。

Babylon は、何もしないことが安全な結果になるようにバルブを設計しました。有効な請求が永遠に到達しない場合でも、ロックされたビットコインは救済プロセスを要求するのではなく、持ち主にデフォルトで戻ります。この「デフォルトから預け入れ者へ」の設計は、成功した経路だけでなく、失敗ケースをまず最初にエンジニアリングしていることを示しています。

@BabylonLabs_io $BABY #baby $DIA