HIP-4とは?Hyperliquid 成果連動型契約の解説
HIP-4や成果連動型契約の仕組みについて学び、Hyperliquid スタックの他の要素との組み合わせ可能性を探り、開発者 がこれをどのように活用できるかを確認しましょう。

2026年3月13日 — 読了時間11分

Hyperliquid 2年間をかけて、ある一つの論旨を導き出すために取り組んできた:
仮想通貨、株式、商品、イベントなど、あらゆる金融市場は、共通の流動性と組み合わせ可能な証拠金制度を備えた、同一の執行エンジン上で稼働すべきです。
HIP(Hyperliquid Improvement Proposals:ハイパーコア改善提案)に基づく各提案や取り組みにより、HyperCore上で取引可能な対象の範囲は絶えず拡大しています。
まず、HIP-1により、チェーンにネイティブトークンが導入されました。
その後、HIP-2は流動性を自力で確保した。
昨年(2025年)、HIP-3により、パーペチュアル先物のパーミッションレスな展開が可能になりました。
ほんの数日前、HIP-4がHyperliquid テストネットで稼働を開始し、Hyperliquid を新たな設計空間へと拡張するとともに、成果連動型契約による市場メカニズムを導入しています。
それは一体何ですか?単に「Hyperliquid上の予測市場」ということでしょうか?どのように機能するのですか?
HIP-4が導入するプリミティブの詳細と、それらがHyperliquid インフラストラクチャ全体の中でどのように位置づけられるかを解説しながら、各質問に答えていきましょう。
成果連動型契約 は、特定の事象の発生の有無に連動する Hyperliquid 特定の事象が発生するかどうかに連動する金融商品です。価格は0から1の間で取引され、その価格は市場が想定する当該事象の発生確率を表しています。
その事象が発生した場合、契約は1で決済される。
そうでない場合は、0に収束する。
決済額は固定されているため、ペイオフ構造は単純明快である。
あるトレーダーが価格P で YES 契約を購入したと仮定すると、決済時のペイオフは次のようになります:
事象が発生した場合の利益:1−P
事象が発生しなかった場合の損失:P
例:
ある契約の取引価格が0.60の場合、市場はその事象が発生する確率を60%と想定していることになります。そして、トレーダーが0.60で「YES」を購入した場合のシナリオは以下の通りです:

数学やお金、そして報酬といった要素はひとまず置いておき、結果連動型契約がどのように機能し、それによって何が可能になるのかを理解するには、もう少し深い考察が必要となります。
成果連動型契約は、 HyperCoreの内部で直接実行されます。HyperCoreは、Hyperliquid 上のスポット市場およびパーペチュアル市場を担う中核的な実行レイヤーです。つまり、これらの契約は、既存の市場が利用しているのと同じオンチェーン のオーダーブックインフラストラクチャ、マッチングエンジン、および取引 環境を使用しています。
オーダーブック:各 アウトカム市場には、それぞれ独自の中央極限定理が適用される 注文帳 (CLOB)を持ち、HyperCore上のスポット市場やパーペチュアル市場と同様に運用されます。
アカウントシステム:アウトカム 契約のポジションは、トレーダーがHyperliquid DEXで使用するのと同じHyperliquid 取引 のアカウント内に保持されます。
成果 契約 HyperCoreにネイティブに組み込まれていることは、Hyperliquid エコシステム内で革新を図ろうとするビルダーや開発者 にとっても、作業を容易にするものです。
成果型契約は、以下の点において、他のHyperCore市場と同じインフラを継承しているため:
これにより、アウトカム市場の状況、オーダーブックの深さ、決済イベントなどを照会するビルダーは、 Hyperliquid のDEXで使用するのと同じインフラストラクチャを利用できるようになります。
次のステップは、これらの市場が実際に導入された後、どのように機能するのかを理解することです。

