UniswapX と 1inch Fusion で実現する Pocket Exchange

目次

• はじめに {#introduction}
• UniswapX と 1inch Fusion {#uniswapx-and-1inch-fusion}
• 1inch Fusion：古典的なダッチオークション {#1inch-fusion-the-classic-dutch-auction}
• Uniswap X：2 段階の差別化オークション {#uniswap-x-a-two-stage-differentiated-auction}
• 学び {#learnings}
• モニタリング & データ取得 {#monitoring–data-acquisition}
  • クエリの構成要素とその意味 {#the-query-parts–their-significance}
  • 結論：「サーバーサイド SQL」の価値提案 {#conclusion-the-server-side-sql-value-proposition}
• 好機をつかむ：研究から収益へ {#seizing-the-opportunity-from-research-to-revenue}
• 研究チームではなく、市場のリーダーに。 {#become-a-market-leader-not-a-research-team}

はじめに

本稿では、完了済みのリサーチプロジェクトから得られた知見と発見の一部を共有します。私たちは、トレーディングにおけるゲーム理論の観点から UniswapX プロトコルの経済モデルを算定するために依頼されました。UniswapX や類似プロトコルの発想は極めて興味深く、巨額の資本を持つプレイヤーが、プロトコルや流動性提供者（LP）のリスクを抑えつつマーケットメイキングに参加できる点に魅力があります。オーダーブックを自ら管理せず、Uniswap によって提示される注文を充足するだけの取引所を通じて、資本を効率的に使いたい方にとって、本稿は良い出発点となるでしょう。

金融サービスの分散化は新たなデジタル経済の不可欠な要素となりましたが、多くの利点と同時に、いくつかの課題ももたらしました。つい最近まで、これらの課題は、あるデジタルアセットから別のアセットへ流動性を移す必要があるすべての人を悩ませてきました。分散型暗号資産取引所（DEX）の一般ユーザーは長年、他人のスワップを「サンドイッチ」するボット、ネットワーク負荷の急増に伴う手数料の高騰、スワップ画面の見積りを実質的に無意味にする不可測なスリッページといったおなじみの頭痛の種に直面してきました。初期世代の AMM（Uniswap V2/V3）は、受動的流動性提供の課題には対処したものの、スワップ実行そのものに内在する欠陥を十分に補正したわけではありません。

状況が本質的に変わり始めたのは、インテントベースのスワップ機構という急進的な新しいパラダイムの台頭からです。従来方式では、トランザクションの準備責任はスワップの発起者にあり（サービスは、取引が許容できる場合に資金を解放するための署名を行うだけ）、インテントプロトコルでは、ユーザーは準備されたトランザクションやその周辺条件の詳細から完全に抽象化できます。あるトークン X を少なくともトークン Y と交換したいという意図への署名により、その他のすべての意思決定はサービスに委ねられ、スマートコントラクトによる保証のおかげで信頼不要に遂行されます。堅牢なアーキテクチャであれば、サービスも選ばれた相手方も、ユーザーの宣言した意図から外れたパラメータでトランザクションを実行することはできません。

ここでは、このアーキテクチャ思想の最も影響力のある 2 つの具現化――Uniswap X と 1inch Fusion――を比較します。両者は古典的なダッチオークションという堅固な基盤の上に立ちながら、実装の細部において経済的にも興味深い差異を見せます。

UniswapX と 1inch Fusion

本稿公開時点の最新版として、UniswapX V2 がメインネットにデプロイされています。

通常どおり、V1 と V2 の包括的なドキュメントは Uniswap のドキュメントサイトにあります。

まず、両システムが是正を目指す従来ワークフローの課題を確認しましょう。標準的な取引（取引所でもエスクロー経由の p2p でも）では、発起者が事実上プロセス全体を自力でこなします。すなわち、十分な深さのある流動性ソース（大口取引なら複数）を見つけ、（初回はネットワーク手数料を払って）トークンをエスクローまたは取引所に送金し、為替レートをロック（不利なら中止）し、最後に、やはり自分の負担で、受け取り金（あるいは未使用の入力トークン）をウォレットへ引き出します。満額受け取れるかは、各流動性ソースでの処理成功に依存します。どこかでレートが大きく滑れば、トレーダーは sunk cost を抱えたまま別の流動性を探すことになります。これには手数料、価格変動、機会損失などが含まれ得ます。また、流動性ソースを選んでから実際にレートをロックするまでの時間差は、相手方に MEV（最大抽出可能価値）を狙った価格操作の誘惑を与えてしまいます。この不運な現状は、いくつかの切迫した問いを突きつけます。

• MEV 脅威：実行順序の操作で他者の取引から価値を略奪するボットから、ユーザーを保護できるか？ • 流動性の分断：多数の取引所やプライベート在庫に散らばる何百もの流動性ソースへ、統合の複雑さを隠蔽したシンプルで低コストな 1 回の操作でアクセスさせられるか？ • サンクコストのリスク：何らかの理由で失敗した取引に対し、ユーザーが費用を払わずに済むか？

1inch Fusion と Uniswap X は、これらの問いにほぼ同様の答えを示します。スワップ注文をプロの実行者間のオークションとして再定式化するのです。クライアントに奉仕する権利を巡って相手方に競争させることは、一挙に複数の課題を解決します。

• 失敗トランザクションからの保護：このモデルではユーザーはトランザクションを準備しません。指定パラメータの注文に対して最適な実行者を探す指示に、無料で署名するだけです。ネットワーク手数料や失敗時の潜在損失は市場スプレッドに内在化され、実行者は競争圧力の下でリスクを正確に価格付けすることにより、それを最小化します。

• MEV をクライアントの利益へ：マーケットメイカーの正当な利潤最大化は、競争という自然な歯止めと組み合わさって、陰から陽へ出てきます。契約書に記載された価格は、資金がユーザーのウォレットを出る前に固定され、価格操作の時間窓を残しません。最良のスプレッドを提示した者が実行します。

• 分断流動性の透明な集約：この仕組みは当事者間の契約を強制するだけで、実行者に共通プールへ事前入金を求めません。トークンの出どころがどこであれ、期限内にクライアントのウォレットへ届けばよい――それがオークションの観点です。これにより、実行者は市場のあらゆる流動性を単一窓口から事実上リセールできます。

この経済モデルが発起者のスワップを劇的に単純化する一方で、実行者の側は複雑になることは見逃せません。古典的な取引所（流動性を入れて価格を掲示し、買い手を受動的に待つだけ）と違い、オークション方式では、実行側はタイトな期限のもと意思決定項目が激増します。自動化は不可欠です。厳しい応答時間と、常時スタンバイ状態を作る必要があり、人間がロボットに勝つ余地はありません。以下では、両プラットフォームにおいてどのような経済的意思決定が自動化を必然にするのかを掘り下げます。

1inch Fusion と Uniswap X は、概略では同じ中核思想を実装しますが、機構設計においては相当に異なります。まず 1inch から、個別に見ていき、その後で比較します。

1inch Fusion：古典的なダッチオークション

このプロトコルは「シンプル・イズ・エレガント」の原則を体現しています。 ここでは 1inch Fusion を使ったトランザクションの流れを分解します。注文は3 つの数値（開始価格、リザーブ価格、オークション時間）だけで構成され、最もクライアントに有利な価格から始まり、期間にわたり直線的に悲観的なリザーブ価格へ滑っていく連続オークションに掲載されます。オークション（現行版）はクローズドで、実行者は登録と KYC を通過する必要があります。掲載された注文に応じる参加者は、ユーザー署名済みの指示に従って、ユーザーのウォレットからトークンを双方向エスクローに移し、そのオンチェーン取り込み時刻を厳密に記録させます。最初にこれを行った者が落札し、結果価格は注文パラメータとエスクロー開設時刻から決定論的に計算されます。以後、実行者は排他期間を享受し、その間にカウンター方向のエスクローへ、ユーザーが受け取るべきトークンを所定量入金して自らの義務を履行できます。最終ステップはエスクローのクローズで、両方向に凍結された資金を同時に解放します。この最終ステップの手数料も、排他期間が切れる前に実行者が負担します。

オークションや排他期間の具体的な時間枠はプロトコルで固定されておらず、サービス提供者に委ねられます。執筆時点では、1inch の案内・実務の双方で、大多数のスワップは 5 分以内に完了しています。

もし問題が生じ、実行者がユーザー資金を凍結したまま途中で停止した場合、排他期間の終了後にはエスクローのクローズ行為はパブリックになります。ネットワーク手数料を支払えば、誰でも（1）カウンターエスクローが十分に資金投入されていないときはユーザーのトークンを全額返却でき、（2）十分な資金があるのに実行者が技術的理由でクローズできないときはスワップを完遂できます。パブリックなクローズに経済的な意味を持たせるため、プロトコルは、実行者に対しユーザー資金の凍結と並行してわずかな自己資金をエスクローへボンドとして入れることを要求します――これはネットワーク手数料を賄える程度の額です。これらの資金は常にエスクローのクローズに署名した者に支払われます。排他期間中は実行者に返還され、排他期間後はスワップの完了またはキャンセルを行った者の報酬になります。こうして、クライアントにとっては透明なまま、ニーズが満たされるのです。

Uniswap X：2 段階の差別化オークション

こちらはやや複雑ですが、その理由は明快です。プロトコルは実行者を2 つの不均等なグループに分け、異なる段階で行動させます。クライアントの注文に最初に関わるのは、登録・KYC 済みの Quoter（クォーター；見積り提供者）で、その作業はユーザーが何かに署名する前から始まっています。ユーザーがトレード方向を選び、希望数量（売る量または買う量）をフォームに入力すると、その注文の下書きが当該方向を担当するすべての Quoter にブロードキャストされます。各 Quoter はきわめて迅速（概ね 0.5 秒以内）に見積り――すなわち相手側数量――で応答することが求められます。ユーザーが一定量を売るなら、見積りは実行者が支払う価格。一定量を買うなら、実行者がそのトークンを売る価格です。

いずれの場合も、Quoter はクライアントに最も有利な見積りを巡って競争します。プラットフォームは勝者を選び、その見積りをスワップフォームに表示し、ユーザーに支払い指示への署名を促します。その瞬間から、勝者の Quoter は、カウントダウン（30 秒）が切れるまでにユーザーが署名すれば、その見積りを履行する義務を負います。この段階は勝者の Quoter に排他的です。署名済み指示の実行にもオンチェーンの期限が設けられ、それが切れると不履行とみなされ、注文は排他段階の失敗となります。期限までに約定を果たせなかった Quoter は、一時的に新規注文への見積り参加が停止されます。

Uniswap の呼ぶこの初期クールダウン（“fading”）は15 分から始まり、連続失敗ごとに指数関数的に延長されます。ただし、各フェード終了後に1 件でも成功すると、ペナルティのエスカレーションはリセットされます。

勝者が放棄した注文だけが第 2 段階へ進みます。そこでは、前述の 1inch Fusion に酷似した、より典型的なダッチオークションが行われます。ここでの最も重要な経済的差は、Uniswap X の第 2 段階が登録不要で公開されていることです。排他期間の終了からリザーブ価格に達するまでの間は、誰でも実行者（Filler）として行動でき、競争の一層の激化により最終スプレッドがさらに圧縮されるはずです。

この追加の複雑さは無駄ではありません。ユーザーが署名する前の段階で、見えている価格を履行する義務を Quoter に負わせることで、Uniswap X は、他では再現の難しい優れた UXを創り出します。比較のために言えば、1inch Fusion では署名時に見える為替レートは、プラットフォームによる近似的で拘束力のない見積りに過ぎません。最終価格は、開始価格とリザーブ価格のどこかで（時に長い）オークションの間に決まります。

×

Uniswap X では圧倒的多数のケースで、ユーザーは「Approve and swap」を押した直後に実際に送受信される数量を見ながら署名を決めます。Quoter が完了に失敗する事例は比較的まれで、第 2 段階の公開ダッチオークションは安全網の役割を果たすに過ぎません。

定性的な経済分析から、この有用な機能が無償ではないことが示唆されます。Uniswap X で Quoter が負う追加の義務とリスクは、同じ名目上のスプレッドでも、より保守的な収益期待へと自然に彼らを向かわせます。ボラティリティの高いトークンが絡むスワップ（または通常は安定ペアでも相場が荒い期間）では、1inch Fusion の古典的ダッチの方が、平均的にはクライアントの注文からより小さな取り分しか取らない可能性があります。

学び

Uniswap X 向けの自動マーケットメイカー（ボット）を経済面で助言した実務経験、および 1inch Fusion でのクロスチェーン取引機能プロトタイピング（ハッカソン）から得られた要点は次のとおりです。

プラットフォーム選択に関わらず、インテントベース・プロトコル向けの自動マーケットメイカーは、機械的に非自明な成果物です。その成否は、プラットフォーム連携という技術課題の解決だけでなく、相互に関連する 2 つの経済的ポイントを戦略で押さえられるかにかかっています。

第一に、ボットの有効性は、扱うペアに対して見積りを素早く正確に価格付けし、市況変化に即応してアルゴリズムを調整できる能力に直結します。最適な見積りを導くための一次シグナルの選択が極めて重要です。自然な候補は、CEX のマーク価格や現物板の生データ。これらは市場動向に迅速に反応する見積り推定を可能にします。

第二に、ボットの収益性を本気で最適化するには、流動性リザーブの効率的管理に細心の注意を払う必要があります。インテント系プロトコルは、実行者が市場のあらゆるソースから不足流動性を引っ張れるとはいえ、自前のウォレットに十分な運転リザーブを維持することはトランザクションコストの大幅な削減につながります。

これらはアルゴリズムで扱うべき問題――つまり、金銭判断をプログラムに委譲する設計ですから、市場分析のためのデータアクセスが特に重要になります。伝統的な取引所では、参加者は情報取得の方法に応じて大別して 3 つ：長期投資家（ニュース等）、デイトレーダー（Nansen / Arkham / Etherscan のダッシュボード）、HFT ロボット（プラットフォームの生 APIをリッスン）。インテント系の実行自動化は、データ要件の観点でデイトレードと HFT の中間に位置します。一方で、もはや人間に全責任を負わせられません。他方で、プロトコル内のタイミングは現代の自動化基準では穏やかです。最もタイトなのは Uniswap X の見積り 0.5 秒で、それ以外はブロック単位（Ethereum なら12 秒）。HFT と異なり、イベント反応速度が工学的な難題にはなりません。12 秒という枠は十分に寛容で、これを落とすのは設計や運用の重大なミスでしょう。

したがって、見積りの精度と流動性管理の最適化の必要性が、オークションモデルにおいて自ずと浮かび上がります。常により良い価格を提示しながら黒字を維持できるボットが、市場の収益を総取りします。

このように中間的なデータ要求ゆえ、従来のデータソースにはいくつかの不都合があります。Nansen / Arkham / Etherscan のようなGUI ダッシュボードは、主にデイトレ向けで、市場活動の射影は限定的。急変環境での特定意思決定の支援という利便性は否めない一方、アルゴリズムのパラメータを磨くための精緻な統計研究には向きません。手作業では扱い切れない大規模データの集計・フィルタが必要になり、テンプレ GUI の利用は実務的でないのです。

逆に、生のブロックチェーン API や取引プラットフォームを使うと、自動化の自由は得られるものの、統計研究はたちまち「干し草の山から針探し」の別個のエンジニアリング課題に化けます。最も手軽だが単調なツールのひとつが Etherscan でしょう。Etherscan はトランザクション、ウォレット、コントラクトの大量のデータを提供しますが、特定のアドレスの正体などを事前に把握していないと、苛立たしい体験になりがちです（干し草＝膨大な情報、針＝求める精密な詳細）。本件文脈では、Uniswap X の特定 Filler のトランザクションを見るなど、ピンポイント用途に向いています。結局、エコノミストの机に届く前に、データは有能なデータサイエンティストの手で、低レベル API から噴出するデジタル鉱滓の山から有益な粒を抽出する工程を経るのが必然です。幸いにも、Dune の存在により、この問題は部分的に回避できます。

モニタリング & データ取得

ここで、Dune プラットフォームが方法論的な “スイートスポット”として登場します。プラットフォーム自身がデータ取り込み・デコード・構造化という巨大なエンジニアリング作業を担い、アナリストは精製済みデータに対する粒度の高いクエリ能力を保持できるのです。

Dune では誰でも公開/非公開ダッシュボードを作成でき、表面上はオンチェーン取引データを使った可視化が中心に見えます。まずはこの表層から、仕組みの実用へと掘り下げます。

私たちのリサーチ段階では、Uniswap X の Filler 活動を容易に追跡できる公開ダッシュボードはほとんどなく、実質的に信頼できるものは 1 つだけでした。

@flashbots による Uniswap X のダッシュボードには、アクティブな Filler に加え、ボリューム、注文サイズ、Filler、トランザクションハッシュなどの重要情報が並びます。

このダッシュボードは廃止されている、あるいは更新が滞っている可能性があります

いくつかの公開データを見てみましょう。 デフォルトで 2 つのビューがあり、上部は週間統計、下部は累積です。

まずは週間ビューに注目します。

×

トレードの種類（および方向）を把握するのに最も有用なクエリが、Top 10 Volume Tokens Grouped by Filler です。これで上位ウォレット（Filler）が分かるだけでなく、最大ボリュームの取引が USDC と WETH（Wrapped Ethereum）ペアで発生していることが明確に見て取れます。

×

Wrapped Ethereum（wETH）は、Ethereum（ETH）を 1:1 で表現する ERC-20 トークンで、DeFi アプリや ERC-20 準拠プラットフォームでの互換性をもたらします。ETH は Ethereum のネイティブ通貨ですが ERC-20 トークンではないため、多くの dApp ではそのまま使えません。

ただし、このダッシュボードは有用ではあるものの、現状では Uniswap X 向けの洗練された自動マーケットメイカー（ボット）の要件をすべて満たしてはいません。Filler の推定 ROI、トランザクションコスト、ポートフォリオ履歴や配分といった基本指標でさえ、ここから容易には得られません。さらにリスク管理、流動性調達、パフォーマンス分析といったより複雑な概念へ抽象化する場合、精密に洗練されたアプローチが必要です。

Dune のサーバーサイド SQLモデルは、データアクセスの**「ゴルディロックス・ゾーン」**を提供します。その抽象度は次のとおりです。

• Raw API より高い：アナリストは 16 進ログのデコード、トークン小数の調整、複雑なインデキシング・パイプラインの構築を行う必要がありません。データはすでに正規化され、erc20.transfers や dex.trades といった関係テーブルで提供されます。
• GUI ダッシュボードより低くて豊富：Nansen や Arkham の事前構築ビューとは異なり、Dune は基盤データへ直接アクセスさせます。問える質問に人工的制限はありません。アナリストは独自の手数料ボラティリティ指標を算出し、3 つのプロトコルに跨る流動性提供の相関を取り、新しい MEV 戦略の収益性を単一の SQLでモデル化できます。

この能力は単なる利便ではなく、インテント系システムの経済設計にとっての根本的な推進力です。これらのプロトコルで重要なのは、純粋な実行速度ではなく経済最適化へとシフトします。ソルバー（実行者）の収益性――ひいてはネットワーク全体の健全性――は、彼らが次をどれだけうまくやれるかにかかっています。

1. リスクと機会の精密価格付け：現スポット価格以上の情報が必要です。競合ソルバーがより良いルートを見つける確率、大口スワップが次ブロックで市場を動かす確率、不履行の暗黙コスト。これには DEX、レンディング、ブリッジのデータを結合する複合クエリが必要です。
2. 流動性調達の最適化：オークションモデルの勝者総取りに近いダイナミクスでは、流動性調達の限界改善が最重要です。ソルバーはプールやチェーンを跨いだ分断流動性を分析し、ガスコストをモデル化し、ユーザーのインテントと束ねられるアービトラージ機会を特定して、より競争的な見積りを提示します。これは統合的課題で、静的ダッシュボードには不向き、探索的 SQLには最適です。
3. 事後分析と競合解析：特定の注文をなぜ競合が勝ったのか？ その見積りが異常に良かったのは新奇ルーティングの示唆か？ 過去の任意ブロック時点の市場状況を再生し、競合ソルバーのオンチェーン行動をクエリすることで、成功戦略をリバースエンジニアリングし、自身のモデルの弱点を炙り出せます。これは Dune の履歴データで標準的に可能です。

要するに、Dune は経済 R&D の計算基盤です。大企業の専有データ基盤が独占していたような深い定量分析を、少人数の研究・開発チームでも行えるようにします。サーバーサイド SQL の威力と利便を示すため、たとえばUniswap X のトランザクション集計による ROI 分析に用いたメインの SQL クエリ（このラッパーでパラメタ化・フィルタ）を挙げられます。以下では、GUI ダッシュボードやRaw APIでは極めて難しい、しかし Dune では容易な意味要素を分解します。

×

クエリの構成要素とその意味

パート A：get_transfers CTE ― トークン転送とネイティブ ETH の統合処理

WITH
  get_transfers AS (
    SELECT ... FROM erc20_ethereum.evt_Transfer ...
    UNION ALL
    SELECT ... FROM ethereum.traces ...
  )

• 目的：各トランザクションにおけるトークン転送（ERC‑20）とネイティブ ETH 転送を統一ビュー化します。経済分析では両方の資産移動を考慮する必要があります。

• 利点（例）：生データの自動デコード。

  • Raw APIなら：

    1. すべてのトランザクションレシートを取得し、ABI で 16 進ログをデコードして ERC‑20 転送を識別。
    2. ethereum.traces で value を持つ CALL を別途解析してネイティブ ETH 移動を抽出。
    3. 構造の異なるデータを手作業で突合し統合。

  • Duneなら：erc20_ethereum.evt_Transfer と ethereum.traces が前処理済み・標準化済み。正規化の重労働は不要です。

パート B：logs CTE ― プロトコルイベントの集約

  logs AS (
    SELECT * FROM uniswap_ethereum.V2DutchOrderReactor_evt_Fill ...
    UNION ALL
    SELECT * FROM uniswap_ethereum.ExclusiveDutchOrderReactor_evt_Fill ...
  )

• 目的：Uniswap X の異なるバージョンのスマートコントラクトから Fill イベントを合算します。

• 利点：コントラクト差異や版の抽象化。

  • GUIでは：「Uniswap のボリューム」は見えても、「Filler の収益性」のような特化ビュー、ましてや複数契約版の統合はほぼ不可能。
  • Duneなら：低レベルのイベントが可読テーブルで用意され、簡単に統合できます。アドレスや ABI を暗記する必要はありません。

パート C：txs_with_evt_fill CTE ― ラベルと価格によるトランザクション拡充

      JOIN ethereum.transactions tx ON x.evt_tx_hash = tx.hash
      LEFT JOIN prices.usd pu ON ... -- TX 手数料の USD 評価
      LEFT JOIN query_2812729 labels ON x.filler = labels.address -- Filler ラベル

• 目的：手数料（ガス）、USD 評価、ラベルを結合し、実体を伴ったトランザクションにします。

• 利点：その場でのデータ拡充。

  • Raw APIなら：手数料の USD 化には、当該ブロック時刻の ETH 価格を別 APIから取得して手組み JOIN。
  • ラベリング問題：Arkham のような GUI では「誰か」をプロプライエタリに扱いますが、Dune では民主化されています。query_2812729 はコミュニティ主導のラベル集で、誰でも参照・フォーク・貢献可能。秘伝のタレを公共財へ。

パート D：get_swapper_txs CTE と後続集計 ― ビジネスロジックの核

CASE WHEN transfers."to" = fill.swapper THEN true ... END as to_swapper
...
CASE transfers."to" WHEN 0x000000fee13a103A10D593b9AE06b3e05F2E7E1c THEN true ... END as to_uniswap

• 目的：トランザクション内のすべての資産フローを経済的に分類します。

  • スワッパーから送信（インプット）
  • スワッパーへ送信（アウトプット）
  • 既知の Uniswap 手数料アドレスへ送信（プロトコル手数料/LP リワード）

• 利点：独自の経済モデルをSQL で直接表現。

  • GUIでは：既定メトリクス（ボリューム、TVL 等）に縛られる。Filler の純利益（スプレッドから手数料とガスを差し引く）などは困難。
  • Duneなら：CASE と SUM の組み合わせで即実装できます。

パート E：ラッパークエリ ― パラメタ化とフィルタ

from "query_5383565(days_num='60')"
where contains(array[ 'DAI-USDT', 'DAI-USDC' ... ], token_pair)

• 目的：複雑なメインクエリを再利用可能なデータソースにし、期間や銘柄ペアを引数・フィルタで切り替え可能にします。
• 利点：合成性と再利用性。一度作った深い分析を、他期間・他ペアへ手直しなしで展開できます。

結論：「サーバーサイド SQL」の価値提案

この単一クエリは、前述の「中間位置」にぴたりとハマるタスクを処理します。これは既製 GUIに載せるには複雑すぎ、Raw APIでやるなら数週間のエンジニアリング（デコード、価格フィード、ラベリングのパイプライン構築）が必要です。

Dune では、たった 1 人のアナリストで扱えます。

この方法論により、研究者は経済ロジック（CASE、JOIN、SUM）に完全に集中でき、データ配管（ログデコード、価格取得、小数管理）に気を取られません。これこそがサーバーサイド SQLの究極の便益です。ブロックチェーンはオープンでデータは豊富ですが、意味を与えるのは容易ではありません。 私たちはリサーチ期間を通じて、特に Uniswap X の Filler のトランザクションや活動を監視するために、複数のリソースを使い、また作成しました。本件ではクライアントの要望により、対象をEthereum メインネットに限定しました。数理モデルや完全なデータセット、最終成果は共有できませんが、この種のモニタリング/取得で何が重要か、方法と理由を解説することで、複雑なシステムの構築・研究に関する一端を示せたと考えます。

好機をつかむ：研究から収益へ

アーキテクチャの観点から、効率的な自動マーケットメイキング・ボットの複雑さを説明してきました。ここで、それが適切な指導と支援のもとでどのような収益機会を開くかに触れます。理解と実運用は全く別物です。

総スワップ数は当初の調査時点に比べて増加しているようですが、ユニーク Filler 数はそれに比例して増えてはいません。

これは、既存の洗練された Fillerが、ほとんど競合なく拡大する利益を取り込んでいることを意味します。

オンチェーンのマーケットメイカーと競う難しさは、情報取得の方法だけではありません。予算、ポートフォリオ管理、インフラ要件など、効率的なボットを実際にデプロイするための考慮事項が多々あります。

私たちは、Uniswap X のようなマーケットメイキング・プラットフォームに参加する際の高い参入障壁を、研究と経験によって下げることができます。

私たちのチームは、リサーチとコンサルティングを通じて、正しい方向へ導きます。クライアントのビジョンを実現するための研究とツールは、すでに整っています。

示したとおり、参入障壁は資本ではありません。莫大な技術的・経済的複雑性です。成功するマーケットメイキング運用には次が必要です。

• 正確な価格付け：サブ秒のリアルタイム・リスク/プライシング・アルゴリズム
• 最適化された流動性：多様なソースからの効率的な調達戦略
• 堅牢なインフラ：500ms 未満で見積り応答し続ける24/7 高可用システム
• 継続的 R&D：競合戦略をモデル化する継続的な深いデータ分析

これをゼロから構築するのは、長く高コストな R&D の挑戦です。R&D は、私たちがすでに完了しています。

私たちは画一的なボットを提供しません。ファンドや大口資本プレイヤーと提携し、専有リサーチを活用したカスタムのマーケットメイキング・ソリューションを設計・構築・デプロイします。

資本と戦略的ビジョンをご提供ください。エンジンを作る専門チームは私たちが提供します。

このパートナーシップは、ゼロから始める場合に比べ、時間とコストを大幅に節約して市場投入へ導きます。私たちは次を共創します。

• カスタム戦略：リスク許容度と資本規模に合わせて、専有アルゴリズムを設計・モデル化・デプロイ
• 専用データ & アナリティクス：公開クエリを超える真の優位性をもたらす、専用のリアルタイムダッシュボードとデータパイプライン
• カスタム・ポートフォリオ自動化：流動性リザーブの効率的管理、ヘッジ、リバランスのための自動化ツール

研究チームではなく、市場のリーダーに。

私たちの完了済みリサーチの上に構築すれば、過酷な R&D フェーズを回避し、機関投資家グレードのシステム構築へ直行できます。

私たちは一流 Web3 プロトコルの信頼できる R&D チームであり、同じレベルの機関グレードの専門性をマーケットメイキングのクライアントにも提供します。

チャンスの窓は今開いていますが、長くは続きません。研究フェーズに予算を費やさないでください。

今すぐプライベート相談にお申し込みいただき、高性能なカスタム・マーケットメイキング・ボットの構築についてご相談ください。

このブログ記事の議論に参加してください: