0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Rascal

NEAR Intentsでクロスチェーン資金洗浄を追跡する — ChainAnalyzer Bridge Flow Traceで74秒のintent settlementを可視化

0
Posted at

NEAR Intentsでクロスチェーン資金洗浄の可能性を追跡

TL;DR

  • NEAR Intents のようなプライバシー保護ブリッジを経由した資金移動でも、bridge detector + counterpart resolution + solver registry + BFS の組合せで上流の user origin まで追跡できます
  • 2026年2月22日に発生した SANAE TOKEN 関連の資金流入を題材に、0.03 ETH ⇄ 0.687 SOL のクロスチェーン intent を 74秒の settlement latency つきで自動再構成しました
  • ChainAnalyzer の Bridge Flow Trace (Business / Enterprise / x402) が 6 ノード・5 エッジ・9 種の forensic insight (日英出力対応) を 1 リクエストで出力します
  • 既存の SANAET 詳細記事は SANAE TOKEN（Solana）のオンチェーン分析 — 運営ウォレット構造と構造的リスクの調査 を参照ください

！重要なインサイト (これだけ読めば OK)

Insight 1: プライバシーブリッジは "追跡不能" ではない

NEAR Intents は intent ベース (= ユーザーが bridge contract を直接叩かない) の仕組みなので、表面上は 「Solver が突然 SOL を delivery してきただけ」 に見えます。
しかし Memo program に刻まれた intent_id (PzUkLi9trGap...) が ETH 側と Solana 側で完全に一致 するため、API (Wormholescan / NEAR Explorer / deBridge) で counterpart を resolve すれば cross-chain で連結することが可能です。
実はプライバシーよりも「Solver と user origin の分離」の方が本質的な論点であり、Solver 自体は普通の市場メイカー (MM) として動いているにすぎません。

Insight 2: Solver wallet は heuristic で機械的に識別可能

Registry に未登録の Solver でも、次の 3 指標で 90%+ の確度で判別できます:

指標 NEAR Intents Solver の典型値
UUID memo 比率 >50% (HWjmoU は 71%)
残高 >1,000 SOL / >100 ETH (HWjmoU は 12,241 SOL ≈ $1.5M)
TX 頻度 >50 TX/hour (HWjmoU は 138 TX/h)

これは 新興 Solver が次々に登場しても自動でカバーできる、という大きな利点です。

Insight 3: same_intent_correlation insight が forensic の決定打に

Intent PzUkLi9... settled in 74s:
  0.03 ETH @ 0x51b7Fe → 0x9F1Fc6 (07:27:23)  ⇄  0.687618 SOL @ HWjmoU → 6ytB (07:28:37)

この 1 行で 「異なるチェーンの 2 つの TX が同じ資金移動である」を、on-chain memo の一致 + 74 秒の時間相関 + USD ベースでの価値整合 の 3 軸で同時に立証できます。法執行レポートや VASP の SAR 提出書類において、そのまま証拠化できるレベルです。

Insight 4: User origin と Solver の分離が重要

graph 上には 6 個の node が見えますが、本質的には 役割は 3 種類しかありません:

  • User origin (0x51b7Fe) — 真の発信者です。Token6900 (meme coin) のプリセール参加者で 181 日の活動歴があります。ここが追跡対象です
  • Relay (0x9F1Fc6) — 使い捨て中継 wallet (TX 3 件のみ)。NEAR Intents が生成するデポジット address の可能性があります。追跡上は通過点です
  • Solver (0x2cFF89 / HWjmoU) — Binance 派生の MM / 12,241 SOL 規模の流動性提供者です。犯罪関与ではなくインフラとして動いています

→ "Solver を見つけたら止める" のが正しい trace 戦略となります。Solver を犯人と誤認する分析を防ぐ役割も、このツールが担っています。

Insight 5: 7 秒で 1〜2 時間の調査を再現可能

手作業の場合: Solana RPC で sig fetch → memo 解析 → NEAR Explorer 検索 → Wormholescan resolve → ETH 側 outbound 追跡 → Solver 識別 → 全部纏める、で 1〜2 時間かかります。
自動化した場合: 6.8 秒で同じ graph + insights が出力されます。SANAE TOKEN のような単独調査も嬉しいのですが、100 件の wallet を一括処理する batch 用途で破壊的に強くなります。

はじめに — クロスチェーンブリッジが追跡の盲点になる理由

