ビルダーコードが元を取れる時と取れない時

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

Hyperliquidのビルダーコードプログラムは、ローンチ以来1,411人のビルダーに対して総額9,000万ドル以上を支払ってきた。Phantom単独で2,360万ドルを獲得している。このような数字を見ると、ユーザーベースが小さなウォレットやトレーディングアプリであっても、統合は明らかな選択肢に思えてくる。

しかしトップ5を超えて見ると、状況は変わってくる。ビルダー1人あたりの生涯収益は平均約64,000ドルだ。中央値はほぼ確実にそれより低い。少数の大規模インテグレーターが平均を大きく押し上げているからだ。ウォレットチームが統合に開発リソースを投じるべきか検討する際、本当の問いは「Phantomはいくら稼いでいるか?」ではない。「自分たちのユーザー、ボリューム、手数料許容度を考えると、私たちはいくら稼げるか?」だ。

この記事では意思決定のフレームワークを解説する。ビルダーコードの収益性を決める3つの変数、損益分岐点の計算、そして統合が有効なシナリオとそうでないシナリオを掘り下げる。

すべてを決める3つの変数

ビルダーコードの収益はシンプルな式に集約される。

月間収益 = アプリ経由の日次ボリューム × 手数料率 × 30

3つの入力値だ。それぞれが重要で、チームが想定外の形で互いに影響し合う。設定する手数料率はパワーユーザーの定着に影響し、それがボリュームに影響し、最終的に構築する価値があったかどうかを左右する。

1. ボリューム：ごまかせない変数

アプリ経由のボリュームは、インターフェース経由でトレードするユーザー数とその取引頻度に依存する。Phantomが全期間パープボリューム総額448億ドル以上を記録しているのは、153,128人のユーザーが経由してトレードし、その多くがPhantomを利便性の理由で選んだ高頻度パーペチュアルトレーダーだからだ。一方Insilico は3,339人のユーザーしかいないが、それでも363億ドルのボリュームを生み出した。そのユーザーが機関レベルのアルゴ運用者で、1アカウントあたり大量の約定を生むからだ。

教訓はこうだ。生のユーザー数は弱い予測指標だということ。重要なのはユーザー1人あたりのトレードボリュームであり、それはユーザーの属性とプロダクトが促す行動によって決まる。カジュアルなスポットスワッパーを10万人抱えるウォレットは、アクティブな先物トレーダーを2,000人抱えるターミナルより少ないパープボリュームしか生まない。

2. 手数料率：自分でコントロールできるノブ

Hyperliquidはビルダーにパープで最大10ベーシスポイント（0.10%）、スポットで100ベーシスポイント（1.00%）の手数料を設定できる。徴収した手数料の100%はビルダーが受け取る。プロトコルの手数料は別途課される。

手数料の設定にはトレードオフがある。MetaMaskは約8.9ベーシスポイントと最大値に近い設定をしている（90億ドルのボリュームに対して810万ドルの収益から算出）。この積極的な手数料が機能するのは、MetaMaskの52,534人のユーザーが主に利便性を求めているからだ。MetaMaskを離れずにパープをトレードしたいユーザーは、数ベーシスポイント余分に払っても構わない。一方Insilico は約1ベーシスポイントを設定している。そのユーザーはクオントチームであり、10bpsのサーチャージに即座に気づき、別のルートに切り替えるだろう。

リーダーボードから得られる教訓は、普遍的に正しい手数料など存在しないということだ。設定する料率はユーザーの手数料感度に依存し、それはユーザーの洗練度と利用できる代替手段に密接に連動している。

3. ユーザーエコノミクス：正気チェックとしてのユーザー1人あたり収益

ユーザー1人あたり収益は、ノイズを切り捨てる指標だ。プロダクトにおける各ユーザーの生涯価値と、異なるビルダー戦略の実際の成果を明示する。

Massはわずか1,054アカウントで1人あたり1,395ドル以上を稼ぐ。Phantomは153,128アカウントで1人あたり154ドルを稼ぐ。どちらも成功しているが、完全に異なるビジネスモデルを体現している。Massは少数のヘビートレーダーを対象とする。Phantomは多数のミドルトレーダーを対象とする。自社プロダクトがPhantomよりMassに近い形なら、ビルダーコードを収益化するために必要なユーザー数は少ないが、そのユーザーが積極的にトレードしている必要がある。

