Hyperliquid Builder Codesが$9,000万を分配。あなたが収益を得る方法。

最初のトレーディングボットを書いてから、実際のユーザー向けにデプロイするまでの間に、すべてのHyperliquidビルダーが直面するある問いに答える必要があります。それは「実際にどうやって収益を得るか」です。答えはbuilder codes、つまりオンチェーンの手数料帰属システムです。このシステムはHyperliquidのローンチ以来、開発者に対して静かに$9,000万以上の収益を分配してきました。この数字は、ウォレット、アグリゲーター、コピートレードプラットフォーム、AIエージェントを通じてトレードをルーティングしている1,411人の登録済みビルダーを対象としています。数字は2026年7月時点のもので、HyperTrackerのbuilderリーダーボードより。

最大の収益者であるPhantomは$2,360万を獲得。2位のBasedは$1,520万を得ています。どちらもトークンをローンチしていません。サブスクリプションも課金していません。builder codeを付けて注文をルーティングし、すべてのフィルから一定の割合を受け取るだけです。

このガイドでは、このシステムがどのように機能するかを正確に説明します。開始に必要な100 USDCの最低額から、EIP-712の承認フロー、手数料を付与するAPIパラメーター、そして高収益ビルダーとそれ以外を分けるビルダー収益のパターンまで。Hyperliquidで何かを構築するなら、これが収益化の方法です。

Builder Codesとは何か（そして何を置き換えるか）

Builder codesはHyperliquidのオンチェーン収益帰属システムです。ユーザーがあなたのアプリケーション（Reactフロントエンド、Telegramボット、Pythonトレーディングスクリプトのいずれであっても）を通じてトレードする際、すべての注文にbuilderパラメーターを付与します。このパラメーターにはあなたのアドレスと手数料額が含まれます。Hyperliquidは各フィルから手数料を差し引き、あなたのアカウントに直接入金します。

この仕組みは、他のエコシステムがパートナーシップ契約、収益分配契約、またはトークンローンチで行っていることを置き換えます。Hyperliquidでは、収益化はパーミッションレスです。申請も、交渉も、許可を求める必要もありません。100 USDCを入金し、手数料率を設定して、アプリがルーティングするすべての注文から収益を得始めるだけです。

手数料体系はシンプルです。

• 無期限先物: 注文ごとに最大10ベーシスポイント（0.10%）
• スポット: 注文ごとに最大100ベーシスポイント（1.00%）
• 収益の分配: builderの手数料の100%がビルダーに支払われます。Hyperliquidはあなたの取り分から何も取りません。

手数料はHyperliquidの標準的なトレード手数料に上乗せされるため、ユーザーはあなたのインターフェースを通じてトレードする際に若干のプレミアムを支払います。その代わりに、あなたのインターフェースはユーザーが価値を感じるもの（優れたUI、自動化された戦略、コピートレード、ポートフォリオ分析、AIを活用したトレード実行など）を提供することが前提です。

4つのステップでセットアップ

すでにHyperliquidのウォレットをお持ちであれば、builder codeを稼働させるまで1時間もかかりません。正確な手順を説明します。

ステップ1: アカウントに入金する

Hyperliquidの無期限先物アカウントに最低100 USDCを入金します。これが唯一の必須要件です。申請フォームも、承認委員会も、パートナーシップ交渉も不要です。100 USDCの最低額はシビル耐性のための措置であり、あなたのアカウントに残ります（Hyperliquidに支払う手数料ではありません）。

ステップ2: ユーザーの承認を得る

あなたのアプリケーションが手数料を請求する前に、各ユーザーがあなたのbuilderアドレスと最大手数料率を明示的に承認する必要があります。ユーザーはEIP-712の型付きデータメッセージに署名し、あなたのアプリはそれをApproveBuilderFeeアクションとしてHyperliquidに送信します。この署名はユーザーのメインウォレットから行う必要があり、エージェントやAPIキーは使用できません。

承認は持続的です。ユーザーが一度あなたのbuilderを承認すれば、失効しない限り再訪時に再承認する必要はありません。アプリはロード時に承認ステータスを確認し、リターンユーザーに対してはこのステップをスキップすべきです。各ユーザーは最大10個のbuilder codeの承認を同時に持つことができます。

ステップ3: 注文に手数料を付与する

承認が完了したら、アプリが送信するすべての注文にオプションのbuilderパラメーターを含めることができます。

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

bフィールドはあなたのbuilderアドレスです。fフィールドはベーシスポイントの10分の1単位の手数料です。つまりf: 10は1ベーシスポイント（0.01%）に相当し、f: 100は10ベーシスポイント（0.10%）で無期限先物の最大値です。手数料は注文ごとに設定できるため、資産、戦略、またはユーザーのティアごとに異なる料率を設定することが可能です。

ステップ4: 収益を請求する

