こんにちは、よだかです。
引き続き、Solanaの市場調査を進めています。
これまではSolana全体の市場構造や、実際に取引している参加者の行動を中心に調べてきました。今回はそこから一歩進み、個別のプロトコルを起点として市場の実態を掘り下げることにしました。
最初の対象に選んだのは、Solanaの主要な流動性プロトコルの一つである**Meteora（メテオラ）**です。
調査では約40万件のプール情報を取得し、価格形成の仕組みを整理したうえで、Meteora内部で完結するアービトラージ（裁定取引）の可能性を検証しました。さらに、短時間のリアルタイム監視を実装し、実際に発生しているプール間の価格差も観測しています。
ただし、今回の検証で取得可能な裁定エッジが見つかったわけではありません。
むしろ、実際のデータを確認することで、Meteoraを一つのDEXとして捉えるだけでは見えてこない市場の構造や、価格差を利益として取得するまでの問題が具体的になってきました。
今回は、Meteoraの仕組み、取得したデータ、内部裁定の検証結果、そして現時点での理解を整理します。
1．Solana市場の探索をMeteoraから具体化する
Solanaの本格的な調査を始めたのは10月24日です。
開発記録#598「Solanaを掘り始めた――高速チェーンに個人botterのエッジはあるのか」では、市場全体の構造を整理し、実際の取引履歴から複数DEXを経由する原子的裁定（Atomic Arb）の存在を確認しました。
続く開発記録#601「Solanaのボトルネックを追う――実取引と流動性の経済構造調査」では、流動性や価格更新能力の違いが、市場参加者の行動や利益取得にどのように関係しているのかを調べました。
ここまでの調査によって、Solanaには多様なDEXや流動性供給の仕組みが存在し、それらを横断して取引する参加者がいることを確認できました。
一方、個々のプロトコルの内部構造や、実際にどのようなプールが存在しているのかについては、まだ十分に理解できていませんでした。
そこで今回は、調査対象をMeteoraに絞りました。
Meteoraは、EthereumにおけるUniswapと同じく、自動マーケットメーカー（AMM）を中心とした流動性インフラです。
ただし、その役割は既存トークンの交換だけではありません。
複数のAMM方式を提供しているほか、新規トークンの市場形成や流動性管理にも関与しています。
SolanaのDEX市場全体を支配する存在ではありませんが、特定の領域で一定の役割を確立しているプロトコルです。
今回の目的は、Meteoraで利益が得られると決めつけてbotを作ることではありません。
まず仕組みと実態を理解し、実際にどのような価格差や取引機会が発生しているのかを確認します。
そのうえで、取得可能な利益が存在するかを検証していきます。
2．Meteoraは複数の価格形成方式を持つ
Meteoraを調べて最初に整理したのが、プールごとの価格形成の違いです。
今回の主な調査対象は、DLMM、DAMM v2、DAMM v1の3種類です。
いずれもプールに預けられた資産を利用して交換を行いますが、価格や手数料の決まり方は同じではありません。
主要なAMMの仕組み
DLMM（Dynamic Liquidity Market Maker）
価格をBin（ビン）と呼ばれる離散的な区間に分割し、その区間ごとに流動性を配置する方式です。
同じBinの内部では固定価格で交換が行われ、流動性を消費して次のBinに移ると価格が変化します。
また、市場の変動状況に応じて取引手数料が変化する仕組みも備えています。
DAMM v2（Dynamic Automated Market Maker v2）
一定積の関係を基礎とするAMMです。
流動性を広い価格帯に配置する方式に加え、特定の価格範囲に集中させる仕組みなども備えています。
価格はプールの資産残高や流動性条件に応じて変化します。
DAMM v1
従来型のAMMで、一定積型のほか、安定資産向けの価格曲線などを扱います。
プールの種類によって、増幅係数や外部の参照価値、Vaultの状態など、価格計算に必要な情報が異なります。
このように、同じMeteoraのプールであっても、価格形成の仕組みは一様ではありません。
さらに重要なのは、同じトークンペアを扱っていても、各プールの流動性や価格、手数料が独立していることです。
例えば、あるトークンAとBを交換できるプールが複数存在する場合、それぞれで交換可能な数量や実効価格が異なる可能性があります。
これはアービトラージの観点では重要です。
一方のプールで安く取得した資産を、別のプールで高く売却できれば、価格差を利益として取得できる可能性があるからです。
ただし、表示価格の差がそのまま裁定利益になるわけではありません。
実際に交換する数量と、各プールの価格変化、手数料を含めて評価する必要があります。
なお、Meteoraには新規トークンの価格発見を担うDBC（Dynamic Bonding Curve）なども存在します。
今回は主に既存のAMMプールを調べており、未移行のDBC市場全体を調査したわけではありません。
3．約40万プールは約40万の活発な市場を意味しない
次に、MeteoraのAPIを利用してプール情報を広く取得しました。
2026年11月4日10時から10時11分ごろにかけて取得したデータを整理した結果、重複除去後のプール数は次のようになりました。
- DLMM：140,053プール
- DAMM v2：172,394プール
- DAMM v1：83,084プール
合計395,531プールです。
登場するトークンも、mintアドレスで区別すると184,137種類ありました。
Solanaには非常に多くのトークンが存在していることは知っていましたが、個別のプロトコルだけでもこれほど大きなプール群が存在することを、今回具体的に確認できました。
ただし、この数字をそのまま活発な市場の数として理解することはできません。
今回の約39.5万プールは、API上で確認できたプール情報の件数です。
その中には、流動性が乏しいプールや、取引活動が確認できないプールも含まれています。
実際、API上で正の取引高が報告されていたプールは12,538件でした。
もちろん、この12,538件すべてが現在も活発に取引されているとは限りません。
反対に、APIの集計だけでは捉えられない取引や状態変化も考えられます。
つまり、ここでは少なくとも以下を区別する必要があります。
- APIに掲載されているプール
- 流動性が報告されているプール
- 取引高が報告されているプール
- 実際にオンチェーンで状態が更新されているプール
- 現在の状態で交換を実行できるプール
これらは同じ集合ではありません。
また、同じ名称やsymbolのトークンであっても、mintが異なれば別の資産として扱う必要があります。
こうした区別をせずに市場を集計すると、実際には交換できない経路や、存在しない裁定機会まで候補として数えてしまいます。
さらに、プールをトークン同士の接続として捉えると、別の特徴も見えてきます。
今回、API上で取引活動の報告があるプールを利用して、USDCを含む3トークンの循環経路を調べたところ、トークンの組み合わせだけでも1,558種類が確認できました。
それぞれの辺で利用するプールまで区別すると、候補の組み合わせは約40万通りに達します。
これは交換の成立や利益を確認する前の、グラフ上の組み合わせ数です。
しかし、以前CEXで多角形アービトラージbotを開発していたときと比べても、経路探索の規模が大きくなり得ることは分かります。
Meteoraを理解するには、単にプール数を数えるだけでなく、どのトークンがどのプールを通じて接続され、実際にどこで売買が行われているのかを把握する必要がある。
これが今回の重要な理解更新の一つでした。
4．プール間の価格差は裁定利益を保証しない
プールの構造と分布を整理したところで、Meteora内部で完結するアービトラージの検証に進みました。
最初に調べたのは、二プールを利用した往復裁定と、三つの交換を組み合わせた三角裁定です。
例えば二プール往復であれば、
A → B → A
という交換を異なるプールで行い、最終的に出発資産Aが増えるかを確認します。
三角裁定であれば、
A → B → C → A
という循環経路を評価します。
まずは流動性の比較的大きい32プールを選び、複数の投入数量について公式SDKで交換数量を計算しました。
この初回検証では、合計1,656件の見積り評価を行いました。
そのうち1,317件で計算が完了しましたが、DEX手数料控除後にプラスとなる経路は確認できませんでした。
ただし、これは対象とした32プールの結果です。
しかも、選定では各商品・ペアのTVLが大きいプールを優先しています。
そのため、Meteora内部の裁定可能性全体を評価した結果とはいえません。
そこで次に、対象を固定した比較から、より広い市場のリアルタイム観測へ進みました。
広域監視で価格差の存在を確認した
DLMM、DAMM v2、DAMM v1の更新を広く取得する仕組みを用意し、まず約10分間の観測を実施しました。
この観測では1,366プールの状態更新を受信しました。
さらに、候補となったプールについて同じRPC応答で状態を取得し直したところ、複数のプール間で比較的大きな表示価格差が確認されました。
一部では数秒離れた観測時点でも価格差が残っていました。
ただし、その間ずっと同じ価格差が継続していたことまでは確認できていません。
また、表示価格の差には実際の交換数量や手数料が反映されていないため、この段階では利益とは判断できません。
続いて、観測時間を約1時間に拡張しました。
このRunでは3,024プールの更新を受信し、87組の候補を判定台帳に整理しました。
そのうち69組について数量別の交換見積りを検査しています。
結果として、DEX手数料控除後に小さなプラスが生じるプール組も見つかりました。
しかし、今回プラスとなった3組は、いずれも記録された基本ネットワーク手数料相当額を下回っていました。
今回の条件で検証した単独の二プール往復裁定について、採用できる候補は0組でした。
ここで一つ明確にしておきたいことがあります。
今回の1時間観測では、三角裁定の広域検証は行っていません。
初回32プールの検査では三角裁定も評価しましたが、広域に取得した市場の組み合わせすべてを調べたわけではありません。
また、広域観測では表示価格差などを起点に候補を選んでいるため、選定条件に該当しなかった経路まで不採算だったとはいえません。
したがって、今回の結果から「Meteora内部にアービトラージの余地はない」と結論づけることはできません。
ただし、少なくとも今回調べた範囲では、価格差が見えていても、そのまま取得可能な利益にはつながらないことが確認できました。
5．広域観測の成立と執行可能性は異なる
今回、実装面でも新しい確認ができました。
広域監視では、RustでWebSocketの更新を受信し、Pythonで状態や候補を解析する構成を利用しています。
数量別の精密な見積りには、Meteora公式のSDKも使用しました。
約40万プールを一つずつ高頻度で巡回するのではなく、プログラム単位で更新を購読し、実際に変化したプールを中心に調べる方式です。
この方法によって、少なくとも今回の観測流量では広域の状態更新を受信できました。
Rust側の受信後処理待ちは、95パーセンタイルで約1.2ミリ秒でした。
ただし、これだけで高速な裁定botが成立したわけではありません。
今回あらためて重要だと分かったのは、データを受信する速度と、取引に必要な状態を取得して見積りを完了する速度は別だということです。
実際、1時間観測の候補検査では、異常を検出してから数量別の見積りを得るまで、中央値で約16秒かかっていました。
これは既存の実験構成における計測結果であり、最適化後の限界性能を表すものではありません。
それでも、受信処理そのものが速くても、追加の状態取得や精密計算、候補の処理待ちが発生することは確認できました。
特にDLMMでは、正確な交換数量を計算するために、対象となるBinの流動性情報などが必要になります。
同じトークンの表示価格を比較するだけなら比較的簡単でも、実際に数量を交換するとなれば確認項目が増えます。
また、観測データの時刻整合性にも注意が必要です。
Solanaでは、RPC通知に含まれるslot情報が一致していても、それだけで同一slot内の全取引の実行順序を復元できるわけではありません。
さらに、今回の1時間観測では接続・ストリームエラーも記録されています。
このような取得の途切れを、価格差の解消と誤認しないことも重要です。
以前の開発記録#600「DEX Arbの『判定不能』を分解する――短時間Runで見えた観測と実行の制約」でも、監視と有効な評価が一致しない問題を扱いました。
今回のMeteora調査では、その問題がさらに具体的な形で現れています。
現時点で確認できたのは、プールの更新を広域に取得し、価格差を検出し、一部の経路で数量別の見積りまで進められることです。
一方、短時間の価格差を競合より先に取得できることや、単一トランザクションで利益を回収できることまでは確認できていません。
今回のMeteoraに関する調査では、トランザクションの仮実行、署名、送信は行っていません。
したがって、実現利益も未確認です。
6．市場構造から利益取得までの理解を更新する
ここまでの調査を振り返ると、Meteoraに対する理解は段階的に変化してきました。
最初は、Solanaで流動性を提供する主要DEXの一つとして捉えていました。
そこから複数のAMM方式が存在することを理解し、プール情報を取得して市場の分布を確認しました。
さらに、実際の状態更新や価格差を観測し、数量別の利益計算へと進んでいます。
ざっくり言うと、理解・調査の流れは以下の通り。
- MeteoraをSolanaの主要な流動性プロトコルとして把握する
- 複数のAMMと独立したプール構造を理解する
- 約40万プールの分布と実際の活動を区別する
- 広域観測によってプール間の価格差を確認する
- 数量別の費用評価で、価格差と取得利益を区別する
- 実行可能性と競争状態の検証が残る現在地を確認する
今回の調査で得られた理解は、単純に「Meteoraにはたくさんのプールがある」というものではありません。
Meteora内部には価格形成方式や流動性の異なる市場が多数存在しており、それぞれが独立した交換条件を持っている。
そして、それらの市場を比較すると、実際に価格差が観測される場合があります。
ただし、価格差の存在だけでは、その理由も、裁定可能性も、競争状態も説明できません。
例えば、価格差が残っている理由としては、取引手数料や価格インパクトが大きく、経済的に裁定する価値がない可能性があります。
また、流動性が乏しいため、交換できる数量が小さすぎる場合も考えられます。
反対に、実際に利益が生じる価格差については、既存の裁定botが短時間で回収している可能性もあります。
今回の観測だけでは、これらを十分に区別できていません。
そのため、現時点でMeteora内部がどの程度競争的なのかを断定することも避けています。
このモデルそのものは、今回初めて考えたものではありません。
これまでも、価格差と実現利益が別であることは繰り返し確認してきました。
今回新しかったのは、Meteoraという具体的な市場について、各段階で何を観測し、どこまで評価でき、どの段階から未検証なのかが明確になったことです。
例えば、表示価格差が大きくても、数量別の評価では利益がほとんど残らない事例がありました。
また、広域監視そのものは成立していても、精密な見積りには追加の状態取得が必要でした。
このように、同じ「価格差を探す」という行為であっても、実際の研究では異なる問題を順番に解決する必要があります。
今回の検証は、その問題を具体的に確認する機会になりました。
7．Meteoraを起点にSolana市場の調査を続ける
今回のMeteora調査では、プールの構造と分布を把握し、限定的な内部裁定の検証から広域のリアルタイム観測まで進めました。
一方で、今回の条件では採用できる単独二プール裁定の候補は見つかっていません。
また、広域の三角裁定や、実際の取引競争については検証が残っています。
現在も追加調査を進めており、Meteora内部のアービトラージについて最終的な結論を出したわけではありません。
そもそも、今回Meteoraを調べ始めたのは、Solana市場の実態を理解するためです。
アービトラージは、その構造を調べるうえで、比較的具体的な検証方法を持つ取引モデルの一つです。
私自身、別チェーンでもDEXアービトラージbotの実装・運用を進めているため、どのような状態を取得し、何を計算し、どこで執行上の問題が生じるのかを想像しやすいという事情もあります。
ただし、理解しやすい戦略が、必ずしも取得しやすいエッジであるとは限りません。
その点は区別しておきたいところです。
また、今回得られたMeteoraの知識は、Meteora内部の裁定研究だけに利用できるものではありません。
SolanaにはRaydiumやOrcaなど、異なる流動性プロトコルも存在しています。
Meteoraのプールと外部の流動性を比較する場合にも、今回整理した価格形成や状態取得の仕組みが関係してくるはずです。
ただし、他プロトコルを含めれば、当然ながら経路や検証条件も増えます。
そのため、単純に監視対象を増やすのではなく、実際の市場活動と取得可能性を確認しながら、調査を進める必要があります。
今回の研究で、Solana全体の価格形成や裁定競争を理解できたわけではありません。
しかし、Meteoraという具体的な入口を通じて、プロトコルの仕組み、プールの分布、価格差の観測、数量別の評価という一連の調査を実施できました。
そして、それぞれについて何が分かり、何がまだ分からないのかを整理できています。
Meteoraは一つの市場ではなく、異なる価格形成方式と流動性条件を持つ多数の市場の集合でした。
今回の大きな収穫は、その構造を知識として理解しただけでなく、実際のデータを使って具体的に確認できたことです。
ここで取得可能なエッジが見つかれば、さらに検証を進めます。
見つからなかったとしても、今回得られた市場理解と観測方法は、次の調査に引き継ぐことができます。
Solanaの研究は、まだ始まったばかりです。
まずは足元から、一つずつ確かめていきます。
それでは、また。