ブロックチェーン分析でいちばん難しいのは、チェーンを跨いだ資金移動 の追跡です。

  • 同じチェーン内であれば from → to でほぼ無限に遡れます
  • ところが Solana の wallet が 0.687 SOL を受け取った時、それが どの Ethereum address から、どのブリッジ経由で来たのか はオンチェーンデータだけからは分かりません
  • 特に NEAR Intents のような Intent ベースの bridge は、ユーザーが直接 bridge contract を叩くわけではなく、Solver と呼ばれる流動性提供者が代理で資金移動を行う仕組みなので、solver wallet の動きしか見えません

実務上、これが OSINT 調査でも犯罪収益洗浄の追跡でも壁になります。

本記事では、SANAE TOKEN の Creator wallet の資金源を追跡する過程で見つけた NEAR Intents → Solana への着金パターン を、自前のツール ChainAnalyzer Bridge Flow Trace で自動再現した結果を公開します。

※ 本記事は過去のXのポストに基づくものです。ChainAnalyzer（旧TokenForge）の一つの機能として開発しましたので改めて記事化しました。
よろしければ、SANAE TOKEN（Solana）のオンチェーン分析 もあわせてご覧ください。

1. 手作業で追跡したフロー

このうち ??? の部分が「クロスチェーンブリッジで切れていて見えない」謎の上流でした。

手作業で Solana RPC を叩いて 6ytB6pX3... の inbound TX (4QZfXmpjA61A...) を解析したところ、Memo program に NEAR Intents の intent ID が刻まれていることを確認できました:

Memo: [36] PzUkLi9trGapLFsSGCf37xFRwX8kyYZZ8iZvTtqwyeFRwrPEa

ここから NEAR Explorer / Wormholescan / deBridge API を当てに行くと、対応する Ethereum 側の送金元 0x51b7FeDBA6d56558e6e23095b0FC52eDC4F1482E まで遡れることが判明します。

さらに Ethereum 側で 0x51b7Fe の最新 outbound TX を辿ると、以下のような流れになっていました:

つまり ETH 側 0x51b7Fe から見ると、次の順序で動いていたことが分かります:

  1. 07:27:23 — 0x9F1Fc6 (使い捨て relay wallet、TX 3 件のみ) に 0.03 ETH を送金
  2. 07:28:11 — relay から 0x2cFF89 (Binance ホットウォレット派生の MM、1.13M TX / $24.6M 保有) へ同額を転送
  3. 07:28:37 — Solana 側で 同じ intent_id を持つ memo 付き TX によって、HWjmoU (NEAR Intents Solver、12,241 SOL ≈ $1.5M) が 6ytB に 0.687 SOL を delivery

→ 0.03 ETH ≒ 0.687 SOL ≒ $67 のクロスチェーン settlement が 74 秒で完結 していました。Solver 同士の API 連携で吸収されてはいますが、on-chain で全ステップが TX として残っている ので追跡可能でした。

手作業ではここまで 1〜2 時間かかります。これを 1 API request / 7 秒で再現する のが今回の主題となります。

2. ChainAnalyzer Bridge Flow Trace の出力

UI 画面 (Business プラン以上)

/account/bridge-flow に address + chain + depth を入れて Trace Flow を押すと、以下のように 横方向の cross-chain fund flow が graph で可視化 されます。

Bridge Flow Trace UI — 横展開 cross-chain graph

  • 🟢 緑: user origin (0x51b7Fe、ETH)
  • 🟡 黄: relay (0x9F1Fc6、ETH、TX 3 件のみの使い捨て中継)
  • 🔴 赤: solver (0x2cFF89 ETH 側 / HWjmoU Solana 側)
  • ◇ slate: bridge ノード (NEAR Intents、PzUkLi9... の intent_id 付き)
  • 🔵 青: scanned (= 入力 6ytB)
  • 実線 edge: 実 on-chain TX (amount + tx hash 付き)
  • 点線 edge: semantic / inferred (counterpart resolve で論理連結)

実行時間は 約 11 秒、6 node / 5 edge / depth 1 (= BFS が 0x51b7Fe で自然終端) となりました。

Forensic Insights パネル (日本語)

graph の下に 9 件の forensic insight が日本語で表示されます (locale=ja の場合。locale=en なら英語表示となります):

Forensic Insights — 9 件の cross-chain forensic 知見

