dex-analysis

DEX 分析

DEX 分析で最もよくある間違いは、間違ったテーブルを使うことではありません。ホップ単位やサイド単位のデータモデルを、スワップ単位または取引単位であるかのように扱うことです。集計する前に、テーブルの粒度を確認してください。

取引の行はスワップ単位ではなく、ホップ単位であることがよくあります

マルチホップルート（A→B→C）では、ユーザーが1回のスワップとして体験したものが、2～3行の取引データになることがあります。これにより、取引量と行数の両方が膨らみます。あるチェーンで行われた特定の比較では、ホップによる行の増加だけで、外部ソースと比べて約1.3倍に膨らんでいました。

• 取引量や件数の合計を信頼する前に、取引テーブルで COUNT(*) と COUNT(DISTINCT transaction_hash) を比較してください。両者に大きな差がある場合、マルチホップによる行の増加が発生している可能性があります。
• 外部アグリゲーター（DefiLlama など）と取引量を比較する場合は、観測されたホップ比で割るか、まず transaction_hash の粒度で集計してください。

AMM の計算に関する質問では protocol で、ブランドに関する質問では project でグループ化する

protocol と project は異なる質問に答えるもので、しばしば混同されます。

• project はブランド化されたプロダクトを識別します（例：「PancakeSwap V2」）。
• protocol は基盤となる AMM の実装を識別します（例：PancakeSwap V2 は Uniswap V2 の直接的なフォークであるため、どちらも protocol = 'uniswap_v2' になります）。

質問の本質が AMM の仕組みに関するものであれば、常に protocol を使ってください。たとえば、インパーマネントロスはブランドではなく価格曲線に依存します。IL 分析を project でグループ化すると、同じ計算方式のプール（Uniswap V2 とそのフォーク）が別々の区分に分割され、本来はひとつにまとめるべきものが分かれてしまいます。

「スワップらしい」形式のすべての取引所で、同じ仕組みが使われているとは限りません。

• PumpSwap ≠ Pump.fun のボンディングカーブです。 これらは同じトークンのライフサイクルにおける連続した段階であり、同じプロダクトではありません。ボンディングカーブの段階にはインパーマネントロスの概念がそもそもありません（外部 LP が存在しないためです）。インパーマネントロスが発生するのは、卒業後の PumpSwap プールだけです。
• V3／集中流動性の IL は、V2 の IL を単純にスケールしたものではありません。 tick_lower／tick_upper の範囲が狭いほど、その範囲に依存する集中係数によって IL と手数料収入の両方が増幅されます。V3 のポジションに V2 の単純な IL 公式を適用すると、概算ではなく、誤った結果になります。
• Pendle の PT／YT／SY／LP ポジションは、dex ではなく yields 系のスキーマにあります。 DEX の取引／流動性テーブルで Pendle を探さないでください。

アグリゲーターの取引では、基本フィールドの取得に結合が必要なことが多く、手数料はトークン転送として記録されています

アグリゲーターの取引テーブル（0x、1inch など）には、通常の取引テーブルならあると思われるフィールドが欠けている場合があります。たとえば、小数桁数の列やスワップ件数の列がないことがあります。小数桁数を取得するにはトークンのメタデータテーブルを結合し、列が存在すると想定するのではなく、COUNT(*) OVER (PARTITION BY transaction_hash) でスワップ件数を導出してください。結合先が名前空間付きの転送テーブルであること（似た名前の名前空間なしテーブルではないこと）を再確認してください。また、厳密な精度が必要な場合は、事前に小数桁数で調整された列ではなく、未加工の整数値の金額列を使ってください。

アグリゲーターの暗黙的な手数料やサープラスは、名前付きの列としては記録されていません。これを再構築するには、取引の買い側または売り側のトークンに関する ERC20 転送を探します。転送元はアグリゲーターのエントリーコントラクトで、転送先はテイカーでも内部プール／ルーターのコントラクトでもないアドレスです。この残余分が手数料です。該当するサイドのトークンの小数桁数を使って調整してください。

比率を信頼する前に妥当性を確認する

