bridge-analysis

ブリッジ分析

ブリッジの送金テーブルは、設計上、非対称です。送金の両方のレッグが常に記録されるわけではありません。合計する前に、方向性のモデルを正しく把握してください。

ブリッジの送金テーブルに記録されるのは、必ずしも両方のレッグではなく、正味の単方向フローです

正確なカバレッジの形は、ブリッジの種類によって異なります。

• Ethereum 上の標準的なブリッジでは、通常、流入と流出の両方の行が記録されます。
• アプリケーションレベルのブリッジや、Ethereum 以外のチェーン上のブリッジ活動では、通常、送金を開始したチェーンからの流出レッグのみが記録されます。

これはカバレッジの欠落ではなく、二重計上を防ぐための意図的な設計です。ただし、クエリ対象のチェーンとブリッジの種類の組み合わせによって、SUM(usd_amount) の挙動が異なるということです。テーブル内にすべての送金について流入と流出のペアが存在すると決めつけず、合計する前に、対象のブリッジ／チェーンで実際にどの direction 値が存在するかを確認してください。

対象チェーンを 2 つ以上に絞り込むと、単一チェーンのフィルターにはない二重計上の落とし穴があります

ブリッジフローを対象チェーンのリスト（例：「ethereum、arbitrum、base 間のフロー」）に絞り込み、ある送金の両端がそのリストに含まれている場合、その送金は WHERE 句を 2 回満たすことがあります。送信元チェーンの流出行と、送信先チェーンの流入行です。その結果、SUM(usd_amount) が過大になります。

• 送信元と送信先の両方が対象に含まれる送金は、他の送金とまとめて合計するのではなく、特別なケースとして扱ってください。
• 複数チェーンをまたぐ単一の数値が必要な場合は、安全なクロスチェーン集計として net_flow_usd（流入 − 流出）を優先してください。同じ送金が両側に対称的に計上されて相殺されるため、二重計上が起きる状況でも正しい値が得られます。

1 つのプロトコルを正しく切り分ける

統合／クロスチェーン送金テーブルから特定のブリッジプロトコルの取引量を取得するには、両方のフィールドがある場合、汎用的な bridge フィールドではなく、プロトコル識別フィールド（一般に protocol という名前）で絞り込んでください。特に Circle の CCTP のようなプロトコルを切り分ける場合、通常、protocol のほうが粒度が細かく、信頼性の高いフィルターです。大文字と小文字を区別せずに照合してください。

1 つのプロトコルの取引量を報告する際は、単独の絶対値ではなく、意味のある分母に対する割合として示してください（例：プロトコルの取引量 ÷ 対象資産のクロスチェーン総取引量、または ÷ ブリッジ取引量全体）。関係者がプロトコルの普及状況を判断する際に実際に用いるのはこの指標であり、単純なドル建ての数値よりも、時間の経過に対して安定した指標です。

ブリッジの識別情報はオンチェーンから導き出せますが、インテグレーター／アグリゲーターの帰属情報は導き出せません

すべてのブリッジ送金のプロトコル（コントラクトアドレス＋イベント署名 → レジストリのマッピング）は、オンチェーンデータだけで特定できます。一方、トランザクションをどこがルーティングしたか、つまりどのフロントエンドやアグリゲーターが送金を開始したか（ブリッジ独自の UI、ウォレット組み込みのブリッジ機能、サードパーティのアグリゲーターなど）は、一般に標準化されたオンチェーンフィールドではありません。また、別種の二重計上を避けるため、統合送金テーブルでは「aggregator」専用の列が意図的に除外される場合もあります。SQL だけで「この送金をどこがルーティングしたか」に答えられるとは考えないでください。その情報には、オフチェーン API／分析データ、インテグレーターパラメーターを追加するコントラクトレベルの変更、または維持管理されているアグリゲーターコントラクトのレジストリを用いたヒューリスティックな tx.to／コールスタックのトレースが必要です。いずれの場合も、通常のクエリより大掛かりな作業であることを明示してください。

直接結合キーがない場合に特定の送金を追跡する

