lending-analysis

レンディング分析

レンディングのスキーマでは、アクティビティが単一の「レンディングイベント」テーブルにまとめられているのではなく、複数のイベントタイプ別テーブル（預け入れ／引き出し／借り入れ／返済／清算）に分かれています。よくあるミスのほとんどは、いずれか1つのテーブルだけをクエリするか、誤った方法で結合することが原因です。

対応範囲はAaveより広い一方、イベントタイプによって偏りがあります

レンディングテーブルは通常、代表的なプロトコルであるAaveだけでなく、Morpho Blue、Fluid、Euler、Mapleや、多数の派生プロトコルにも対応しています。デフォルトで「Aaveのみ」に対象を絞らず、まず実際の対応範囲を確認してください。

イベントタイプごとに対応範囲が一様とは限りません。たとえば、flashloansのように対象が限定されたテーブルは、より広範な預け入れ／借り入れテーブルが多数のプロトコルをカバーしていても、対応するプロトコルが一部に限られる場合があります（例：ネイティブのフラッシュローン機能を持つプロトコルのみ）。フラッシュローンのデータを一般的なレンディングアクティビティと結合する場合、対象プロトコルが暗黙のうちにflashloansの対応範囲に絞られることになります。そのことを明記してください。

「担保スワップ」や「債務スワップ」を示すテーブルはありません。結合して導き出します

担保スワップ、債務スワップ、レバレッジの追加／解除などのポートフォリオ管理操作には、明示的なイベントタイプがないのが一般的です。イベントタイプ別テーブルをtransaction_hashで結合し、どのテーブルの組み合わせでイベントが発生したか、またどのトークンが関わっているかを比較して検出します。

• 引き出し＋預け入れ（異なるトークン）、借り入れ／返済なし → 担保スワップ
• 返済＋借り入れ（異なるトークン）、預け入れ／引き出しなし → 債務スワップ
• 預け入れ＋借り入れ → レバレッジの追加
• 返済＋引き出し → レバレッジの解除

このため、「レンディング関連のあらゆる操作」の代わりにloansテーブルだけを使うと、大幅な過少計上になります。新たな借り入れはアクティビティの一部にすぎません。実際のポジション管理アクティビティの大部分（スワップ、レバレッジ解除、セルフ清算）は、loansテーブルには一切記録されず、他の3つのテーブルにのみ現れます。

通常、フラッシュローンが実行された「理由」（裁定取引、担保スワップ、ガバナンス関連の操作／エクスプロイトなど）を記録した専用テーブルもありません。上記と同じ結合手法で、他のテーブル（DEXの取引テーブル、ガバナンス関連の生ログのパターンなど）に同じtransaction_hashがあるかを確認して分類します。

結合のパフォーマンス：ハッシュで結合する前に日付で絞り込む

レンディングイベントテーブルは通常、transaction_hashではなくblock_timestamp::dateでクラスタリングされています。transaction_hashだけをキーにして複数のテーブルを結合し、上記のパターンを検出しようとしても、パーティションプルーニングが行われず、テーブル全体がスキャンされます。ハッシュで結合する前に、CTE内で各テーブルを対象の日付範囲に絞り込んでください。

テーブル間で列名に一貫性がありません。想定する前に確認してください

関連テーブルの列名から類推して名前を推測しないでください。命名規則は統一されていません。

• withdrawalsには「withdrawer」形式の列、depositsには「depositor」形式の列、loansには「borrower」形式の列が使われています。また、repaymentsには借り手の列と、別途返済者の列の両方がある場合があります。これらは異なることがあり、借り手に代わって第三者が返済できます。
• liquidationsでは、通常、トークンシンボル形式の列は差し押さえられた担保を指し、別の「返済トークン」列は返済される債務トークンを指します。どちらも「清算に関わるトークン」なので、取り違えやすい点に注意してください。
• USD列の名前は一貫しており（例：usd_amount）、特定のテーブルに大文字小文字や順序が異なる形式（amount_usd）があると、確認せずに想定しないでください。

取引量で順位付けする場合：NULLを除外し、順位を押し上げないようにする