損益分岐点の計算

統合はタダではない。既にウォレットやトレーディングインターフェースを持つチームであれば、Hyperliquidのビルダーコード統合には通常数週間の開発工数がかかる。ビルダーアドレス自体はパープアカウントに100 USDCあれば足り、資本要件は無視できるほど小さい。実際のコストは開発工数と継続的なメンテナンスだ。

以下は、ボリュームと手数料の組み合わせごとの月間収益を示すシナリオマトリクスだ。

この表の読み方として、アプリが1日200万ドルのパープボリュームを5ベーシスポイントで処理する場合、月間約30,000ドルになる。同じ手数料で1日1,000万ドルなら150,000ドルに跳ね上がる。これらはビルダーコードの計算式、つまり収益が日次ボリュームに手数料率（小数表記）を乗じて30日分を掛けたものに基づく概算だ。

上記の数値は計算式のみに基づく。ボリュームの変動、ユーザーのチャーン、そして暗号資産のトレードボリュームが景気循環的で強気相場と弱気相場の間で何倍にもブレ得るという現実は考慮していない。

統合が有効なケース

リーダーボードのデータを見ると、ビルダーコードが効果を発揮する明確なシナリオがいくつか見えてくる。

既にパープをトレードするユーザーがいる

これが最も強いケースだ。ウォレットやアプリが既にHyperliquidのトレードを処理しており、そのボリュームをビルダーコードなしで処理しているなら、収益を取り逃している。Phantomの統合が機能するのは、何百万人もの人々が既にPhantomを使っていたからだ。ビルダーコード付きのパープ追加は、既存の流通アドバンテージに乗せた漸進的な開発だった。

ユーザーが手数料に鈍感

専用取引所に移動せずウォレット内蔵のスワップインターフェースでトレードするような利便性重視のユーザーは、小さな手数料を許容する傾向がある。このタイプのユーザーを引き寄せるプロダクトなら、ボリューム損失を気にせずより高い手数料（10bpsの上限に近い値）を設定できる。MetaMaskの実効レートが9bps近いのは、ユーザーが手数料最適化より利便性を優先するからこそ成立している。

1人あたりボリュームが高いニッチを対象にしている

少人数のユーザーベースでも、各ユーザーがヘビーにトレードすれば意味のある収益を生める。Insilico の3,339人のユーザーが370万ドルのビルダー収益を生んだのは、平均ユーザーが生涯で1,000万ドル以上のボリュームをトレードしたからだ。クオントチーム、ファンドマネージャー、プロのマーケットメーカー向けにツールを構築しているなら、数万人のユーザーは必要ない。積極的にトレードする数百人で足りる。

おそらく有効でないケース

リーダーボードはビルダーコードが期待を下回るパターンも示している。

ユーザーが主にスポットトレーダー

Hyperliquidのパープボリュームはスポットボリュームを大きく上回る。ビルダーコードはどちらにも機能するが、収益の計算は劇的に異なる。スポットユーザーは取引サイズが小さく、取引頻度も低い傾向がある。スポットの100bps上限に近い手数料を設定してよほど大きなスポットフローを処理しない限り、カジュアルなスポットスワッパーからの収益はほぼ取るに足らないだろう。

ユーザーが手数料に敏感で代替手段がある

他のターミナルと競合するトレーディングターミナルを構築しているなら、ユーザーは手数料を比較検討するタイプだ。競合が1bpsを設定しているのに5bpsを課すと、特にボリュームの大半を生むパワーユーザーの間で実質的な離反リスクが生じる。このシナリオでは手数料レンジの下限を強いられ、計算を成立させるには膨大なボリュームが必要になる。

Hyperliquidのユーザーをまだ持っていない

ビルダーコードは需要を生み出さない。既存の需要を収益化するものだ。ウォレットのユーザーが既にHyperliquidでトレードしていない（またはパープに関心がない）なら、ビルダーコードを統合してもその行動は変わらない。統合コストは中程度かもしれないが、インターフェース経由でユーザーをHyperliquidに誘導する明確な計画がない限り、収益予測はオーガニック採用ゼロを前提にすべきだ。

トップビルダーの手数料設定

収益上位10社を見ると、手数料戦略は2つの陣営に集約される。