✅ solver_detected × 2 — HWjmoU + 0x2cff890f を NEAR Intents Solver と判定
✅ trace_terminus — 深度 1 の 0x51b7Fe でブリッジクロスを検出せず → トレース終端
✅ same_intent_correlation — Intent PzUkLi9... が 74 秒で settle: 送出 0.03 ETH ⇄ 受領 0.687618 SOL ← forensic 決定打
⚠️ privacy_bridge_used [medium] — プライバシー保護ブリッジ (NEAR Intents) を使用 → 上流追跡には counterpart resolution API 必要
⚠️ bridge_funnel_detected [medium] — user 0x51b7Fe が同一 chain 2 hop で Solver 0x2cff890f に集約 = 意図的事前中継
✅ chains_traversed — トレースは 2 チェーン跨ぎ
✅ user_origin_profile — 0x51b7Fe は成熟ウォレット (182 日、5 TX) → 「資金洗浄直後 origin」仮説の確度は低下
✅ multi_solver_bridge_path — 標準的なクロスチェーン bridge crossing を 2 チェーン間で確認、高信頼度のフォレンジック連結

Raw API レスポンス

POST 一発で取得できます:

curl -X POST https://chain-analyzer.com/api/bridge-flow \
  -H "Content-Type: application/json" \
  --cookie "..." \
  -d '{
    "address": "6ytB6pX3d6avtgzCkRjsyd1jkUJCutyCoc83ZeoVTC6c",
    "chain": "solana",
    "max_depth": 2
  }'

レスポンス (抜粋):

{
  "success": true,
  "graph": {
    "depth_explored": 1,
    "duration_ms": 6794,
    "nodes": [
      { "id": "solana:6ytB6pX3...", "role": "scanned" },
      { "id": "solana:HWjmoU...", "role": "solver",
        "metadata": { "solver_score": { "confidence": 1.0, "bridge": "near_intents" } } },
      { "id": "bridge:near_intents:PzUkLi9...", "role": "bridge" },
      { "id": "ethereum:0x2cff890f...", "role": "solver",
        "metadata": { "solver_score": { "confidence": 1.0, "bridge": "near_intents" } } },
      { "id": "ethereum:0x9f1fc645...", "role": "relay",
        "metadata": { "tx_count": 3, "span_days": 0 } },
      { "id": "ethereum:0x51b7fedb...", "role": "user",
        "metadata": { "tx_count": 5, "span_days": 181.6 } }
    ],
    "edges": [ /* 5 件 */ ],
    "insights": [
      { "type": "solver_detected", "description": "HWjmoU... classified as near_intents solver — delivered 0.687618 SOL to scanned wallet" },
      { "type": "solver_detected", "description": "0x2cff890f... classified as near_intents solver — bridge-funnel endpoint upstream of the bridge crossing" },
      { "type": "trace_terminus", "description": "No bridge crossings detected at depth 1 for 0x51b7fedb… on ethereum" },
      { "type": "same_intent_correlation",
        "description": "Intent PzUkLi9trGap… settled in 74s: 0.03 ETH on send → 0.687618397 SOL on receive",
        "evidence": {
          "intent_id": "PzUkLi9trGapLFsSGCf37xFRwX8kyYZZ8iZvTtqwyeFRwrPEa",
          "send_leg": { "tx": "0x046ca1fa...", "amount": 0.03, "token": "ETH",
                         "timestamp": "2026-02-22T07:27:23+00:00" },
          "receive_leg": { "tx": "4QZfXmpjA61A...", "amount": 0.687618397, "token": "SOL",
                            "timestamp": "2026-02-22T07:28:37+00:00" },
          "delta_seconds": 74
        }
      }
    ]
  }
}

graph として表現すると、こんなイメージになります:

実線は実 TX、点線は intent_id で論理的に連結された semantic edge を表しています。

3. 仕組みの解説

Bridge Flow Trace のパイプラインは、大きく以下のステップで構成されます:

3.1 Bridge Detector

3 つの方法で「この TX はブリッジ関与」を判定します:

  1. Program ID マッチ — Solana の場合、accountData[].account に既知の solver / program ID が含まれているか
  2. Label マッチ — Helius enhanced TX の description / source に near intents 等の bridge name が含まれているか
  3. Memo マッチ — NEAR Intents 限定で、Solana Memo program に 36-49 char base58 (intent_id らしき文字列) があるか

EVM 側は、既知 bridge contract への送受信を to/from フィールドで突合しています (Stargate / Across / Synapse / Hop / Wormhole / deBridge 等、7 プロトコル登録済み)。

3.2 Counterpart Resolution

検出された intent に対して、tx_signature または intent_id をキーに、以下の API を best-effort で当てに行きます:

  • Wormholescan — https://api.wormholescan.io/api/v1
  • deBridge — https://api.debridge.finance/api
  • NEAR Explorer Search — 1 req / 5 sec の rate limit (NEAR は時間がかかります)

12 秒のタイムアウトを設けてあります。返ってきた source_chain / source_address (inbound の場合) または target_chain / target_address (outbound の場合) を BridgeDetection に追記する形になります。

