なぜ分散型金融は症状を扱い、原因を扱わないのですか？
パッチソリューションは効果的に見えます。
モデルはより困難です。
分散型金融で故障が発生した場合、通常は迅速に対応されます。
保証の割合を増やします。
基準を修正します。
新しい予防措置を追加します。
この手続きは責任があるようです。
問題が再発するまで。
ここで通常、故障が発生します。
明確ではなく、静かに。
一般的な仮定は、故障が誤った設定に起因するというものです。
数字を調整すれば、安定が実現します。
これは理にかなっています。
弱点がさまざまな形で現れ続ける限り。
まだこれについて考えています:
なぜ解決策は常に損害が明らかになった後に来るのか？
ほとんどの分散型金融システムは結果に反応します。
清算が増加し、しきい値が動きます。
ボラティリティが上昇し、安全な期間が拡大します。
流動性は低下し、インセンティブは増加します。
これが解決策です。
診断ではありません。
症状は変わります。
理由は残ります。
基本的なモデルが疑問視されることはほとんどありません。価格に基づく仮定はそのままです。
リスク管理のフレームワークは変わらず残ります。
流動性は依然として信頼できる資本として扱われています。
だから、システムはより安全に見えます -
状況が変わるまで。
最近の圧力イベントの間に、私たちはすでにこのプロトタイプを目にしました。
原因に対処するには、ゆっくり考える必要があり、実行ではありません。
これは、数値が変わる前に行動が変わる理由についての疑問を意味します。
なぜ流動性は価格が動く前にためらったのか？
なぜインセンティブは圧力が現れたときに耐えられなかったのか？
この種の作業はダッシュボードでは見えません。
迅速に達成されるわけではありません。
それは急場しのぎの解決策のようには見えません。
最近のいくつかのアプローチは、失敗を修正することにあまり焦点を当てていません。
そして、それがどのように形成されるかを理解することがより重要です。
それは行動を見ており、ただの転換点だけを見ているわけではありません。
価格だけでなく、評価にも。
APROはこの考え方に適合します。
他の解決策のようには。
むしろ、何が起こっているかをシステムが解釈する方法の変化です。
修正する前に急ぐのではなく。
ここには結論がありません。
時には、真の問題は分散型金融（DeFi）の機能不全にありません。
むしろ、私たちが故障したものを修理し続けることに。
理解するのではなく、
主にそれが機能しなかった理由。
@APRO Oracle#apro $AT