stablecoin-analysis

ステーブルコイン分析

ステーブルコインの取引量に関する質問で最も重要な判断は、生の取引量か調整済みの取引量かです。ここを間違えると、その後の数値はすべて5～20倍ずれてしまいます。SQLを書く前に、これを読んでください。

生の取引量は実態以上に見えるため、調整済みの値を使う

1件ごとの送金テーブルには、CEX内部の送金、DeFiプロトコル内部の移動、MEV、ウォッシュ取引が含まれています。生の送金テーブルに対するSUM(usd_amount)で分かるのは「どれだけの価値が移動したか」であり、「実際の経済活動がどれだけあったか」ではありません。この2つは桁違いになることがあります。実際の普及状況や利用状況を分析するには、生のSUMではなく、エンティティ調整済みの取引量列（is_adjusted_volume、is_inorganic_sender／is_inorganic_receiver、is_mev_transferのようなフラグ、または事前集計済みのエンティティ調整済み指標テーブルを探してください）を使います。

ユーザーがすでに信頼しているチャートや数値を提示し、それに対して生の取引量を使ったクエリの結果が5～20倍高い場合、通常はクエリのバグではなく、生の取引量と調整済み取引量の差が原因です。SQLが間違っていると判断する前に、調整済み取引量のデータソースがないか確認してください。

合計値を信頼する前に、偽データや不正なデータのトークンがないか必ず確認する

ステーブルコインの取引量テーブルには、カタログに誤分類された非ステーブルコイントークンが含まれることがあります（実際に、Arbitrum上の「xy」というトークンは通貨がNULLで、見出しに使われた$16.65Tの取引量のうち$5.4Tを偽の取引量として占めていました。単一の不正トークンが報告合計の約1/3を占めていたことになります）。取引量の合計を示す前に、次の点を確認してください。

• トークンごとに内訳を確認し、市場での存在感に比べて取引量の割合が不自然に大きいもの、currencyがNULLまたは欠落しているもの、通常の日次パターンを大きく上回る単日の急増がないか探します。
• 徹底的な調査を求められた場合は、たまたま気づいたトークンだけでなく、取引量の0.1%を超えるすべてのトークンを実際に監査してください。実際の監査では、最初に見つかったものだけでなく、複数の不正トークン（1回の調査で5件）が見つかった例があります。

チェーン固有の二重計上の仕組み

• XRPL（RLUSDおよびその他のXRPL発行ステーブルコイン）：トラストライン／リップリングの仕組みにより、実際の送金1件につき2行（送信者→発行者、次に発行者→受信者）が出力されます。発行者アドレスを単純に除外しても解決しません。発行者の下流に財務・運用ウォレットがあり、取引量が引き続き水増しされるためです。transaction_hashごとにMAX(usd_amount)を使って重複を除去し、固定のアドレス除外リストではなく、非常に取引量が多く、相手先がちょうど1つであるという行動パターンから財務ウォレットを特定してください。
• Aptos：一部の資産（USDT）には、同じ基盤トークンに対して2つの有効なアドレスがあります。従来のCoinモジュールのアドレスと、新しいFungible Assetアドレスです。供給量・送金テーブルはそのうち一方（多くの場合、新しいFAアドレス）をキーにしているため、従来のアドレスを検索するとエラーではなく、何も返されません。
• メッセージングプロトコルのテーブルにあるブリッジ済みティッカー：トークンシンボルでブリッジ取引量を絞り込む場合は、LIKEやあいまい一致ではなく、完全一致を使ってください。ラップ済みトークンやデリバティブのティッカー（例：PT-USDG-28MAY2026、USDG0）は実際のシンボルと部分文字列が重複しており、あいまいなフィルターでは件数が気づかないうちに水増しされます。

アドレスの規則はチェーンごとに異なるため、どこでも同じルールを適用しない

結合やフィルタリングの前に、EVMアドレスは小文字に変換してください。Solana、Tron、Aptosのアドレスは小文字に変換しないでください。これらは大文字と小文字を区別するため、小文字に変換するとエラーではなく、結合結果が0行になります。

同じチェーン上でも、ネイティブとブリッジ済みの展開は別々の供給量

同じステーブルコインでも、1つのチェーン上にネイティブ発行分とブリッジ表現の両方が存在する場合があります（例：Polygon上のネイティブUSDCとブリッジ済みUSDC.e）。これらはアドレスも供給量も異なります。「Polygon上のUSDC」が1つの標準アドレスに対応すると決めつけず、クエリの対象とする展開を明示してください。

保有者と地理情報には適切なテーブルが必要であり、どちらのテーブルも単独では不完全です

• 「ステーブルコインを利用するウォレット」を調べるには、トランザクター ∪ 保有者が必要であり、どちらか一方だけでは不十分です。残高をすべて送金したウォレットはトランザクターですが、期末時点の保有者ではありません。一方、取引を一度もしない休眠中の保有者はその逆です。「利用」に関する質問に、片方だけで答えないでください。
• 残高／保有者テーブルは通常EVMのみを対象としています。SolanaやTronには、balances_daily形式に相当するテーブルがないことがよくあります。これらのチェーンの保有者数には、代わりにトランスファーに基づく推定が必要です。この制約は、黙って無視せず明記してください。
• 地域別に分ける場合は、UTCの時間帯を使った推定ではなく、実際のアドレス地理情報テーブル（取引所の入出金パターンから推定）を使用してください。「UTC 00:00～08:00の取引活動＝アジア」というのは粗い代理指標であり、実際の地域情報テーブルと食い違う可能性があります。地域情報テーブルはEVM／Tron／Solanaのみを対象とし、すべてのEVMチェーンが1つのバケットにまとめられていることがよくあります。結合する前に、対象のチェーン（ethereum、polygon、baseなど）をそのバケットに対応付けてください。そうしないと、結合結果が何も返されなくても気づけません。

ルーティング／DEXの取引量は流通残高の増加ではありません

ステーブルコイン発行者のトークンがDEXやソルバーの取引を通じてルーティングされる場合、その取引量は流通残高の増加とは異なります。次の点を区別してください。

• 純粋な通過 — 同一トランザクション／短期間内のミントとバーン。流通残高への純影響は約$0です。
• 在庫モデル — マーケットメーカーが運用在庫を保有し、流通残高は保有在庫に相当します。
• 真の普及 — エンドユーザーによる継続的な保有。

取引量やルーティング量のうち、#3に該当する割合は実際より大幅に多く見積もられます。普及や流通残高の増加について尋ねられた場合、この3つのどれを反映しているのか確認せずに、取引量だけで答えないでください。

---

データソース

各チェーンのデータベースには、それぞれ独自のstablecoinsスキーマ（<chain>.stablecoins.*。例：ethereum.stablecoins.transfers、solana.stablecoins.supply_change）があります。複数のチェーンにまたがるデータを扱う場合は、crosschain.stablecoinsではなく、専用のstablecoinsデータベースを優先してください。クロスチェーン集計の命名規則は独立したトップレベルデータベースに移行しています（発行者／ペッグ方式／分類のメタデータにはstablecoins.registry.catalog、調整済み取引量／オーガニックなアクティビティの分類にはstablecoins.intelligence.enriched_transfers、またそのデータにはstablecoins.core.transfersとstablecoins.core.balances_daily）。以前のセッションや記憶に頼って古いcrosschain.stablecoin.*名を使わないでください。この命名規則はすでに変更されています。

チェーンごとに、従来の<chain>.assets.stablecoin_transfersテーブルは廃止が進み、<chain>.stablecoins.transfersに置き換えられています。可能な限り、assetsスキーマのテーブルは避けてください。

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