手数料はオンチェーンのbuilderアカウントに蓄積されます。Hyperliquidの標準的なリファラルリワードのプロセスを通じて請求します。最低請求金額はありません。日次のフィルデータはLZ4圧縮CSV形式で公開されており、stats-data.hyperliquid.xyz/Mainnet/builder_fills/{your_address}/{YYYYMMDD}.csv.lz4で独自の分析と照合に利用できます。

オープンソースの参考実装: DwellirはMITライセンスのNext.jsデモアプリを公開しており、builder codeのライフサイクル全体（承認、入金、エージェントのアクティベーション、手数料付きの注文発注、失効）を実装しています。テストネットとメインネットの両方で動作します。クローンして、あなたのbuilderアドレスに差し替えれば、数分で動作する実装が完成します。

誰がいくら稼いでいるか: Builderリーダーボード

builderエコシステムの収益は急峻なべき乗則に従います。上位2つのコード（PhantomとBased）はそれぞれ$1,500万以上を生み出しており、登録済みの1,411ビルダーのほとんどは控えめな金額を稼いでいます。累計収益ベースのトップ10を以下に示します。

| 順位 | Builder | 収益 | ユーザー数 | ルーティング取引量 | | --- | --- | --- | --- | --- | | 1 | Phantom | $23.6M | 153,128 | $44.8B | | 2 | Based | $15.2M | 42,967 | $44.9B | | 3 | MetaMask | $8.1M | 52,534 | $9.0B | | 4 | PVP | $8.0M | 28,223 | $17.1B | | 5 | Insilico | $3.7M | 3,339 | $36.3B | | 6 | Infinex | $2.8M | 9,283 | $5.2B | | 7 | Axiom | $2.4M | 34,093 | $23.0B | | 8 | TreadFi | $2.2M | 4,835 | $11.1B | | 9 | Dreamcash | $1.8M | 11,215 | $7.6B | | 10 | Liquid | $1.5M | 9,499 | $3.2B |

理解すべき収益パターン

リーダーボードのデータから、Hyperliquidでビルドしている人にとって重要な3つのパターンが浮かび上がります。

ユーザー数よりも取引量の密度が重要

Insilocoは収益ランキングで5位（$370万）ですが、ユーザー数はわずか3,339人で、トップ10の中で最小のユーザーベースです。しかし合計取引量は$363億で、全体で3番目に高い数字です。これはユーザー1人あたり約$1,090万の取引量に相当します。Axiomと比較してみましょう。Axiomは34,093人のユーザーを抱えますが、ユーザーベースにカジュアルなトレーダーが多いため、ユーザーあたりの収益は大幅に低くなります。高取引量のユーザーを惹きつけるもの（クォント戦略、アルゴリズム実行、コピートレード）を構築しているなら、ユーザーベースが小さくても意味のある収益を生み出せます。

ウォレットは配布面での優位性

PhantomとMetaMaskが収益の1位と3位を占めているのは理にかなっています。ウォレットはユーザーがすべてのトレードセッションを開始する場所だからです。すでにエントリーポイントを押さえているなら、注文フローにbuilder codeを追加するのは自然な拡張です。Phantomの153,128人のユーザーは、エコシステムで最大のユーザーベースを3倍以上の差で上回っており、その配布面での優位性が直接収益に結びついています。ウォレットやトレード機能を持つブラウザ拡張機能を構築しているなら、builder codesは既存のユーザーベースを収益源に変えます。

収益は集中しているが、テールは長い

上位10のビルダーが$9,070万の合計のうち約$6,900万を占めており、残りの1,400以上のビルダーが約$2,100万を分け合っています。これはべき乗則の分布で、ほとんどのマーケットプレイス経済学と一致します。しかし、テールはそれでも無視できません。何百ものビルダーがそれぞれ5桁から6桁の収益を得ています。参入障壁は低く、実験のコストはほとんどかかりません。

Builder CodesとReferral Codes: 重要な違い

Hyperliquidにはビルダーがよく混同する2つの別個の帰属システムがあります。Builder codesとreferral codesは異なる目的を持ち、互いに独立して積み重なります。

Referral codesはユーザーレベルです。誰かがあなたのリファラルリンクを通じてHyperliquidに参加した場合、その人の取引手数料の10%を永続的に（累計取引量が$10億に達するまで）受け取ります。referral codeの作成には$10,000の取引量が必要です。Referral codesはユーザーに紐付けられており、ユーザーがどのインターフェースを通じてトレードしても適用されます。

Builder codesは注文レベルです。ユーザーを誰が紹介したかに関わらず、あなたのアプリケーションを通じてルーティングされた特定の注文に適用されます。他の誰かのリファラルリンクでサインアップしたユーザーでも、あなたのbuilder codeが付与されたあなたのアプリでトレードすることができます。

2つは積み重なることができます。ユーザーがAによって紹介され、builderBのインターフェースを通じてトレードした場合、そのトレードに対してAとBの両方が手数料を得ます。つまり、あなたのbuilder code収益はリファラルネットワークとは独立しており、その逆も同様です。