• 記録された TVL がほぼゼロの場合、資本効率（取引量／TVL）は無限大に近づきます。 通常は、実際に無限の効率があるのではなく、そのプロトコルにおける TVL のインデックス化が不完全であることを示します。TVL の最低しきい値を設けて比率をガードし、しきい値を下回る場合は未加工の除算結果を報告するのではなく、null を返すかフラグを設定してください。
• 取引サイズの平均値と中央値に大きな差がある場合は、通常とは異なる取引所である可能性があります。 少数の大口機関取引によって平均値が偏るのは、DEX データに流動性ステーキングやトレジャリー管理のプロトコルが含まれている場合によく見られる特徴であり、「一般的な」個人向けスワップ取引所の特徴ではありません。取引サイズの分布が質問に関係する場合は、平均値だけでなく中央値も確認してください。

Perp-DEX（Hyperliquid 形式）の特記事項

• 生の約定テーブルは通常、約定の片側ごとに1行（買い手側に1行、売り手側に1行）あり、各行にテイカー／メイカーのフラグが付いています。片側ごとのテーブルで両方のカウンターパーティが1行に記録されると想定しないでください。両側をまとめて確認する必要がある場合は、取引ごとに1行で、両方のカウンターパーティのアドレスが記録された取引レベルのテーブルを使用します。
• 約定は片側ごとに記録されるため、すでにユーザーごとに集計している場合は、SUM(size)を2で割らないでください。「2で割る」補正が必要なのは、取引が買い手側と売り手側の両方の行から数えられる、市場全体を集計する場合に限られます。1人のユーザーの約定に絞り込んで集計すれば、そのユーザーの出来高はすでに重複なく数えられています。
• 「ビルダー」に帰属するフロー（ボット、アグリゲーター、コピートレードのフロントエンドなど、第三者による注文フローの送信者）は、通常、自動化されていて積極的に注文するもので、受動的な指値注文ではないため、テイカー注文に大きく偏っています。ビルダーフローを一般的な個人投資家のフローと同じように扱わないでください。
• 大規模なパーペチュアル取引テーブルをユーザーごとに集計する長期間のルックバック（例：12か月）は、ウェアハウスのステートメントタイムアウトに達することがあります。最初の確認では短めの期間（3～6か月）に絞ってから、全期間での集計に進んでください。特に「月に$1000以上取引するユーザー」のような、しきい値に関する質問では注意が必要です。

価格データの注意点

Allium の DEX 由来トークン価格は通常、異常値を除外して純粋なアービトラージによる急騰を取り除いた、短い間隔（例：1分）の VWAP です。1分未満の間隔で連続して同じ価格が返される場合、その期間に新たな取引がなかったことを示すのが一般的です（API が最後にキャッシュした価格を返しています）。データの不具合ではありません。この現象は、中央集権型取引所の基礎資産に比べてオンチェーンでの取引頻度が大幅に低い、流動性の薄いラップドアセットで最も顕著です。そのため、CEX と DEX の間に価格差が継続していても、エラーとは限りません。

DEX 横断のペア集計

取引方向（A→B と B→A）にかかわらずペアごとに1つの数値が必要な場合（A→B と B→A は同じペアです）、ペアのラベルを正規化します。たとえば、LEAST(token_sold_symbol, token_bought_symbol) || '/' || GREATEST(...)を使うと、両方向をまとめて集計でき、別々のペアとして表示されません。「上位ペア」のランキングを信用する前に、トークンシンボルが未解決で、ペアのラベルがnullになっていないか確認してください。

---

データソース

各チェーンのデータベースには、それぞれ独自のdexスキーマがあります（<chain>.dex.trades、<chain>.dex.pools、<chain>.dex.liquidity_positionsなど）。ステーブルコインやRWAとは異なり、DEX にはまだ専用のクロスチェーンデータベースがありません。複数のチェーンにまたがる質問には、チェーンごとのテーブルを手動で結合するのではなく、crosschain.dex配下のマルチチェーン統合ビュー（crosschain.dex.trades、EVM 向けに最適化されたcrosschain.dex.trades_evm、およびアグリゲーター版のcrosschain.dex.aggregator_trades／aggregator_trades_evm）を使用してください。

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