HyperCore内にデプロイされると、アウトカム・コントラクトは「作成 > オークション > 継続的な取引 > 決済」というシンプルなライフサイクルをたどります。
このプロセスは一見すると自明のように思えますが、各ステップには、 Hyperliquid この市場での提供価値を最大限に引き出すのに役立つ、各ステップには微妙な違いがあります:
ビルダー(デプロイ担当者)は、アウトカムマーケットをデプロイするために、100万$HYPEトークンをステーキングする必要があります。
ビルダーがオラクルを操作しようとしたり、無効な状態遷移を引き起こそうとしたりした場合、そのステークはスラッシュの対象となります。部分的または完全にスラッシュされた$HYPEはすべてバーンされます。
デプロイ時に、ビルダーはイベントスキーマを定義します:
イベント名
解決までの時間
決議の出典
認定オラクル・アップデーター
オプションの追加機能:楽観的な早期解決と紛争解決のためのチャレンジウィンドウ
また、デプロイ担当者は、Hyperliquid の基本手数料に加えて、最大50%の追加手数料を設定することができます。
マーケットは、ビルダーのイベントDEX内のスロットに配置されます。
解決後は、そのスロットを新しいイベントに再利用することが可能です。つまり、1M $HYPEのコミットメント1回で、サポート のように連続する一連の市場を運営できるということです。
導入後、約15分間の単一価格清算オークションが実施され、その間、ユーザー は注文(「価格PまでのYESを買い」)を出します。
このフェーズでは、何も実行されないことを覚えておいてください。
約定終了時、エンジンは約定数量を最大化する清算価格を選定し、 すべての約定注文がその単一の価格で約定します。
未約定の注文は、元の指値価格で「取引 」に持ち越されます。

始値の算出に用いられる実際の計算式。 出典
オークション終了後、市場は連続注文板取引に移行します 取引 。
注文は価格・時間の優先順位に従います。トレーダーは、Hyperliquid の他の市場と同様に、指値注文や成行注文を出すことができます。
契約価格は、その事象が発生する市場が想定する確率を反映しており、事象が解決するまで0.001から0.999の範囲内に留まります。
イベントが解決すると、承認されたオラクルが最終的な結果を投稿します:
1 イベントが発生した場合
そうでない場合は0
取引 取引が停止され、未約定注文はキャンセルされ、すべてのポジションはUSDH建ての最終損益で自動的に決済されます。
市場では、オプションとして「異議申し立て期間」を設けることがあり、これにより、決済が確定する前にオラクルの出力結果に対して異議を申し立てることが可能となる。
さて、アウトカム市場の仕組みや計算方法、そのプロセスについては理解できました。ここでは、これが「Hyperliquid 」というエコシステム全体、およびその中のすべての参加者にとってなぜ重要なのかを理解することに焦点を当てましょう。
Hyperliquidのロードマップ は当初から一貫しています: 単一の実行エンジン内で、取引 の処理範囲を拡大すること。

その考え方は単純です。
これは、スポット、パーペチュアル、そして新たに導入されたアウトカム契約といったあらゆる市場タイプが、同じインフラ上で稼働し、同じエンジンを通じて決済され、同じ取引 アカウント内に収まる、単一の実行レイヤーを構築するものです。さらに重要なのは、新しい市場タイプが追加されるたびに、流動性プールが細分化されるのではなく、同じ流動性プールをさらに充実させるという点です。
この最後の部分が、ここでいう「コンポーザビリティ」の本当の意味なのです。
具体的な例を考えてみましょう。あるトレーダーがETHの永久先物をロングポジションで保有しています。このトレーダーは、FRBが利下げを行えばETHが上昇すると予想していますが、利下げが行われなかった場合のリスクをヘッジしたいと考えています。
他の場所であれば、トレーダーは2つの別々のプラットフォームで、それぞれ独自の担保プールを備えた2つの別々のポジションを取らなければならないでしょう。
Hyperliquid では、犯人と結果の契約が同じアカウント内に存在します。
また、この組み合わせのしやすさは、ビルダーにとっても開発者 にとってもメリットをもたらします:
スポット市場で活動しているマーケットメーカーは、新たなシステム連携を行うことなく、アウトカム市場へとインフラを拡張することができます。
Hyperliquid を検討している開発者は、かつては複数の機関レベルのインフラと、それを機能させるための多大な調整が必要だった設計スペースを、無制限に利用できるようになります。
まあ、これはHyperliquid が行った新しい実験というわけではありません。彼らは最初から一貫して同じ目標を掲げてきたのです。