ステーキングリファラルプログラム: HyperliquidのステーキングリファラルシステムはHYPEをステーキングしたビルダーがユーザーのトレード手数料をより高い割合（最高ステーキングティアで最大40%）で得られるようにする提案です。ビルダーはそのステーキングリファラル収益の最大50%をユーザーへの手数料割引として還元することもできます。このプログラムが実装されれば、大量のHYPEをステーキングするビルダーにとってbuilder codesはさらに収益性が高くなります。

よくあるセットアップの間違い（と回避方法）

Builder codeシステムはコンセプトはシンプルですが、新しいビルダーがつまずくいくつかの落とし穴があります。

間違ったキーで署名する

ApproveBuilderFeeアクションはユーザーのメインウォレットで署名する必要があります。エージェントキーとAPIキーは承認を署名できません。アプリがエージェントベースのシステムを通じてウォレット接続を処理している場合、後続の注文署名をエージェントに委任する前に、ユーザーにメインウォレットで承認に署名するよう促す必要があります。

最大手数料の上限を忘れる

ユーザーはあなたのbuilderアドレスに対して最大手数料率を承認します。ユーザーが承認した手数料より高い手数料を付与しようとすると、注文は失敗します。柔軟性を確保するために最大レートをリクエストするよう承認フローを設計し（多くのビルダーは無期限先物の上限10bpsをリクエストしています）、その上限以下で注文ごとに実際の手数料を設定します。

ロード時に承認ステータスを確認しない

承認は持続的なので、リターンユーザーには承認プロンプトを再表示すべきではありません。アプリのロード時に{"type": "maxBuilderFee", "user": "0x...", "builder": "0x..."}を使って承認ステータスをクエリし、レスポンスにアクティブな承認が示されている場合は承認ステップをスキップします。

手数料を高く設定しすぎる

無期限先物の最大値は10bpsですが、最大値を請求すべきとは限りません。ユーザーは承認前に手数料率を確認でき、いつでも失効させることができます。高収益のビルダーのほとんどは上限よりかなり低い手数料を設定しています。なぜなら、高取引量に対する低手数料は、競合他社にユーザーを奪われる高手数料より多くの収益をもたらすからです。同様のアプリケーションが請求している額を確認し、競争力のある価格を設定しましょう。

当社APIでBuilderのパフォーマンスを追跡する

builder codeが稼働したら、そのパフォーマンスを把握したいはずです。自分のコードだけでなく、エコシステム全体の動向も含めて。当社のbuilder分析エンドポイントを使えば、上記のリーダーボードテーブルの背後にあるデータにプログラムでアクセスできます。

/builders/listエンドポイントは、任意の期間（全期間、月次、週次、日次）の収益、ユーザー数、取引量を含む登録済みのすべてのビルダーを返します。自分のbuilder codeの成長を時系列で追跡し、競合他社と比較し、エコシステムのトレンドを特定できます。/builders/usersエンドポイントは特定のbuilder codeの個別ユーザーのアクティビティを分析するため、どのユーザーが収益を牽引しているか、時間の経過とともにその行動がどう変化するかを確認できます。

この種の可視性が重要なのは、builder codeの収益が静的ではないからです。ユーザーの行動は市場状況によって変化し、新たな競合が参入し、エコシステム全体の手数料率が変化します。当社のデータによると、トップビルダーはこれらの指標を毎日監視しています。あなたもそうすべきです。

Builder Code収益を追跡する

当社のbuilder分析APIは、Hyperliquidのbuilderエコシステム全体にわたる収益、ユーザーアクティビティ、取引量へのリアルタイムの可視性を提供します。リーダーボードをクエリし、パフォーマンスをベンチマークし、競合他社より先にトレンドを把握しましょう。

APIを試す

次に構築すべきもの

builder codeのデータはHyperliquidで価値がどこに流れているかを示しており、次の機会がどこにあるかを示唆しています。ウォレットはユーザーの出発点を押さえているため、リーダーボードを支配しています。しかし最も成長が速いセグメントは特化型ツールです。コピートレードプラットフォーム、AIトレーディングエージェント、ポートフォリオ管理ダッシュボード、分析インターフェース。これらのプロダクトは、より頻繁により大きなサイズでトレードするユーザーを惹きつけ、それがユーザーあたりのより高い収益に直結します。

出発点を探しているなら、エコシステムで今欠けているものを考えてみてください。特定のコホートがポジションを変えたときにユーザーに通知するアラートシステム。清算クラスターデータに基づいてレバレッジを制限するリスク管理オーバーレイ。複数のアルゴリズムに注文を分散するマルチ戦略実行エンジン。これらはいずれもbuilder feeを正当化するだけの価値を提供し、それぞれの実行があなたのコードを通じて取引量をルーティングします。

結論はシンプルです。このシステムを通じてビルダーにすでに$9,000万以上が支払われています。セットアップには1時間もかかりません。最低投資額は100 USDCです。そして、あなたのアプリがルーティングするすべての注文は、あなたが回収するか、あるいは機会損失として残すかのどちらかです。