#TermMax @TermMax $BOME $BTW $HANA
私はTermMax Vaultのシナリオを見ていて、最初は回収された担保があることで問題は基本的に解決したのだと思いました。
しかし、そんなに単純ではありません。
通常の返済ルートに従わず、現物の引き渡しが行われると、回収された担保がERC-4626の持分(シェア)の下にあるTermMax Vaultの中に残ってしまうことがあります。これは前向きに聞こえるでしょう――しかし、実際に引き出し(withdrawal)リクエストが必要としているものを見ると話は別です。
Vaultには回収された担保があるかもしれないのに、ユーザーはまだまったく別の引き出し資産が届くのを待っています。一番大事な点は、担保がVault内に戻ったとしても、それが自動的に引き出しキュー(withdrawal queue)が要求している資産に変換されるわけではないことです。
つまり、道は2つあります。
要求された資産の十分な流動性が到着して、引き出しを処理できるのを待つ。
または、ERC-4626のシェアを焼却して、代わりに引き渡された担保を受け取る。
そして2つ目の選択肢は、問題を別の場所へ移すだけです。
引き出しキューは解消されるかもしれませんが、回収された担保は、別の市場を通じて、しかも別の価格で売却が必要になる可能性があります。ユーザーは本来、その担保の売却を最初から要求していなかったのです。
この違いこそが、私の注意を引きました。私がTermMaxの設計で特に注視しているのはまさにこの部分です。 #BinanceSquareTalks #termmax登上借贷赛道王者
私はTermMax Vaultのシナリオを見ていて、最初は回収された担保があることで問題は基本的に解決したのだと思いました。
しかし、そんなに単純ではありません。
通常の返済ルートに従わず、現物の引き渡しが行われると、回収された担保がERC-4626の持分(シェア)の下にあるTermMax Vaultの中に残ってしまうことがあります。これは前向きに聞こえるでしょう――しかし、実際に引き出し(withdrawal)リクエストが必要としているものを見ると話は別です。
Vaultには回収された担保があるかもしれないのに、ユーザーはまだまったく別の引き出し資産が届くのを待っています。一番大事な点は、担保がVault内に戻ったとしても、それが自動的に引き出しキュー(withdrawal queue)が要求している資産に変換されるわけではないことです。
つまり、道は2つあります。
要求された資産の十分な流動性が到着して、引き出しを処理できるのを待つ。
または、ERC-4626のシェアを焼却して、代わりに引き渡された担保を受け取る。
そして2つ目の選択肢は、問題を別の場所へ移すだけです。
引き出しキューは解消されるかもしれませんが、回収された担保は、別の市場を通じて、しかも別の価格で売却が必要になる可能性があります。ユーザーは本来、その担保の売却を最初から要求していなかったのです。
この違いこそが、私の注意を引きました。私がTermMaxの設計で特に注視しているのはまさにこの部分です。 #BinanceSquareTalks #termmax登上借贷赛道王者
