1回限りの期限切れサンプルは「この種の失敗が起きたこと」を証明できるが、「それがどれくらいの頻度で起きるのか」には答えられない。Trustless Bitcoin Vaults（TBV）のプロバイダ信頼性を計算するには、少なくとも「失敗数」と「総試行数」という2つの量が必要である。

Explorerは、0.07199256 sBTCのVaultを1件公開している。Providerがウィンドウ内でkeeper ACKを完了せず、最終的に期限切れになった。これを失敗数1として記録するのは問題ない。しかし、同一の統計基準での総アクティベーション試行、観測期間、各Providerの分布が提示されていないため、分母は空のままである。

分母がなければ、1をパーセンテージとして書くこともできず、この事例から特定のProviderが長期的に不可靠だと断言することもできない。まして、プロトコル全体の安定性を推論することはできない。2026年7月24日のページには4社のProviderが挙げられていたが、それは役割数のスナップショットにすぎず、4回の試行でもなく、信頼性サンプル集合でもない。

それでも、この記録には価値がある。テストネットが「成功パスだけ」ではなく、協調の可用性が工程の停止点になり得ることを確認するからだ。結論は、失効（失敗）モードが存在することに留めるべきであり、検証可能な反例を一般の統計へ拡張してはならない。

また、資産管理も別個の変数である。現在のtestnetではBTCはBitcoin Signet Taproot UTXOに残っており、Sepolia側にはAave v4が読み取れる、自由に譲渡できない担保記録しかない。Providerのタイムアウトはlivenessの問題を示すにとどまり、BTCの托管権を取得したこととは等しくない。

したがって、この種の事例を引用する際は、観測単位、時間窓、失敗イベント、そして欠けている分母を一緒に明確に記すべきである。N＝1はリスク課題を開くことはできても、信頼性評価を閉じることはできない。統計的基盤のないパーセンテージを提示するより、それのほうが有用だ。

@BabylonLabs_io $BABY #baby