不良債権とは何ですか?一般的に理解される「投資損失」とどう違いますか?
不良債権とは、過剰担保融資プロトコルにおいて、ある借入ポジションの担保の実際の市場価値がすでに返済すべき借入額を下回り、担保をすべて現金化しても対応する債務を返済するには不十分な状態になることを指す。過剰担保メカニズムの本来の設計は、担保の価値が借入額を「超える」ことを要求するものだからだ(150ドルを担保にして100ドルしか借りられないなど)。通常の状況では、この緩衝の余地は価格変動に対応するのに十分なはずで、清算メカニズムが担保の価値が借入額を下回る前にポジションを決済する機会がある。不良債権の出現は、この緩衝メカニズムがある瞬間機能しなくなったことを意味する。
一般的に理解される「投資損失」との最大の違いは「誰が損失を負うか」にある:一般的な投資損失は通常投資家自身が負い、どれだけ損をするかは投資家自身の問題であり、他人に直接波及することはない。不良債権はこれとは異なり、ある借入ポジションに不良債権が発生すると、この穴は何もないところから消えるわけではなく、プロトコル全体の資産(通常預金者が共同で保有する資金プールから)によって吸収される必要がある。これはその特定の融資取引に直接参加していなかった他の預金者も、この不良債権によって間接的な損失を負う可能性があることを意味し、これが不良債権が融資プロトコルにおいて最も真剣に扱われるべきシステミックリスクの一つと見なされる理由でもある。
不良債権はなぜ発生するのですか?背後にある原因にはどのようなものがありますか?
いくつかの一般的な不良債権の原因:
これらの原因はしばしば同時に重なって現れ、本当に深刻な不良債権事件は、単一の原因によるものではなく、複数の要素が同時に機能不全に陥った結果であることが多い。
不良債権が発生した後、プロトコルは通常どう対処しますか?具体的な対処プロセスはどのようなものですか?
典型的な不良債権の対処プロセスにはいくつかの段階がある:
この一連のプロセスが順調に実行できるか、処理結果が公平で合理的かは、プロトコルのガバナンスメカニズムの成熟度と透明性に大きく依存する。
不良債権は一般ユーザーにとって実際どのような影響がありますか?預金前にこのリスクをどう評価すればよいですか?
預金者にとって、不良債権の最も直接的なリスクは:自分自身の預金操作がまったく正常で、いかなる問題のある融資取引にも関与していなくても、プロトコル全体に不良債権が発生することで、元本を全額償還できない損失を被る可能性があるということだ。この「連座」的な性質のリスクは、過剰担保融資プロトコルという資金プール共有モデルの固有の特性であり、どの融資プロトコルを評価する際にも真剣に考慮すべきシステミックな要因である。
預金前に検証する価値のあるいくつかの具体的な指標:このプロトコルがサポートする担保資産の種類、そのボラティリティと流動性の深さはどうか——サポートする資産が多様であるほど、ボラティリティが極めて高いか流動性の浅いロングテール資産を含むほど、全体的な不良債権リスクは通常高くなる;プロトコルの清算メカニズムの設計の成熟度、清算報酬の設定が合理的か、操作耐性のあるオラクル設計(以前の記事で紹介したTWAPメカニズムなど)を採用しているかを含む;プロトコルが第一の防衛線として保険基金を持っているか、そしてこの基金がプロトコル全体のリスクエクスポージャーに対して十分な比率であるか;そしてプロトコルが過去に不良債権イベントを経験したことがあるか、もしあれば事後の処理方法が公平で透明であったか、根本原因に対処する具体的な仕組みの調整が行われたか。これらの詳細を合わせることで、単に表示される預金の年利回りを見るよりも、極端な状況下でのあなたの元本の実際の安全性をよく反映できる。
2020年3月、「ブラックサーズデー」として知られる暗号資産市場の激しい暴落期間中、融資プロトコルのMakerDAOはイーサの価格が瞬時に暴落したことに加え、ネットワークが深刻に混雑し清算取引がタイムリーにオンチェーンで確認できなかったため、約400万ドルの不良債権の穴を蓄積した。一部の清算オークションはゼロに近い価格で約定することさえあった。事後プロトコルはガバナンストークンの追加発行のオークションを通じて資金を調達し穴を埋め、この事件はまたMakerDAOがその後清算メカニズムの設計を大幅に調整するきっかけとなり、より洗練されたオークションプロセスと価格保護メカニズムの導入を含んでいた。
これはシステミックリスクの用語であり、前向きなトレードオフというものは存在しない——不良債権はプロトコルと預金者にとって純粋な損失である。唯一議論できるトレードオフは:より保守的な担保率要件とより厳格な資産ホワイトリストは不良債権の発生確率を下げられるが、代償として資金効率が低下し、サポートできる資産の種類が限定されることである。これはプロトコル設計段階でのトレードオフであり、ユーザーが一方的に変えられる選択ではない。ユーザーができることは主にプロトコルの清算メカニズムの成熟度と保険基金の規模を検証し、リスク管理設計が比較的堅実なプロトコルを選ぶことである。