Hyperliquidの全トレードがフロントエンドに報酬を支払う：ビルダーコードを解説する

サードパーティのウォレットやトレーディングターミナルを通じてHyperliquidで取引すると、使用しているアプリが手数料の一部を受け取る。あらゆる約定に対して。自動的に。オンチェーンで。USDCで。それがビルダーコードの仕組みだ。

この仕組みは一見シンプルに見える。Hyperliquidを通じて注文をルーティングするアプリであれば、各トレードに小さな手数料を付加できる。プロトコルはその手数料をビルダーのアドレスに直接支払う。トークンの発行も、サブスクリプションモデルも、パートナーシップの交渉も不要だ。約定からアプリへと手数料が流れるだけだ。累計で、Hyperliquidのビルダーエコシステムは1,411人の登録ビルダーから$9,000万超の収益を生み出しており、DeFiで最も静かに機能している収益化システムの一つとなっている。

このガイドでは、ビルダーコードの仕組み、誰が利益を得ているか、そして自分のアプリケーションに統合するために何が必要かを詳しく解説する。

仕組み：ビルダーコードの実際の動作

ビルダーコードは、Hyperliquidのマッチングエンジンに組み込まれたオンチェーンの手数料帰属メカニズムだ。ここで言う「ビルダー」とは、Hyperliquid上でアプリケーションを作るDeFiビルダーのことであり、「コード」とは彼らがルーティングする各注文に付加される手数料パラメータを指す。

このプロセスには3つのステップがある：

1. ユーザーの承認。 ビルダーがトレーダーから手数料を徴収する前に、そのトレーダーはメインウォレットからApproveBuilderFeeアクションに署名する必要がある（エージェントウォレットやAPIウォレットではこの操作を行えない）。 承認により、ビルダーが請求できる上限手数料が設定される。ユーザーはいつでもこの許可を取り消すことができ、各ウォレットは最大10件のアクティブなビルダーコード承認を保持できる。
2. 手数料の付加。 ビルダーは各注文にオプションのパラメータを含める：{"b": builder_address, "f": fee_in_tenths_of_bps}。手数料は注文ごとに設定できる柔軟な仕組みになっており、ビルダーが選択すれば異なるトレードに異なる料率を適用できる。
3. オンチェーン決済。 取引が成立すると、Hyperliquidの手数料ロジックが約定からビルダー手数料を差し引き、USDCでビルダーのアカウントにクレジットする。この手数料はプロトコルの標準的なメイカー/テイカー手数料に加算される形で請求される。

手数料上限とfパラメータ

手数料パラメータfはベーシスポイントの10分の1単位で測定される。f: 10は1ベーシスポイント（0.01%）、f: 100は10ベーシスポイント（0.10%）に相当し、これが永久先物の上限となる。 スポット市場では最大100ベーシスポイント（1%）が許容される。

$10,000の永久先物約定で上限の10bpsを適用した場合、ビルダーの収益は$10となる。より一般的な5bpsでは、同じ約定から$5が生まれる。ビルダーコードは、クォートまたは担保資産（USDC）で徴収される手数料にのみ適用されるため、スポット市場の買い側には適用されない。

最高収益者：ビルダーリーダーボード

2026年7月時点のデータ。HyperTrackerのビルダーリーダーボードより。

リーダーボードの上位を見ると、明確なパターンが浮かび上がる。最高収益を上げるビルダーは、ユーザーの日常的なワークフローに組み込まれたウォレットやトレーディングターミナルだ。Phantomが首位で、153,128人のユーザーと$448億のルーティングボリュームから$2,360万の累計ビルダー手数料収益を達成している。Crypto Briefingは、Phantomが2025年7月にHyperliquidとの統合をローンチして以来、$370億の取引ボリュームを処理し、ビルダーコード手数料で$2,000万を稼いだと報じた。 私たちのデータでは、その数字はすでに$2,300万を超えている。

Basedが2位で、$449億のボリュームに対して$1,520万の収益を上げている。ボリュームの数字は実際にPhantomを上回っているが、収益が低いのは、より少ない代わりに取引量の多いユーザー層にルーティングしているためだ（ユーザー数は42,967人で、Phantomの153,128人を大きく下回る）。MetaMaskとPVPはそれぞれ$800万前後に位置しており、MetaMaskは比較的最近（2025年8月）参入したにもかかわらず、すでに52,534人のユーザーを獲得している。