信頼できる価格フィードがない資産（エキゾチックなプリンシパルトークンや利回り付きラッパートークンがよくある例）は、実際の取引件数が多くても、USD金額がNULLになることがあります。usd_amount IS NULLを先に除外せずに「取引量または件数の上位資産」を順位付けすると、価格結合が欠けているだけで、実際に小規模だからではないにもかかわらず、こうした資産が主要なステーブルコインやETHなどの本当に大規模な資産を、上位N件のリストからひそかに押し出す可能性があります。

利用率：プロトコル全体だけでなく、資産ごとに計算する

プロトコル全体の加重平均利用率は、中程度（例：約45％）に見えても、その中の個別市場では利用率がほぼ100％に達している場合があります（よくあるのはステーブルコインやETHで、借入需要が最も高い資産です）。「この市場の流動性は逼迫しているか」という問いに答える場合は、プロトコル全体の集計値だけを当てにせず、トークンでグループ化した市場粒度のテーブルを使って、資産ごとに利用率（outstanding_loans_usd / supplied_amount_usd）を算出してください。

TVL／メトリクスのテーブルは単純な直線のパイプラインではなく、必ずしも値が一致しません

よくある構成では、粒度の細かい市場レベルのテーブル（プロジェクト + プロトコル + トークン + 市場、日末時点で補間）から、兄弟関係にある2つの集計テーブルが別々に作られます。1つは独自のTVL形式の数値を持つプロトコルレベルの「レンディングアクティビティ」テーブル、もう1つはトークンレベルのオンチェーン残高／TVLの生データテーブルです。これらは、同じ数値を異なる方法で計算したものではありません。同じ日、同じプロジェクトで比較したところ、両者には数％の差が見られました。おそらく、各パイプラインで価格付けやタイミングが異なるためです。分析ごとにTVLのデータソースを1つ選び、一貫して使ってください。分析の途中で両者を混在させたり、平均したりしないでください。

クロスチェーンの正規化

EVMチェーンで確立された列の慣例（例：どの種類のレンディング操作が発生したかを示すイベントタイプ列）が、そのまま非EVMチェーン（Solana）では相当するものが存在しないことを意味するわけではありません。欠落していると決めつけず、スキーマ検索で確認してください。クロスチェーン／統合されたレンディングテーブルでは、各チェーン独自のスキーマのテーブル構造が上流で異なっていても、そのフィールドがすべてのソースチェーンで完全に入力されている可能性が高いため、ソースチェーンごとの前提をハードコードするより、クロスチェーンテーブルから直接選択することをおすすめします。

清算の約定：結合の両側でカーディナリティを確認する

1つの清算イベントが、同じ（user、asset、timestamp）キーを共有する複数の部分約定によって約定される場合、約定レベルの行をイベントレベルのテーブル（清算イベントごとに1行、例：差し押さえた担保の合計）に直接結合すると、行が増殖し、イベントレベルのフィールドが追加の約定ごとに1回ずつカウントされて二重計上されます。結合前に、約定データを（user、asset、timestamp）単位でSUM/COUNTを使って事前集計してください。

これは清算に限らない、約定データとイベントデータ間のカーディナリティ不一致です。キーごとに複数行あるテーブルをキーごとに1行のテーブルへ結合する場合は、二重計上の修正が完了したと判断する前に、両側でカーディナリティ（それぞれで COUNT(*) GROUP BY key）を確認してください。「イベントレベル」側にも想定外の重複があり、逆に過小評価を引き起こす可能性があります。片側だけのカーディナリティ確認では、これを見落とすことがあります。

---

データソース

各チェーンのデータベースには、それぞれ独自の lending スキーマ（<chain>.lending.deposits、 withdrawals、loans、repayments、liquidations、markets_daily、metrics_daily）があります。DEXと同様、レンディングにはまだ専用のクロスチェーンデータベースがありません。複数のチェーンにまたがる質問には、チェーンごとのテーブルを手作業で統合するのではなく、crosschain.lending 配下のマルチチェーン統合ビュー（crosschain.lending.metrics_daily、tvl_daily、repayments、およびその他のイベントタイプごとのテーブル）を使用してください。

このスキーマの進化に伴い、テーブル名や列名は変わるため、上記の名前を記憶に頼ってハードコードしないでください。まず data-matching を実行して、質問に該当する現在のテーブルを確認してください。SQLを書く前に列を再確認する必要がある場合は、search_schemas／search_docs を直接使ってください。