3.3 Node Classification (Solver Registry の話)

ここが今回の肝です。各 wallet を 5 つの役割 に分類します:

Role 判定基準
scanned 入力 address
solver (a) KNOWN_SOLVERS 静的リスト hit、または (b) ヒューリスティック: Solana なら UUID memo 比率 > 50% + 残高 > 1000 SOL + TX 頻度 > 50/h、EVM なら TX 数 > 10万 + bridge contract 接触多数
relay TX 10 件以下 + span 短期 (7 日未満) + 単発転送パターン
user TX 多数 + 自然な活動歴 (30 日以上)
exchange known_entities.py の category=exchange

HWjmoU の判定根拠 (実測値):

  • 1000 TX / 7 時間 (= 138 TX/h)
  • UUID memo 比率 71%
  • 残高 12,241 SOL ≈ $1.5M
  • → confidence 0.92 で near_intents solver と判定

これは 新規 wallet でも heuristic だけで Solver 検出ができる ことを意味します (registry にない無名の Solver も自動でカバーされます)。

3.4 BFS + Forward Trace

BFS とは

BFS (Breadth-First Search / 幅優先探索) は、グラフ探索アルゴリズムの代表的な手法のひとつです。起点ノードから「近い順 (= 距離が浅い順) に」ノードを訪問する のが特徴で、もう片方の代表である DFS (Depth-First Search / 深さ優先探索) が「ひとつの枝を行けるところまで深く掘る」のと対照的です。

Bridge Flow Trace では BFS を採用しています。理由は次のとおりです:

  • max_depth で素直に切れる — 「最大 N hop まで」という制約を強制しやすい
  • 早期終了に強い — solver / exchange に到達した瞬間にその枝を打ち切れる
  • 横方向の優先度が自然 — 同じ depth の counterpart を並列に処理した方が、複数 bridge を持つ wallet で取りこぼしが減る
  • 可視化との相性 — graph layout が breadthfirst なので、BFS の探索順がそのまま左→右の表示順と一致して見やすい

Bridge Flow Trace 内の BFS の動き

擬似コードで書くと、次のような構造になっています（ChainAnalyzerのバックエンドでは実際にPython（FastAPI）を使っています）:

queue = [(input_address, input_chain, depth=0)]
visited = set()

while queue:
    addr, chain, depth = queue.pop(0)   # ← FIFO なので幅優先になります
    if (addr, chain) in visited or depth > max_depth:
        continue
    visited.add((addr, chain))

    bridges = detect_bridges_on(addr, chain)  # 3.1 + 3.2
    for b in bridges:
        counterpart = resolve(b)              # 3.2
        role = classify_node(counterpart)     # 3.3
        graph.add_edge(addr → bridge → counterpart)

        # ★ ここが BFS の振り分け
        if role in ("solver", "exchange"):
            # 終端 — bridge terminus または取引所
            continue
        else:
            # user / relay / unknown は次の hop へ
            queue.append((counterpart, counterpart_chain, depth + 1))

ポイントは次の 2 つです:

  • queue.pop(0) で FIFO (先入れ先出し) を実現 → 浅い depth から順に処理されます
  • solver / exchange で continue することで、ブリッジ終端や取引所より上流を遡る無駄を排除しています

Forward Trace との組合せ

BFS 単独では、counterpart resolution が返してくる「上流 chain での発信者」(SANAET 事例なら 0x51b7Fe) までしか到達できません。実際にはその発信者から bridge contract に資金を渡すまでに同一 chain で何 hop か挟んでいる ケースが多いため、別軸で same-chain forward-trace を併走させています。

  • 対象: EVM 側で user 判定された node
  • 動作: 最新の native-token outbound TX を辿り、Solver まで到達するまで最大 2 hop 追跡
  • depth_explored には反映されない (= BFS とは独立の補助系)

これにより、SANAET 事例では BFS が 0x51b7Fe で終端したあとも、0x51b7Fe → 0x9F1Fc6 (relay) → 0x2cFF89 (Solver) の 3-hop ETH chain を補完できる構造になっています。

3.5 Insights Post-process

graph を眺めて、9 種類の insight を生成します:

  • solver_detected — Solver 判定された各 node について発火
  • relay_chain — 連続 relay の検出
  • trace_terminus — BFS が終端した理由
  • same_intent_correlation — 同じ intent_id を持つ edge を時間順に並べ、settlement latency と金額対応を 1 行にまとめます ← forensic レポート用の決定打
  • privacy_bridge_used — プライバシー保護ブリッジ使用フラグ
  • bridge_funnel_detected — user → relay → solver の意図的事前ルーティング検出
  • chains_traversed — 跨いだ chain 数 + 一覧
  • user_origin_profile — user 役 wallet の年齢別プロファイリング (new / young / established / mature)
  • multi_solver_bridge_path — 複数 chain で solver が連結されているかの確認

