Hyperliquid：フロントエンド戦争

出典：Blockworks
原題：Hyperliquid：フロントエンド戦争
元リンク：https://blockworks.co/news/hyperliquid-the-frontend-wars

Hyperliquidの中核的なイノベーションのひとつがビルダーコードです。これらのコードはトランザクションペイロード内のプロトコルレベルのパラメータとして機能し、インターフェースが自動的にオンチェーンで手数料を取得するためのビルダーアドレスを追加できるようにします。ビルダーはスポットで最大100ベーシスポイント（(1%)）、パーペチュアルで10ベーシスポイント（(0.1%)）までのサーチャージを追加できます。

この実行と決済の切り離しにより、フロントエンドはオーダーブックの維持や流動性確保のための資本非効率性といった技術的な複雑さなしに、独自フローを収益化することが可能になります。下図のように、サードパーティのフロントエンドはHyperliquidパーペチュアルを統合し、その上に独自の可変手数料階層を追加することで、同一の基礎的な実行に対し、差別化された価格体系を実現しています。

このように、ビルダーコードは強力なディストリビューション・フライホイールを生み出しました。現在、デイリーアクティブユーザーの約40%がネイティブUIではなくサードパーティフロントエンドを通じて取引しており、10月末には一時的に50%を超えました。上位3つのビルダー、Based、Phantom、pvp.tradeだけで、$31 ミリオンを超える手数料を獲得しています。

市場構造の観点から見ると、これはHyperliquidを完全統合型の暗号資産取引所モデルから、伝統的な株式市場の階層的仲介モデルに近づけています。大手取引プラットフォームのような中央集権型取引所では、一つの事業体がオンボーディング、ルーティング、マッチング、カストディまで全てをコントロールしています。

Hyperliquidの設計は米国株式市場を模倣しており、小売ブローカーが顧客関係を所有し流通を収益化しつつ、注文を実行・決済を担うホールセーラーへルーティングします。実質的にスタックは2層構造となります：

• ブローカーのような流通層。ビルダーが注文フロー獲得と商品・手数料転嫁で競争。
• 中央の実行会場。Hyperliquidが流動性を集中させ、マッチングやマージン管理を担当。

暗号資産パーペチュアルにとっては新しい仕組みですが、この切り離しメカニズムは既にSolanaで実現済みです。PhotonやAxiomといった取引ターミナルは、消費者層にフォーカスすることでユーザーフローを掌握。Photonは最速のSolanaミームコインスナイパーとして成長し、Axiomはより広範な商品群と積極的なポイント・リベート設計で追随しました。これらのターミナルは実質的にビルダーとして機能し、DEXの上に独自の手数料を上乗せし、会計管理も手動で行っていました。Hyperliquidのビルダーコードはこのパターンをプロトコルネイティブなプリミティブに変換しています。

ただし、Solanaの事例はリスクも浮き彫りにします。取引ターミナルは過去1年間でSolanaのDEX収益の77%（$633 ミリオン対DEXの$188 ミリオン、3.4倍）を獲得しており、フロントエンドの所有がバックエンドより価値が高いことを示しています。具体的に言えば、フロントエンドはHyperliquidが手放すにはあまりにも価値が高すぎるのではないでしょうか？

フロントエンドとバックエンドの関係は、純粋に共生的ということはほとんどありません。Jupiterのようなフロントエンドは様々なバックエンドを集約し、サイズ・手数料・スリッページ制約に基づいて最適なルートを返します。

これによりDEXバックエンドは厳しいマージン圧縮を強いられます。モート（堀）がゼロであるため、フローを獲得するには最安値でなければなりません。ユーザーを所有していないので、バックエンドは置き換えリスクにもさらされます。実際、pump.funがRaydiumの流動性バックエンドを自社AMMに切り替えたことで、Raydiumのボリュームシェアが大きく減少しました。

現時点でHyperliquidはこの問題に直面していません。パーペチュアルでビルダーコードを先駆けて導入したことで、実質的に単一ビルダーコード環境となっています。しかし、ビルダーがHyperliquid上のUIから、競合バックエンドにもフローを送れる本格的なルーターへと進化した場合、伝統金融のスマートオーダールーターのようになります。このシナリオではビルダーは以下のことが可能となります：