一部のレッグは、チェーンごとのブリッジ送金テーブルに記録されていません。最もよくあるのは、EVM ネイティブではないレッグ（例：Bitcoin を送信元とする送金が EVM チェーンにブリッジされる場合）です。この場合、ブリッジイベントは送信先側でのミントとしてのみ記録され、送信元チェーンの未加工トランザクションへの上流リンクはありません。

直接結合キーを使わずに、この種のロック・アンド・ミントのフローを追跡する一般的な手順は次のとおりです。

1. 関連する未加工テーブルから、送信元チェーンの金額とタイムスタンプを取得します。
2. 送信元のタイムスタンプの少し後の短い時間枠で、送信先チェーンのラップドトークン送金からミント（from_address = ゼロアドレス／バーンアドレス）を検索します。
3. ブリッジの手数料許容範囲（通常は数ベーシスポイント）内で金額を照合します。手数料があるため、金額の完全一致では通常見つかりません。

両側を結び付けるデコード済みブリッジイベントがどちらにもない場合（例：記録されたブリッジトランザクションとは無関係にラップドアセットがミントされた場合）は、送金レベルの結合を無理に行わないでください。代わりに、エンティティマップ（エンティティ、チェーン、アドレス、タイプ、信頼度）を作成し、各側で相関はあるものの独立したアクティビティをフロープロキシとして追跡します。これは一致したトレースではなく、相関を示す証拠として提示してください。

手数料／ガスの帰属

ブリッジによって開始されたミントやリレーに伴う送信先側のガス代は、通常、受取人ではなくブリッジのリレイヤーアドレスが支払います。ブリッジの経済性を再構成するときや、特定ユーザーの送金の手数料内訳を作成するときに、このガス代をエンドユーザーに帰属させないでください。

データ提供面ごとのカバレッジの不足

未加工 SQL テーブルではなく Allium の Wallet API を使う場合は、そこで提供されるクロスチェーン／ブリッジのアクティビティタイプは、一般に EVM のみに限られることに注意してください。Solana および Bitcoin 側のブリッジアクティビティは、エンリッチ済みアクティビティフィードに表示されないことがあり、代わりに未加工テーブルを直接追跡する必要があります（上記を参照）。

---

データソース

ブリッジデータは2か所にあります。各チェーンデータベースにはそれぞれ独自の bridges スキーマ（<chain>.bridges.*）があり、さらにクロスチェーンのロールアップと比較用に共有の crosschain.bridges スキーマもあります。複数のチェーンにまたがるデータを扱う場合は、チェーンごとのテーブルを手作業で結合するのではなく、crosschain.bridges を優先してください。

どちらのスキーマでも、アクティビティは3つの異なるカテゴリに分かれています。これらを同じものとして扱わないでください。

1. ブリッジ — 価値を直接移動する標準的なブリッジおよびアプリケーションレベルのブリッジ（ロック・アンド・ミント、バーン・アンド・ミント、流動性プール型ブリッジ）。
2. メッセージングプロトコル — 汎用メッセージパッシング基盤（例：LayerZero、Wormhole、CCIP）。価値移転を実行できますが、それ自体はブリッジではありません。メッセージが送られても対応する送金が行われるとは限らず、その逆も同様です。
3. アグリゲーター — 特定の送金について、複数の基盤ブリッジ／メッセージングプロトコルから1つを選択するルーターです。アグリゲーターレイヤーと、そこからルーティングされた基盤ブリッジは別々の帰属先です。一方を対象にしたクエリでは、もう一方が見落とされます。

各カテゴリは、1つのテーブルに方向列を設けるのではなく、インバウンドテーブルとアウトバウンドテーブルに分かれています（例：送信元チェーン側のアウトバウンド送金テーブル、送信先チェーン側のインバウンド送金テーブル）。これは上記の非対称な記録設計をテーブルレベルで明示したものです。片方のテーブルに両方のレッグがあると想定せず、メッセージ／送金識別子で両側を結合してください。

可能な限り、フラットな <db>.bridges.transfers テーブルは避けてください。非推奨です。 このテーブルは、上記のブリッジ／メッセージングプロトコル／アグリゲーターへの分割より前のもので、その帰属情報を保持していません。このテーブルに対するクエリでは、どのカテゴリや方向から行が生成されたのかを区別できません。

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