| 戦略 | 手数料レンジ | ユーザータイプ | 例 | | --- | --- | --- | --- | | 高手数料・利便性優先 | 5-10 bps | リテール、ウォレットネイティブ | Phantom, MetaMask, Rabby | | 低手数料・ボリューム優先 | 1-3 bps | アルゴリズム、機関 | Insilico, Axiom, Based |

どちらが本質的に優れているわけではない。PhantomとBasedはどちも総収益上位3位に入るが、正反対の戦略でそこへ到達した。Phantomは膨大なユーザーベースに高い手数料を課した。Basedは同様に膨大なボリュームに低い手数料を課した。正しい戦略は完全にユーザーの属性と、手数料が高すぎた場合に彼らが選ぶ代替手段に依存する。

注目すべきパターンがある。ユーザー1人あたり収益上位2社（MassとInsilico）はどちらも、ヘビートレーダーの少数精鋭ユーザーベースを持つ。プロダクトがこのプロファイルを自然に引き寄せるなら、ビルダーコードを収益化するためにPhantomのような規模は必要ないかもしれない。

ビルダーコードのパフォーマンス監視

統合後は、ビルダーコードのパフォーマンスへの可視性が必要だ。重要な指標は、コード経由の日次ボリューム、実効手数料率、ユーザー1人あたり収益、そしてユーザーリテンション（同じウォレットが継続的にトレードしているか、それともボリュームが一度きりのユーザーによって生まれているか）だ。

HyperTrackerのビルダーアナリティクスAPIはこれらすべてをプログラムで追跡する。/builders/listエンドポイントは任意のビルダーコードのボリューム、収益、ユーザー数を期間別（日次、週次、月次、全期間）に返す。手動計算なしに自分のコードのパフォーマンスを監視し、エコシステム全体と比較できる。

重要指標の追跡: HyperTrackerのビルダーアナリティクスエンドポイントで任意のビルダーコードの収益、ボリューム、ユーザー数を取得できる。/builders/listをクエリして自社のパフォーマンスをエコシステム全体と比較し、底線に影響が出る前にトレンドを把握しよう。

意思決定フレームワーク

開発リソースをコミットする前に、このチェックリストを確認しよう。

1. ユーザーは既にHyperliquidでトレードしているか? イエスなら既存の行動を収益化する。ノーなら採用に賭けることになる。
2. 現実的に処理できる日次ボリュームはどれくらいか? 現在のユーザー指標を使って推計する。パープボリュームで1日100万ドル以上を見込めないなら、収益が開発コストを正当化しないかもしれない。
3. ユーザーが許容できる手数料率は? ユーザーベースの手数料感度を確認する。ウォレットユーザーは高い手数料を許容しやすい。トレーディングターミナルユーザーは離れやすい。
4. 統合コストは? 既存のHyperliquidインフラを持つチームで数週間の開発工数。ウォレット署名フロー、エージェントキー、デポジットのオーケストレーションをゼロから構築するならさらに長くなる。
5. 市場サイクルを通じてボリュームを維持できるか? 強気相場のボリュームは弱気相場の何倍にもなる。統合が下落相場を生き延びられるよう、保守的な数値でプロジェクションを組もう。

1日200万ドル以上を処理でき、ユーザーが受け入れられる手数料率を設定できるなら、統合は最初の四半期でほぼ確実に元を取る。その閾値を下回る場合、判断は難しくなりオプション価値の見積もりに依存する。ボリュームが伸びれば、ビルダーコードは既にそれを捉える準備が整っている。

ビルダーコードの収益をリアルタイムで追跡する

HyperTrackerのビルダーアナリティクスAPIで、Hyperliquid上の任意のビルダーコードのボリューム、収益、ユーザー数を監視できる。リーダーボードをクエリし、自社のパフォーマンスをベンチマークし、スプレッドシートに数字が現れる前にトレンドを把握しよう。

APIを見る

見出しを飾るビルダーコードは、大規模な流通を背景に持つものだ。Phantomは統合時に153,128人のユーザーを持っていた。MetaMaskは52,534人を連れてきた。しかし流通がすべてではない。Massは1,054人のユーザーで147万ドルを生み出し、それが正しい1,054人であることを証明した。問いは「ウォレットはビルダーコードを統合すべきか?」ではなかった。常に「あなたのウォレットには、それを機能させるユーザー、ボリューム、手数料許容度があるか?」だ。これで答えを出すための数字が揃った。