こんにちは、よだかです。
今日は、Solana上のPropAMM（Proprietary Automated Market Maker）について、引き続き調査を進めました。
今回の主な対象は、TesseraVとBisonFiの2つです。
それぞれの取り扱いトークンや原資産を照合するとともに、オンチェーンの口座構造、実際の交換取引、データ取得方法などを調べています。
これまで私は、PropAMMを「専門的なマーケットメーカーが独自に運営する流動性プール」という程度の理解で捉えていました。
大まかな説明として間違いではありませんが、実際に調べてみると、それだけでは十分に説明できない部分が出てきました。
特に重要だったのは、価格を提示する仕組み、取引に必要な状態を管理する仕組み、資金を保管する仕組み、実際に交換を成立させる仕組みを、それぞれ分けて考える必要があるという点です。
今回は、既存の技術仕様と実際のオンチェーンデータから分かったことを整理しながら、PropAMMに対する理解がどのように変わったのかを記録します。
1．PropAMMを独自プールとして捉えていた
前回の開発記録#606「価格変化の中身を調べる――SolanaとCEXのエッジ探索」では、Solanaの市場参加者を追跡する中で、PropAMMの調査を進めていることに触れました。
当時から、PropAMMが一般的なAMMとは異なる方式で流動性を供給していることは理解していました。
ただ、その具体的な構造については、まだ曖昧な部分がありました。
一般的な定数積型AMMでは、資金プールに預けられた資産の残高と価格計算式によって、交換数量に応じた価格が決まります。
一方、PropAMMでは、専門的なマーケットメーカーが外部市場の情報や独自のモデルを利用し、価格の提示条件を能動的に更新します。
そのため、同じトークンペアを扱っていたとしても、価格形成や流動性供給の仕組みは異なります。
ここまでは、既存の技術資料でも説明されている内容です。
今回の調査で進んだのは、その仕組みが個別のプロトコルでどのように実現され、実際の取引とどう結び付いているのかを確かめる部分でした。
特にTesseraVでは、状態を保持する口座と資金を保管する口座の関係が、当初想定していたほど単純ではないことが分かってきました。
そこで今回は、プールの数や取引量だけを見るのではなく、実際の口座構造と交換処理まで調べることにしました。
2．PropAMMは価格提示・状態管理・資金保管・取引執行を分けて考える必要がある
まず、PropAMMの基本的な仕組みを整理します。
Solana公式のPropAMM解説では、マーケットメーカーがオフチェーンで価格モデルを運用し、必要な情報をオンチェーンへ更新する方式が説明されています。
これは、通常の定数積型AMMのように、プール残高の変化を中心として価格を決める方法とは異なります。
マーケットメーカーは、市場価格の変化や取引状況などを踏まえ、売買条件を調整できます。
ただし、そのためには、価格に関係する情報をオンチェーン上に保持し、交換処理から利用できるようにする必要があります。
ここで重要になるのが、SolanaのProgramとAccountです。
Solanaでは、スマートコントラクトに相当する処理をProgramと呼びます。
一方、プログラムが利用する設定や状態などのデータは、別のAccount（口座）に保存されます。
この口座は、一般的なウォレットや資金口座だけを意味するものではありません。
プログラムが利用する設定値や市場状態を保持するデータアカウントも含まれます。
今回の調査では、主に次の構成要素を区別しました。
| 構成要素 | 主な役割 |
|---|---|
| 価格モデル | マーケットメーカーが提示する価格や条件を決める |
| 状態口座 | 取引ペアの設定や交換処理に必要な状態を保存する |
| Vault | 実際のトークンを保管する |
| Swap処理 | 状態や取引条件を参照し、資産交換を実行する |
| 外部ルーター | 複数の取引先から交換経路を選択する |
例えば、価格に関する状態が更新されたとしても、それだけで資金が移動するわけではありません。
また、Vaultに十分な資産が存在していても、その全額を任意の価格で交換できるとは限りません。
実際に交換可能な数量や価格は、プロトコルが定める条件にも依存するからです。
つまり、資産を保管していることと、その資産をどの条件で流動性として提供するかは別の問題です。
ここが、今回改めて意識するようになった部分です。
なお、資金保管と市場管理を分離する設計そのものは、PropAMM固有ではありません。Balancerなど、一般的なDeFiプロトコルにも共通Vaultや複数市場を管理する仕組みがあります。
PropAMMの特徴として重要なのは、こうした口座構造そのものより、マーケットメーカーが価格提示を能動的に管理する点です。
3．BisonFiとTesseraVでは市場構造と取り扱い商品が異なる
続いて、今回調査した2つのPropAMMについて整理します。
BisonFiとTesseraVは、どちらもSolana上で流動性を提供していますが、商品構成や実際の口座管理には違いがあります。
11月9日の調査では、公開RPCから市場設定や関連口座を取得し、次の情報を確認しました。
| 調査項目 | BisonFi | TesseraV |
|---|---|---|
| 調査した市場・状態口座 | 44 | 31 |
| 取り扱いmint | 38 | 29 |
| 株式・ETF系mint | 29 | 3 |
| 成立済みSwapの数量復元 | 一部成功 | 既存パーサーで一部成功 |
| 注目した構造 | 市場状態とVaultの対応 | 複数ペアでのVault共有と別の状態口座 |
※口座数は今回の調査で識別した対象の数です。両者で口座の役割や分類が完全に一致するわけではなく、独立した資金プールの数を示しているものでもありません。
BisonFiでは市場状態と資金保管先の対応を確認した
BisonFiでは、市場状態を保持する口座から、対象となるトークンやVaultの情報を調べました。
さらに、実際に成立した交換取引を取得し、トークン移動の記録と照合することで、どの資産が何枚投入され、何枚受け取られたのかを確認できています。
ここから交換時の実績平均価格も算出できました。
ただし、これは過去に成立した取引の復元です。
BisonFiの価格計算式そのものを解明したわけでも、任意数量に対して現在提示されている交換価格を取得したわけでもありません。
TesseraVでは状態口座とVaultの関係が単純ではなかった
一方、TesseraVでは、31個の状態口座が30種類の取引ペアに対応していることを確認しました。
SOL/USDCについては2つの状態口座があります。
また、過去の成功Swapを調べると、異なる取引ペアが同じVaultを利用している実例が見つかりました。
これは、ペアごとの状態口座と、実際の資金保管口座が必ずしも一対一に対応していないことを示しています。
ただし、同じVaultを参照しているからといって、複数市場が同じ在庫を自由に共用できるとまでは言えません。
保管先を共通にしながら、内部の会計や利用条件で市場ごとの資金を分離することも可能だからです。
共有Vaultによって資本効率が改善している可能性は考えられますが、今回それを実測で確認したわけではありません。
ここは今後の調査対象です。
同じ原資産でも同じ商品とは限らない
もう一つ進んだのが、取り扱いトークンと実際の原資産の照合です。
両プロトコルには同じmintもありますが、別のmintでありながら、同じ原資産を参照する商品も存在します。
代表例がSPCXです。
SPCXはSpaceX株に関連するトークン化商品ですが、今回確認したTesseraV側とBisonFi側のSPCXは、異なるmintでした。
TesseraV側ではBackpack系、BisonFi側ではSecuritize系の商品が確認されています。
Backpack公式の商品説明では、同社が発行するトークン化株式と原資産との変換・償還の仕組みが説明されています。
しかし、その条件を別の発行体の商品へそのまま適用することはできません。
また、BisonFiの株式系29 mintでは、新規トークン口座が初期状態で凍結される設定を確認しました。Securitize系の商品には本人確認やウォレットの許可登録に関わる条件もあります。
通常の暗号資産Swapを利用できることと、取り扱われている株式系商品を自由に売買できることは別です。
ここは前日の開発記録#607「トークン化株式を調べ直す――RWA市場研究の地固めと取引経路の再確認」ともつながる部分です。
今回改めて確認したのは、取扱銘柄数と、実際に参加可能な市場の広さは一致しないということです。
同じ原資産を参照していても、mint、発行体、保管・償還経路、利用条件をそれぞれ確認する必要があります。
4．TesseraVの状態口座と実取引から市場の挙動が見えてきた
今回、技術的に特に興味深かったのが、TesseraVの状態口座です。
調査では、ペアごとに対応する1264バイトの状態口座と、それとは別に更新される2048バイトの状態口座を確認しています。
ここでいうバイト数は、口座に保存されているデータ領域の大きさです。
「1264バイト口座」「2048バイト口座」は正式な機能名ではなく、調査中に区別するために使用している呼称です。
Solanaでは、状態データの保存形式を各プログラムが定義します。そのため、データの大きさだけでは内部の意味を判断できません。
この点については、Solana公式のアカウント構造でも説明されています。
ペア別の状態口座はSwapに利用されていた
1264バイトの口座については、取引ペアとの対応関係や、成功したSwapへの登場を確認しています。
さらに、6口座について異なる時点の内容を比較し、保存されているデータが変化していることも確認しました。
ただし、どの命令がどの部分を書き換えたのか、その値が価格や数量などの条件にどう作用するのかについては、まだ対応付けが完了していません。
別の状態口座は更新され、Swapでも参照されていた
2048バイトの口座については、別の命令で更新されていることが分かりました。
興味深いのは、更新処理では書込み対象となっていた同じ口座が、成功したSwapでは読取り専用の引数として渡されていたことです。
つまり、何らかの情報が更新され、その口座が交換処理でも参照される構造になっています。
ただし、そこに保存されているのが価格情報なのか、取引条件なのか、その他の制御情報なのかは未確定です。
現時点で、この口座を価格更新口座や在庫管理口座と断定することはできません。
状態の鮮度が交換結果に関係する挙動を確認した
さらに、過去に実施した未署名シミュレーションでは、状態を固定したまま実行時のslotを進めると、交換結果の受取量や成否が変化する例を確認しています。
slotはSolanaのブロック生成に関係する時間上の単位です。
また、外部ルーターが特定のTesseraV市場をstale pool、つまり状態が古い候補として除外するログも確認しました。
一部の実例では、ログから逆算した経過slot数と、ペア別状態口座内の生データに一致する値が見つかっています。
これらの結果から、TesseraVでは状態の鮮度が交換可能性に関係している可能性が考えられます。
ただし、slot経過によって結果が変化したことと、どの口座のどの値が原因で変化したのかを特定したことは別です。
現在も、その対応関係の調査を進めています。
ここでは、ペア別状態口座、別途更新される状態口座、更新命令、Swap処理の関係を暫定的に整理しています。
なお、この図では更新・参照が確認できた関係は実線で示し、各フィールドが価格や交換条件へ及ぼす作用については未解明として破線で表現しています。
今回の段階で分かったのは、状態口座が存在するということだけではありません。
状態が更新されること、交換処理から参照されること、一部の交換条件には鮮度に依存する挙動があることまで、実際の取引やシミュレーションから確認できています。
一方で、それらの関係を完全に説明できる段階ではありません。
5．取引経路とデータ観測を分けて検証する
今回、もう一つ整理が進んだのが、実際の取引経路とデータ取得方法の違いです。
調査の初期段階では、Jupiterを使ってBisonFiやTesseraVの見積もりや取引情報を確認していました。
しかし、Jupiterは両プロトコルの必須構成要素ではありません。
Jupiterは複数の流動性供給先を比較するアグリゲーターであり、その内部には交換経路を選択するルーティング機能があります。
公式のAMM連携仕様でも、外部AMMから必要な状態を取得し、見積もりとオンチェーン実行の整合性を検証する仕組みが説明されています。
ただし、実際の交換が必ずJupiterを経由するわけではありません。
今回の調査では、TesseraVでDFlow経由の成功Swapを確認しました。BisonFiでも、Jupiterのオンチェーン呼出しを伴わない成功取引を確認しています。
オンチェーンの呼出しにJupiterが存在しないことだけで、オフチェーンの取引組成まで含めた関与を完全に否定することはできませんが、少なくとも取引経路はJupiterに限定されていません。
したがって、Jupiterで見積もりが返らないことだけを理由に、プロトコル全体が利用できないと判断するのは適切ではありません。
現在はSolanaから直接データを取得している
現在の研究観測では、Jupiterをデータ取得の入口にしていません。
Solanaの公開RPCとWebSocketを使い、対象プロトコルから直接、更新や実行に関する情報を取得しています。
主に利用しているのは、次の情報です。
- Programログ：どのプログラムが呼び出され、処理が成功・失敗したかなどの実行記録
- 状態口座の更新：プログラムが管理するデータアカウントに変更があったという通知
- 取引本文：取引内の命令、トークン移動、残高変化などの詳細情報
なお、状態口座の更新とVault残高の更新は同じではありません。今回の主な口座更新監視は、プロトコルが所有する状態データを対象にしています。
実際に成立した交換の数量を調べる場合には、取引署名から本文を取得し、命令やトークン移動を照合する必要があります。
この処理によって、成立済み取引の投入数量、受取数量、実績平均価格を復元できます。
BisonFiでは自作の解析処理で一部のSwapの復元が成立し、TesseraVでも既存パーサーを用いた成功取引の復元を確認しています。
ただし、全商品・全取引の捕捉が成立しているわけではありません。
取得できる情報と市場評価は別の段階にある
ここで、今回の研究の対象範囲も明確になりました。
市場データを扱う工程は、大きく3つに分けられます。
| 段階 | 確認する内容 | 現在の到達点 |
|---|---|---|
| 取得 | 状態、ログ、取引本文、欠測やエラー | 継続取得を実施中 |
| 解釈 | 市場の識別、数量、実績平均価格 | 一部の成立済み取引で成功 |
| 評価 | 現在の執行可能価格、外部価格との乖離、採算 | 今回の主な検証対象外 |
当初は外部市場の価格も取得し、PropAMMで成立した交換価格との差を調べていました。
しかし、その外部参照値自体についても、データの出所、更新タイミング、市場時間、価格の算出方法などを検証する必要があります。
特に株式系商品では、参照価格がどの市場や情報提供者の値に由来するのか、時間外にどのように更新されるのかが十分に確認できていませんでした。
そこで現在は、外部価格との比較を切り離し、まずプロトコル由来の情報取得と解釈に集中しています。
継続監視は成立しているが、取得範囲には制限がある
現在はBisonFiとTesseraVについて、独立した監視系を稼働させています。
WebSocketで受信した原データを保存し、必要な取引本文を補助的に取得する構成です。
再接続や保存データの再生検算も確認しています。
ただし、取引本文には取得頻度の制限を設けており、全取引の詳細を収集しているわけではありません。
また、WebSocketが切断された期間の全履歴を補完できる構成にもなっていません。
したがって、今回の観測は、各プロトコルから何が取得できるか、その制約がどこにあるかを調べる段階です。
取引標本が少ない市場についても、それだけで市場活動が少ないと判断することはできません。
実際の取引頻度と、自分たちの取得処理によって観測できた範囲は、分けて評価する必要があります。
6．PropAMMの理解を更新し、未解明の市場構造を追う
今回の調査を振り返ると、PropAMMに対する理解はいくつかの点で変わりました。
最初は、専門的なマーケットメーカーが独自の流動性プールを提供する仕組みという、かなり大まかな認識でした。
そこから実際のプロトコルを調べ、価格提示、状態管理、資金保管、取引経路、データ観測を分けて考えるようになりました。
今回の認識の変化を整理すると、次のようになります。
| 当初の認識 | 今回の調査を踏まえた理解 |
|---|---|
| 企業が運営する独自プール | マーケットメーカーが価格提示条件を能動的に管理する仕組み |
| 市場ごとに資金プールがある | 状態口座とVaultは一対一とは限らない |
| 同じトークン名なら同じ市場 | mint・原資産・発行体・利用条件を分けて確認する必要がある |
| Jupiterが主な取引の入口 | 複数の取引経路が存在し、直接観測も可能 |
| 取引価格を取得すれば価格を把握できる | 成立済み取引の実績価格と現在の執行可能価格は異なる |
もちろん、今回見つかった構造のすべてがPropAMM固有というわけではありません。
共有Vaultや複数市場の管理などは、ほかのDeFiプロトコルにも存在する仕組みです。
その一方で、マーケットメーカーが価格を能動的に更新し、オンチェーン上の状態や取引条件を通じて流動性を提供する点は、PropAMMを理解するうえで重要な特徴です。
そして、それらが具体的にどのように組み合わされているかは、プロトコルごとに異なります。
今回のTesseraVの調査では、ペア別状態口座と別途更新される状態口座、共有Vaultの実例、状態の鮮度に関係する挙動などを確認できました。
ただし、内部データの意味や、価格・数量・交換条件への具体的な作用については、まだ検証中です。
ここから先は、状態の更新命令と実際の交換をさらに対応付けることで、理解を深められる可能性があります。
また、BisonFiについても、取り扱い商品が広いことと、実際に利用できる市場や流動性が広いことは別です。
今後は、商品ごとの利用可能性や実際の取引活動についても、取得できるデータから確認していく必要があります。
以前の開発記録#601「Solanaのボトルネックを追う――実取引と流動性の経済構造調査」では、市場のどこで流動性や資本が必要とされ、誰がその制約を引き受けているのかという視点から調査を進めました。
今回のPropAMM研究も、その延長にあります。
ただし、今の段階で収益機会が確認できたわけではありません。
実際の市場構造やデータ取得の限界を理解することと、その市場で継続的に利益を得られることは別の問題です。
まずは、実際に存在する市場を構成要素ごとに捉え、どの情報が観測可能で、何がまだ判断できないのかを明確にしていきます。
今回の研究で得られたのは、単にBisonFiとTesseraVの仕様をいくつか知ったということだけではありません。
PropAMMという市場を、独自の流動性プールという一つの概念だけで捉えるのではなく、価格提示・状態管理・資金保管・取引執行・外部接続の関係として具体的に見るようになったこと。
これが、今日の一番大きな理解の更新だったと思います。
引き続き、実際の取引とオンチェーンの状態を追いながら、まだ説明できていない部分を少しずつ明らかにしていきます。
それでは、また。