• 総コストの最適化：スプレッド/スリッページ＋テイカー/メーカー手数料＋ビルダーサーチャージ−リベート＋想定ファンディングコストを計算
• 会場との交渉：フローを他会場にルーティングする脅威を用いて、より高いビルダーシェアやリベートを要求
• ユーザー関係の掌握：会場側は最安値・最高実行品質のリクイディティプロバイダーとして純粋に競争させられる

同様に、伝統金融でもホールセーラーはブローカーディーラーと出来高で競争します。

DriftやOstiumなど競合DEXもビルダーコードを導入していますが、現時点で本格的な競合は現れていません。しかし、構造的なリスクは依然として存在します。もしLighterのような会場がゼロ手数料モデルにビルダーリベートを組み合わせた場合、PhantomやRabbyのようなウォレットはHyperliquidの4.5bps手数料を回避できる可能性があります。これによりフロントエンドは手数料スタック全体を獲得でき、現在のHyperliquidモデルと比べて1取引あたりの収益が倍増することになります。

LiquidTradingはこの未来の先行指標です。Paradigmが支援するこのターミナルはHyperliquid上で56億ドルの取引高を実現していますが、同じインターフェースでOstiumやLighter上での取引も可能です。もしより大きなビルダーがこの流れに従い、忠誠心ではなく会場リベートに基づいて積極的にフローをルーティングし始めた場合、Hyperliquidビルダーフロントエンドはコモディティ化したパーペチュアルアグリゲーターへと進化し、プロトコルの価値捕捉能力を直接的に脅かします。

それでも根本的な違いがあります。スポットは各スワップがアトミックであり、資産が会場間でファンジブルなため、集約が容易です。1トランザクション＝1フィルであり、ルーターは複数プールに取引を分割できます。しかしパーペチュアルでは、ポジションは持続的かつ会場固有です。会場AのBTC-PERPポジションは、インデックス構成・ファンディングレート・清算エンジン・リスク制限の違いにより、会場BのBTC-PERPとはファンジブルではありません。

パーペチュアルを意味のある形で会場横断ルーティングするには、以下の2つの難題のいずれかが必要です：

• ユーザー断片化： ユーザーが複数会場に証拠金を置く必要があり、資本効率が悪くUXも悪化
• プライムブローカーレイヤー： ルーターがクリアリングレイヤーとして機能し、与信・クロスマージニング・清算調整という難問を解決

非ファンジビリティは短期的な防御策になりますが、現実としてフロントエンドは合理的な経済主体なので、競合がより高いマージンを提供すれば移行します。しかし、現時点ではこの脅威は抑えられているようです。サードパーティUIのユーザー数が多いにもかかわらず、取引高の90%以上は依然としてHyperliquidのネイティブフロントエンドから発生しています。

さらに、HYPEトークンはリテンションレイヤーとして機能します。ビルダーはHYPEを保有することで手数料割引を受けられ、紹介手数料、ビルダー手数料、取引高に基づく割引という複数の収益源を積み重ねられます。これにより、わずかに手数料が良いからといって既存フロントエンドが移行するインセンティブは高くありません。最後に、ビルダーからのフローはカニバリズムではなく追加的なものと見られます。これはインターフェースを切り替えた既存ユーザーではなく、ウォレットやターミナル経由で新規ユーザーがエコシステムに流入しているのです。

したがって、ビルダーコードは効果的な拡張ベクトルを提供しますが、Hyperliquidがディストリビューションレイヤーを完全支配し続けると期待するのは非現実的です。業界が成熟するにつれ、Hyperliquidはアグリゲーターや低手数料競合との競争でリードを守るため、より厳しい戦いに直面します。ただし、高性能なオンチェーンオーダーブックの構築は依然として大きな技術的参入障壁であり、フロントエンドのマージンが健全な限り、ビルダーが乗り換えるインセンティブは低いままです。それでも、急拡大する市場ではシェア維持の戦いではなく、より競争的な成長レースとなり、Hyperliquidが打倒すべきヘビー級の存在であり続けるでしょう。