TBVのいちばん面白いアイデアは「借り入れボタン」ではない
私にとってTBVのいちばん興味深い部分は、借り入れボタンではありません。それは清算（リクイデーション）オーダーです。現在のパブリック・テストネットでは、TBVは意図的にバウチャー（vault）を小さく保ちます：最低バウチャーサイズは0.01 BTC、最大バウチャーサイズは0.4 BTC、ポジションは最大10のバウチャーを使用可能、BTC担保ファクターは78%で、ヘルスファクターが1.0を下回ると清算が開始されます。TBVは、ラップやブリッジなしでBitcoin上にBTCをロックし、Aave v4はその上に登録された最初のDeFiアプリです。
私が特に目を引かれたのは、BabylonがBTCそのものをどう構成させようとしているかです。ドキュメントでは、まず「犠牲（サクリファイス）のバウチャー」を用意し、次に「保護されたバウチャー」を用意することが推奨されています。清算が発生した場合、プロトコルはバウチャーを順番に辿り、目標のヘルスファクターを回復するために必要な最小限の量だけを差し押さえます。保護されたバウチャーは無傷のままにできます。さらに、市場環境が変われば後からバウチャーの順序を入れ替えることさえ可能です。これは、よくある「小さく動いただけで全部が終わる」タイプの担保モデルとはまったく違って感じられます。
だからTBVは、私の中では融資デモよりも大きく見えます。BTCバウチャーはpeg-inの時点で1つのアプリのために作成され、その後別のアプリへ移すことはできません。つまり担保は「借りられる」だけのものではなく、目的をもって段階付け（ステージング）されているのです。私は借り入れ画面の“どれだけBTCが使えるか”よりも、その点に何度も立ち返ってしまいます。大事なのは、BTCを使えるかどうかではなく、ポジションが間違った方向へ動き始めたときに、そのうちどれだけが生き残れるのか、ということです。DYOR。
@BabylonLabs_io #baby $BABY
私にとってTBVのいちばん興味深い部分は、借り入れボタンではありません。それは清算（リクイデーション）オーダーです。現在のパブリック・テストネットでは、TBVは意図的にバウチャー（vault）を小さく保ちます：最低バウチャーサイズは0.01 BTC、最大バウチャーサイズは0.4 BTC、ポジションは最大10のバウチャーを使用可能、BTC担保ファクターは78%で、ヘルスファクターが1.0を下回ると清算が開始されます。TBVは、ラップやブリッジなしでBitcoin上にBTCをロックし、Aave v4はその上に登録された最初のDeFiアプリです。
私が特に目を引かれたのは、BabylonがBTCそのものをどう構成させようとしているかです。ドキュメントでは、まず「犠牲（サクリファイス）のバウチャー」を用意し、次に「保護されたバウチャー」を用意することが推奨されています。清算が発生した場合、プロトコルはバウチャーを順番に辿り、目標のヘルスファクターを回復するために必要な最小限の量だけを差し押さえます。保護されたバウチャーは無傷のままにできます。さらに、市場環境が変われば後からバウチャーの順序を入れ替えることさえ可能です。これは、よくある「小さく動いただけで全部が終わる」タイプの担保モデルとはまったく違って感じられます。
だからTBVは、私の中では融資デモよりも大きく見えます。BTCバウチャーはpeg-inの時点で1つのアプリのために作成され、その後別のアプリへ移すことはできません。つまり担保は「借りられる」だけのものではなく、目的をもって段階付け（ステージング）されているのです。私は借り入れ画面の“どれだけBTCが使えるか”よりも、その点に何度も立ち返ってしまいます。大事なのは、BTCを使えるかどうかではなく、ポジションが間違った方向へ動き始めたときに、そのうちどれだけが生き残れるのか、ということです。DYOR。
@BabylonLabs_io #baby $BABY