精算ロボットにハサミはなく、ただ丸ごと箱単位で持ち去るだけです。<br>@BabylonLabs_io の公開テストネットで、各Vaultを独立したUTXOとして設計しているのを見て初めてわかりました。双Vaultは見栄えのいい預金オプションではなく、精算時の損失を“粒度”として刻み分けるためのものだと。<br><br>一般的なDeFiでは担保を割合で切り分けて回収できますが、Bitcoinの取引では出力を丸ごと一つしか消費できません。たとえばポジションに0.4 BTCあるとします。精算で処理すべきのはそのうち約0.25 BTCだけで済むとしても、0.4 BTCを一つのVaultに全て詰め込んでしまっていれば、プロトコルはそこから0.25 BTCだけを切り出せず、Vault全体を精算に取り込むしかありません。余った価値が“消滅”するわけではありません。公平メカニズムが先にユーザーの残債を減らし、それでも余剰があればWBTCで返還されます。しかし、「等価の補償がもらえる」ことと、「自分のポジションにある原生BTCがそのまま残る」ことは、明らかに別物です。<br><br>これが双Vaultの本当の有用性です。現在の公開テストネットのパラメータでは、担保係数が78%、目標ヘルスファクターが1.24。ドキュメントの推定によると、ポジションが精算に“ちょうど触れる”時点で、目標として持ち去られる量はBTC価値の約62%です。Portalはリアルタイムのパラメータに基づき、より大きい犠牲Vaultを優先して並べ、残りのBTCは保護Vaultに入れます。精算手続きはリスト先頭から順にVaultを見ていき、最初の1つで足りればそこで停止し、2つ目はポジションに残ります。<br><br>つまりこれは「精算を防ぐ魔法のアイテム」ではなく、船室の防水扉に近い存在です。事故が起これば損失は出ますが、できるだけ“船全体を飲み込む”のを防ごうとするだけです。相場下落が速すぎる、犠牲Vaultのサイズが足りない、あるいは順序が間違っていると、システムが次のVaultまで連続して持ち去る可能性があります。また62/38は永久の公式ではなく、パラメータが変わればPortalが提示する分割を作り直す必要があります。<br><br>私はこの設計を「損失粒度管理」と呼ぶほうが好きです。借り手が本当に注視すべきなのは、ヘルスファクターだけでなく、自分のVaultサイズと並び順です。あなたは、2つ目の原生BTC Vaultを守るために、より複雑なポジション管理を受け入れますか？<br>#baby $BABY