#baby $BABY 公式の借入説明書の中である1語を切り出してみて初めて、TBVの「シンプルさ」自体が1つの境界線だと気づきました。Babylon Core Spoke では、担保記録は1種類しかありません。
@BabylonLabs_io のドキュメントはとても具体的です。現在のポジションにおける担保係数は固定です。コアの貸し借りエリアにはBTC担保しかないためです。もしある市場が複数の担保資産を同時に受け入れるなら、異なる資産ごとに加重計算を行う必要があります。TBVはそのため、パラメータ判定が1段減っており、ユーザーが見る健康度を説明しやすく、プロトコル側も、資産のバスケット同士のリスク加重を先に処理する必要がありません。
しかし、この簡潔さは無料ではありません。BTCだけを保有している借り手ならルールを理解しやすい一方で、手元にステーブルコイン、イーサ、またはその他の資産があっても、それらを同一のポジションにまとめて入れられず、単一担保資産がもたらす圧力を分散できません。安全余裕を増やすためにできる主な手段は、負債を減らすか、BTCを追加することです。
ストレス場面には複雑な市況は要りません。ユーザーにはすでにBTC担保の借入があるのに、後から別の資産で補足したいと思っても、その資産が同じ担保記録に入れられないことがわかる、というケースです。ここでの問題は、ユーザーが健康度を理解できないことではなく、プロダクトがそもそも第2の資産選択肢を用意していないことにあります。資本効率もリスク計算も、BTC側に固定されてしまっています。
だから私は、TBVの現行設計に対してこう判断しています。TBVはまず、読みやすく、コントロール可能な単一担保モデルを優先して実装しました。しかしそれだけでは、より幅広い借り手に適していると証明できたわけではありません。$BABY の後に注目すべきなのは、パラメータ表が長くなるかどうかではなく、新しい担保資産が登場したとき、プロトコルが加重ルールを今と同じくらい分かりやすく説明できるかどうかです。
@BabylonLabs_io のドキュメントはとても具体的です。現在のポジションにおける担保係数は固定です。コアの貸し借りエリアにはBTC担保しかないためです。もしある市場が複数の担保資産を同時に受け入れるなら、異なる資産ごとに加重計算を行う必要があります。TBVはそのため、パラメータ判定が1段減っており、ユーザーが見る健康度を説明しやすく、プロトコル側も、資産のバスケット同士のリスク加重を先に処理する必要がありません。
しかし、この簡潔さは無料ではありません。BTCだけを保有している借り手ならルールを理解しやすい一方で、手元にステーブルコイン、イーサ、またはその他の資産があっても、それらを同一のポジションにまとめて入れられず、単一担保資産がもたらす圧力を分散できません。安全余裕を増やすためにできる主な手段は、負債を減らすか、BTCを追加することです。
ストレス場面には複雑な市況は要りません。ユーザーにはすでにBTC担保の借入があるのに、後から別の資産で補足したいと思っても、その資産が同じ担保記録に入れられないことがわかる、というケースです。ここでの問題は、ユーザーが健康度を理解できないことではなく、プロダクトがそもそも第2の資産選択肢を用意していないことにあります。資本効率もリスク計算も、BTC側に固定されてしまっています。
だから私は、TBVの現行設計に対してこう判断しています。TBVはまず、読みやすく、コントロール可能な単一担保モデルを優先して実装しました。しかしそれだけでは、より幅広い借り手に適していると証明できたわけではありません。$BABY の後に注目すべきなのは、パラメータ表が長くなるかどうかではなく、新しい担保資産が登場したとき、プロトコルが加重ルールを今と同じくらい分かりやすく説明できるかどうかです。