Vaultを運用する際に、ユーザーがいつでもオンラインになれて、いつでも署名できることだけを前提にすると、現実的ではない仮定を置いてしまいます。それは「資産保有者が永遠に連絡不能にならない」という前提です。

長期保有のBTCを持つ人は、端末を買い替えることもあれば、鍵を紛失することもあり、また突発的な事情で一時的に資産に対応できない場合もあります。このとき、システムは統制権を第三者に安易に委ねることもできず、またBTCが永遠に誰も操作できない状態で止まってしまうことも許されません。

そこで、私が @BabylonLabs_io が TBV を探索する動きに注目しているとき、同時に回復メカニズムをどう設計すべきかも考えています。ユーザーは事前にバックアップ条件を指定できるのでしょうか。回復プロセスには十分に長い待機期間が必要でしょうか。元の保有者が再び現れた後も、予期しない実行を阻止する機会は残るのでしょうか。これらのルールは、資産がVaultに入る前に明確にされるべきであり、問題が起きてから臨時に決めるものではありません。

#baby のエコシステムにとっては、回復能力は日常の利用と同じくらい重要です。回復の経路が緩すぎるとセルフカストディが弱まり、まったく回復経路がないと、一度の不注意が永久的な損失になり得ます。

より妥当な方向性は、ユーザー自身が事前に安全な境界線を定義できるようにすることです。誰が回復を提起できるのか、どのような証明が必要なのか、そしてどれくらい後に有効になるのか。

$BABY 関連のアプリケーションが徐々に長期資産を担うようになるにつれ、システムは「今誰がBTCを制御できるか」に答えるだけでなく、「元の保有者が操作できない場合、制御権をいかに安全に継続するか」も答えなければなりません。