4. なぜ "same_intent_correlation" が決定的か

{
  "intent_id": "PzUkLi9trGapLFsSGCf37xFRwX8kyYZZ8iZvTtqwyeFRwrPEa",
  "send_leg": {
    "tx": "0x046ca1fa...",
    "from": "0x51b7Fe...",
    "to":   "0x9F1Fc6...",
    "amount": 0.03, "token": "ETH",
    "timestamp": "2026-02-22T07:27:23+00:00"
  },
  "receive_leg": {
    "tx": "4QZfXmpjA61A...",
    "from": "HWjmoU...",
    "to":   "6ytB6pX3...",
    "amount": 0.687618397, "token": "SOL",
    "timestamp": "2026-02-22T07:28:37+00:00"
  },
  "delta_seconds": 74
}

この 1 ブロックで:

  • 同一 intent ID で ETH と Solana の 2 TX が紐づいていること (off-chain ではなく on-chain memo に刻まれている)
  • 送出 leg と受領 leg の 発生時刻が 74 秒以内 であること
  • 送出 0.03 ETH と受領 0.687 SOL は 当時の market 価で価値整合 していること (≒ $67)

を一括で示すことができます。AML / 法執行レポートにおいて「異なるチェーンの 2 つの TX が同じ資金移動である」と立証する材料が、これ 1 つに圧縮されている形となります。

5. Cross-Chain Solver の挙動について

HWjmoU を別途分析すると、以下の特徴があります:

  • 直近 7 時間で 1000 TX、平均 138 TX/h、median gap 11 秒
  • 712/1000 TX (71%) が 36-char UUID memo 付き
  • 残り 288 は memo なし (Solver 内部の rebalancing / admin TX)

これは典型的な professional NEAR Intents Solver の挙動であり、SANAET Creator が自前で立てたわけではなく、汎用 Solver がたまたまこの intent を処理した ことを意味します。

同様に、0x2cFF890f (Ethereum side) は Binance hot wallet 派生の market maker であり、こちらも汎用 Solver です。NEAR Intents の特徴である「intent を出すユーザー」と「実際の流動性を提供する Solver」が完全に独立した actor として動いていることが、graph 構造として可視化できるようになっています。

6. 価格

プラン アクセス 月額
Free / Starter ✗ —
Pro ✗ (single-chain bridge trace のみ) $19.99
Business ✅ Multi-hop Bridge Flow Trace $99.99
Enterprise ✅ + 上限なし + SLA + Insider 監視 個別
x402 pay-per-trace ✅ 1 リクエストごと $3.00 / call

サブスクなしで 1 件だけ調べたい場合は、x402 endpoint がご利用いただけます:

POST https://chain-analyzer.com/api/v1/x402/bridge-flow/trace
$3.00 USDC on Base / Solana — agentic.market（こちらは実験中） / Coinbase Bazaar 等経由で自動決済

7. まとめ

内容 値
手作業時の所要時間 1〜2 時間
Bridge Flow Trace の所要時間 7〜11 秒 (depth 1〜3 / NEAR Explorer rate limit 依存)
出力 node 数 6
出力 edge 数 5
Forensic insight 数 9 (solver_detected ×2 / trace_terminus / same_intent_correlation / privacy_bridge_used / bridge_funnel_detected / chains_traversed / user_origin_profile / multi_solver_bridge_path)
検出された Solver 2 (HWjmoU on Solana, 0x2cFF890f on Ethereum)
結合 intent latency 74 秒

つまり、「NEAR Intents 等のプライバシーブリッジを使えば追跡できない」という直観は半分間違いで、Solver の挙動と intent_id memo を読めば cross-chain でも繋がります。これを実装して 1 API で実行できるようにしたのが、ChainAnalyzer Bridge Flow Trace です。今回は当プラットフォームの機能追加の一環として数ヶ月前のことを題材として追跡してみました。

参考リンク

免責: 本記事は公開 on-chain データの分析結果であり、個別の事件性・違法性を断定するものではありません。Solver wallet (HWjmoU…, 0x2cFF890f…) は NEAR Intents protocol の流動性提供者として通常運用されているもので、当該 intent に関与した事実が直ちに法的な責任を意味するものでもありません。本報告は、2026年5月24日現在の時点での分析によるものです。また誤りがある場合がありますのでご承知おきください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?