Hyperliquid 同社は、長期的なビジョンについて非常に明確に示してきた。
ブロックチェーン がすべての金融市場を網羅: 単一の ブロックチェーン により 、すべての金融市場を1つの執行レイヤー上でホストすることが可能。
さて、コンポーザビリティの有用性は、それを革新するビルダー次第です。Hyperliquid におけるビルダーとオペレーターについて、より実践的な観点から考えてみましょう。
HIP-4は、Hyperliquid のすべてのユーザーに等しく影響を与えるわけではありません。視野を広げて、主要な2~3つの役割オンチェーン に対する影響について考えてみましょう。
開発者にとって、HIP-4はイベント市場を、単体のアプリケーションではなく、展開可能なインフラへと変えます。これにより、新しいタイプの製品が登場する余地が生まれます:
市場間アービトラージボット
取引 インターフェースのイベント
階層型構造化商品
市場分析および確率データ製品
予測市場のフロントエンド
このインフラストラクチャは専用に設計され、信頼性が高いため、開発者はアウトカム契約を基盤として、幅広いインターフェースや市場探索レイヤーを構築することができます。
流動性プロバイダーやマーケットメーカーにとって、アウトカム市場が現在提供している機能は限定的です。ペイオフに上限があることは、利益の最大化を目指すあらゆるLPにとって魅力に欠ける要素となっています。
また、確率商品としてのアウトカム市場は、エクスポージャーが継続的であり、資金調達レートがポジションの決定を左右するLP向けのパーペチュアル市場に比べ、より受動的であり、これにより利益の上限が高まります。
おそらく、時間が経つにつれて、これがHyperliquid 上でまったく新しい流動性カテゴリー、すなわち「イベント確率のマーケットメイキング」につながる可能性がある。
LPやマーケットメーカーは、HIP-4から直接的なウィンウィンの関係を得ることができません。
100万の$HYPEステークが障壁となっています。現在の価格水準では、これは相当な資本投入を要しますが、スロットのリサイクルにより、ユニットエコノミクスは大きく変わります。
一連の市場を継続的に支える単一の投資は、そのコストを時間をかけて償却していく。
これにより、デプロイ担当者は、次のような定期的なイベントを中心に、ローリング・イベント・マーケットを運営できるようになります:
マクロ経済指標の発表
決算発表
選挙または統治に関する投票
主要製品の発売
つまり、マーケット作成者は、100万の$HYPEをステーキングすべきかどうかという問題よりも、スロットの活用方法やマーケット展開の順序、そしてマーケットのタイミングについてはるかに深く考えなければならない。
では、次に何が必要でしょうか? ビルダーは、アウトカム市場の新たな設計空間を真に活用するために、優れたツールとデータへのアクセスが必要です。
アウトカム市場はイベント主導型である。
単純な説明ですが、このアーキテクチャ上の違いは、スポットやパーペチュアルのような連続型市場には見られない直接的な影響をもたらします。
> 継続的な市場では、更新を見逃すと、価格がわずかに古くなってしまいます。
> アウトカム市場において、イベントが発生しなかったということは、インターフェースの不具合、ヘッジの失敗、あるいはポジションが正しく決済されなかったことを意味します。
インフラの機能不全によるコストは非対称である。
これらの市場に関わる開発者やトレーダーにとって、こうした動向は、信頼性の高いインフラの重要性を高めています。アプリケーションには、以下への一貫したアクセスが必要です:
リアルタイムのオーダーブックデータ
市場の状況およびイベントのメタデータ
口座残高およびポジションの最新情報
注文およびキャンセルに関する取引送信
アウトカム・マーケットはHyperCoreのオーダーブック上で取引されるため、こうしたやり取りは、市場データや執行インターフェースを提供するRPCエンドポイントやAPIを通じて行われます。
実際には、イベント取引 インターフェースや分析ダッシュボード、あるいは自動化戦略を開発する開発者たちは、市場に新たな情報が流入した際に発生するトラフィックの急増を確実に処理できるインフラストラクチャを必要としています。
ここで、Quicknode のようなインフラプロバイダーが役立ちます。
By Hyperliquid のマネージドRPCエンドポイント、データアクセス、および開発者向けツールを提供することで、 Quicknode これにより、チーム は製品やソリューションの構築に専念できるようになります。
Quicknode現在パブリックベータ版として提供されている「HyperCore」の統合機能は、次のようなインフラの「超能力」をもたらすと期待されています:
Streamsサポート Hypercoreデータセット向けに、Hyperliquid データのフィルタリングおよびプッシュ型配信を可能にします
gRPC API 大容量かつ低遅延のデータパイプライン向けに設計されたAPI
既存のワークフローとの互換性を確保するための、JSON-RPC および WebSocket 関連のメソッド
『Hyperliquid 』開発者のための、Quicknode に関するその他のリソース:
SDKおよびツール
Hyperliquid PythonSDK—PyPIにも掲載されています
Hyperliquid API のサンプル— Python、TypeScript、Rust、Go で「コピーして実行」できるサンプル
Hyperliquid SDK 例— 「SDK 」の高度な活用例
HyperCore CLI— ターミナルからHyperCoreデータのストリーム送信とバックフィル
hyperliquidapi.com— ゼロカストディ型Hyperliquid 、取引 API
今後も引き続き有益な情報を発信していきますので、ぜひ当ブログを購読して、ブロックチェーン インフラに関する最新情報をお見逃しなく。
HIP-4を基盤とするチーム において、インフラストラクチャ層の良し悪しが、肝心な時に機能する製品とそうでない製品との分かれ目となります。
HyperCoreの取引可能面積が拡大し、HIP-4が テストネット。アウトカム契約により、Hyperliquid は現在、イベントの価格設定を行っています。
こうした変化により、建設業者や市場関係者の設計の幅が広がります。
開発者 定期的なイベント市場を展開することができ、流動性プロバイダーは従来の市場と並行して確率型金融商品を提示でき、トレーダーは価格だけでなく結果についても見解を示すことができる。
次は、市場の展開、ツールや開発者向けリソースの成熟、そしてもちろん、Hyperliquid が絶えず追求している、同じ取引 インフラストラクチャ内で稼働できる市場の範囲を拡大する取り組みです。
必ずしもそうとは限りません。予測市場は、結果契約の一つの応用例にすぎません。
アウトカム・コントラクトは、イベントの結果に基づいて0または1で決済される、基礎となる金融プリミティブ、すなわちバイナリー商品です。予測市場は、単にこのプリミティブを用いて、将来のイベントの確率に価格を付けるものです。
Hyperliquid では、アウトカム・コントラクトを活用することで、従来の予測ユースケースにとどまらず、サポート さまざまな種類のイベントベースの市場を構築することができます。
2026年3月現在、HIP-4の成果である取引 がHyperliquid テストネットで公開されています。 メインネット ローンチは2段階のアプローチで行われます。まず厳選された標準市場が導入され、次に許可不要なビルダーの展開が行われます。具体的な メインネット 日程は未定です。
Quicknode HyperCoreおよびHyperEVMサポート 、gRPC ストリーミングを完備し、最も幅広いプロトコルに対応した、最も包括的なソリューションを提供しています。最適なプロバイダーは、最終的にはお客様の具体的なニーズ(高頻度取引取引 、コスト最適化、あるいはマルチチェーン インフラストラクチャなど)によって異なります。
はい、プロバイダーの切り替えは簡単です。ほとんどのプロバイダーが標準的なJSON-RPCおよびWebSocketインターフェースを採用しているためです。通常、必要なのは エンドポイント URLを更新するだけで済みます。
ただし、Quicknode の分析ダッシュボードやカスタムAPIなど、プロバイダー固有のツールを中心に機能を構築している場合は、それらの連携設定を調整する必要があるかもしれません。ブロックチェーン との基本的な連携機能については、プロバイダーを問わず互換性が保たれています。
2017年に設立されたQuicknode は、開発者 および企業向けに、機関投資家レベルのブロックチェーン インフラストラクチャを提供しています。99.99%の稼働率と、77以上のチェーンに対応したサポート を備え、チーム は妥協のないオンチェーン アプリケーションの構築とスケーリングを実現します。
最新のエンジニアリングに関する知見、製品の最新情報、Web3のニュースを、メールボックスに直接お届けします。
📚 新刊:『金融ソフトウェアの構築』Solanaオプションからパーペチュアルまで、10の完全なプログラムが収録された無料の書籍。
入手する