ランキングをさらに下ると、Insilicopは3,339人のユーザーだけで$370万を稼いでいる。これは極めて少数のアクティブなアルゴリズムトレーダーが、自社インフラを通じて巨大なボリューム（$363億）をルーティングしていることを示す異常値だ。そのユーザー1人あたりの収益はトップ15の他のすべてのビルダーを圧倒している。

ユーザー1人あたりの収益：隠れた指標

収益の総額はあくまでも一側面に過ぎない。この機会を評価するビルダーにとって、より興味深い指標はユーザー1人あたりの収益だ。これにより、ビルダーの収益モデルがユーザー数に依存しているのか、ユーザーの取引密度に依存しているのかが明確になる。

| ビルダー | 収益 | ユーザー数 | ユーザー1人あたり収益 | ユーザー1人あたりボリューム | | --- | --- | --- | --- | --- | | Insilico | $3.7M | 3,339 | $1,113 | $10.9M | | Mass | $1.5M | 1,054 | $1,395 | $2.4M | | TreadFi | $2.2M | 4,835 | $463 | $2.3M | | PVP | $8.0M | 28,223 | $284 | $607K | | Phantom | $23.6M | 153,128 | $154 | $293K |

Insilicopはユーザー1人あたり$1,100超を稼ぎ、Phantomは$154だ。どちらも成功しているが、それぞれ根本的に異なる戦略を体現している。Phantomは配布力で勝る（すべてのSolanaウォレットユーザーをワンタップでHyperliquidのパーペチュアル取引に誘導する）。Insilicopは密度で勝る（膨大なボリュームを生み出す少数のパワートレーダーに特化してサービスを提供する）。ビルダーコードのシステムは、どちらのアプローチも等しく報いる。

ビルダーコード vs リファラルコード

Hyperliquidには2つの手数料シェアリングメカニズムが存在する。新規ビルダーが最もよく犯す間違いの一つが、この二つを混同することだ。

ビルダーコードは注文ごと、アプリ固有、かつ加算型だ。プロトコルの標準的な取引手数料に上乗せする形で手数料が発生する。ビルダーのアプリを通じて取引した場合にのみ適用され、署名済みの承認によるユーザーの明示的な同意が必要だ。

リファラルコードはユーザーごと、永続的、かつ減算型だ。プロトコルの手数料を引き下げ、その一部をリファラーに分配する。ユーザーがどのフロントエンドを使って取引しても適用され、紹介されたユーザーが累計$10億のボリュームに達した後に失効する。

同じ注文に両方が存在する場合、そのフィルに対してはビルダーコードがリファラルコードをオーバーライドする。これにより、ビルダーの収益は、自分のアプリを通じてルーティングされたトレードのリファラルコードによって希薄化されることはない。

ビルダーコードの統合：技術的な手順

始めるには、少なくとも100 USDCを保有するHyperliquidのパーペチュアルアカウントと、Hyperliquid APIを通じて注文を送信するアプリケーションが必要だ。申請フォームも審査委員会も存在しない。

ステップ1：ビルダーアドレスを登録する

ビルダーアドレスとは、手数料を受け取るウォレットのことだ。パーペチュアルアカウントの残高が少なくとも100 USDCあること、標準的なアカウントアブストラクションモードを使用していることを確認する。

ステップ2：ユーザーに手数料の承認を促す

収益を得るには、各ユーザーがApproveBuilderFeeアクションに署名する必要がある。これはユーザーのメインウォレットから行わなければならない。このアクションにより、そのユーザーに対して請求できる上限手数料が設定される。ベストプラクティスとして、UIでビルダーアドレス、上限手数料、費用の例示、手数料がプロトコル手数料に加算される旨の説明、および取り消し方法を明確に表示することが推奨される。

ステップ3：注文に手数料を付加する

送信する各注文にビルダーパラメータを追加する：

{
  "b": "0xYourBuilderAddress",
  "f": 50
}

この例では、f: 50は約定ごとに5ベーシスポイント（0.05%）を請求する。注文ごとに変更することも可能で、ボリュームの多い銘柄では競争力を保つために低く設定し、流動性が低いペアではアナリティクスやルーティングが明確な付加価値を提供する場合に高く設定するといった使い分けもできる。

ステップ4：収益を引き出す

ビルダー手数料はビルダーアドレスに蓄積され、リファラル報酬システムを通じて請求できる。すべてのビルダーコードの活動はオンチェーンに記録され、完全な透明性を確保するためにLZ4圧縮形式で毎日公開される。

ビルダーたちが実際に作っているもの

ビルダーコードのシステムは、多様なエコシステムを生み出した。PhantomやMetaMaskのようなウォレットはHyperliquidのパーペチュアル取引をネイティブ機能として統合しており、ユーザーはapp.hyperliquid.xyzにアクセスすることなく取引できる。PVPやInsilicopのようなトレーディングターミナルは、ソーシャルトレーディング、コピートレーディング、アルゴリズム実行に特化したインターフェースを構築している。Axiom（収益$240万、34,093ユーザー）やInfinex（$280万、9,283ユーザー）のようなアグリゲーターはHyperliquidの流動性を通じてクロスチェーンの取引をルーティングする。

共通しているのは、どのビルダーも収益化のためにトークンを発行していないことだ。プロダクトを構築し、ビルダーコードを付加し、初日から収益を得始めた。これは、プロトコルを立ち上げ、ガバナンストークンを発行し、そのトークンに価値が集まることを期待するというDeFiの従来のプレイブックとは対照的だ。

私たちのデータでビルダーのパフォーマンスを追う

ビルダーコードの経済学をスケールで理解するには、生のオンチェーンログだけでは不十分だ。私たちのビルダーアナリティクスエンドポイントは、Hyperliquidに登録されたすべてのビルダーの収益、ボリューム、ユーザー数、参入日を含む完全なリーダーボードを提供する。

ビルダーはこのデータを活用して、エコシステム全体に対して自分たちのパフォーマンスを比較できる。ファンドはどのフロントエンドがシェアを伸ばし、どこが失っているかを評価できる。そして生の数字は、表面的な指標では見えてこないダイナミクスを明らかにする。たとえば、Insilicopの3,339人のユーザーがMetaMaskの52,534人よりも多くのボリュームを生成していること、またBasedがPhantomとほぼ同じボリュームを3分の1のユーザー数でルーティングしていることなどだ。

私たちのコホートアナリティクスはさらに深い洞察を加える。ビルダーコードデータと16の行動コホート（アカウントサイズで8つ、累計損益で8つ）を照合することで、どのタイプのトレーダーがどのフロントエンドに集中しているかを把握できる。主にSmart Moneyコホートのユーザーを引き付けるビルダーとExit Liquidityトレーダーにサービスを提供するビルダーでは、同じボリュームであっても経済的なダイナミクスが根本的に異なる。

HyperTrackerでビルダーアナリティクスを探る

Hyperliquidエコシステム全体のビルダー収益、ボリューム、ユーザー成長を追跡できる。無料ティアあり。

ビルダーリーダーボードを見る

大局的な視点

ビルダーコードは、DeFiフロントエンドが長年抱えてきた問題を解決した。分散型プロトコルに取引をルーティングするアプリケーションは、どうやって収益を得るのかという問題だ。ビルダーコードが登場する以前、その答えは大抵「トークンを発行する」か「サブスクリプションを課金する」だった。どちらも摩擦を生む。トークンはガバナンスのオーバーヘッドと規制リスクを伴う。サブスクリプションは、プロダクトを試す前にカジュアルなユーザーをふるい落としてしまう。

Hyperliquidのアプローチはインセンティブをより直接的に整合させる。ビルダーは自分たちが生み出した価値、つまりルーティングしたトレードボリュームに比例して収益を得る。ユーザーは手数料に明示的に同意し、支払額を正確に把握し、いつでも取り消すことができる。各ビルダーが事実上の流通チャネルとなり、ネイティブフロントエンドを訪れることのなかったかもしれない新しいトレーダーをHyperliquidエコシステムに引き込むため、プロトコルにも恩恵がある。

累計ビルダー収益$9,070万と1,411人の登録ビルダーにより、このシステムはすでに意義あるスケールでそのモデルを証明した。次のフロンティアは、ビルダーコードが機能するかどうかではない。その上に何が構築されるかだ。