オペレーターが覆せないルール

キャンセル優先の注文処理は、数十年にわたってあらゆる主要取引所が採用してきたポリシーだ。Hyperliquidでは、それは別の何かになっている——バリデータセットによってコンセンサスルールとして強制されるものであり、オペレーターが通知なく変更できる設定トグルではない。この違いは形式的なものではない。

ポリシーとプロトコル

キャンセル注文とアグレッシブ注文がマッチングエンジンに同時に届いた場合、ほとんどの取引所はキャンセルを優先する。考えを変えたトレーダーを守るためだ。約定前にクォートを引き上げたいマーケットメーカーを守るためでもある。電子取引における根本的な公正慣行のひとつであり、現在稼働するあらゆる中央集権型取引所において、これは内部ポリシーに過ぎない。

ポリシーは変わる。オペレーターは、通常は公開開示なく、外部承認なしに、ソフトウェアアップデートでマッチングエンジンの動作を変更できる。ルールは何年も続くかもしれない。あるいは競争圧力のもとで、手数料収益の考慮のもとで、異なる順序から利益を得る参加者の影響のもとで変化するかもしれない。その変化は、組織外の誰も観察できる前に起きる。

これは仮定の懸念ではない。ペイメント・フォー・オーダーフロー——リテール注文を対価と引き換えに特定のマーケットメーカーへ誘導する慣行——は、マッチングエンジンへのアクセスに経済的価値があるから存在する。対価を払う企業は、部分的には、キャンセル優先ルールを設定する同じオペレーター制御から派生する優先関係に対価を払っている。ルールは安定しているかもしれない。構造的に安定であることは保証されていない。

コンセンサスによる拘束

Hyperliquidは2026年5月、レイテンシとトランザクション順序付けアーキテクチャの分析を公開した。その文書は、バリデータセットがトランザクションをマッチングエンジンに渡す前にどう並べ替えるかを説明している——キャンセル注文とポストオンリー注文は、アグレッシブ注文より先に処理される。この並べ替えはコンセンサス層で行われ、アプリケーションレベルの設定ファイルではない。

メカニズムは明確だ。バリデータはこの順序付けルールをブロック生成の一部として実装する。ルールを適用しないバリデータは無効なブロックを生成する。ルールは設定ではない——コードから読み取れる、ネットワーク上のすべてのバリデータによって強制される、コンセンサスソフトウェアの性質だ。

この動作を変えるには、コンセンサスルールを変更し、ネットワークアップグレードを調整する必要がある。そのプロセスは公開され、監査可能で、発効前にすべての参加者が確認できる。優先スタックを書き換える内部メモは存在しない。緊急設定ロールバックもない。ルールが変わるなら、その変更は事前に観察可能だ。それがプロトコルの性質とポリシーの違いだ。

MEVの教訓

Ethereumのメモリプールは、トランザクション順序付けがパブリックチェーン上で構造化されないまま放置された場合に何が起きるかについて、具体的な教訓を残した。サーチャーは保留中のトランザクションを観察し、自分のトランザクションを先に挿入できた——大規模にユーザーをフロントランニングする。プロトコルは透明だったが、抽出は組織的だった。教訓は、パブリックチェーンが本質的に不公正だということではなかった。透明性だけで順序付け構造がなければ、エンドユーザーから流れ去る抽出可能な価値が生まれるということだった。

Hyperliquidのアーキテクチャは、その教訓をデリバティブ市場に直接適用している。キャンセル優先とポストオンリー優先をコンセンサスでエンコードすることで、プロトコルは特定の抽出ベクター——同じユーザーからのキャンセルに先んじてアグレッシブな約定が入り込む状況——を排除する。いかなるアプリケーション層も順序付けに触れる前にルールが強制される。より速い接続を持つ参加者も、設定オーバーライドを持つオペレーターも、コロケーション優位を持つHFT企業も、それを回避できない。

これは、プロトコルがすべての抽出可能な価値を排除するという主張ではない。どの注文タイプが保証された優先権を得るかについての具体的な構造的選択であり、その根拠はプロトコルに埋め込まれていて、その日マッチングエンジンを動かす者の善意に依存しない。

リテール保護に必要なもの

金融市場におけるリテール保護は規制上の概念だ。ほとんどの主要法域では、取引所にベストエグゼキューション、公平なアクセス、注文タイプの無差別な扱いを実証することを要求している。取引所はポリシーを維持することで準拠する。規制当局はそのポリシーを監査する。フレームワークは概ね機能する。

しかしこのフレームワークは、取引所が安定したインセンティブを持つ誠実な仲介者であるという前提の上に成り立っている。インセンティブが変化したとき——アグレッシブな参加者からの手数料収益が優先ルールの変更を促す圧力を生んだとき、あるいは市場構造の変化が既存のルールを不都合にしたとき——規制準拠は遅行指標になる。変化は監査が捕捉する前に起きる。

コンセンサスルールはこのダイナミクスを逆転させる。ルール自体が強制メカニズムだ。誠実な仲介者は不要だ。なぜなら、いかなる仲介者も関連する変数を制御しないからだ。キャンセル優先の順序付けが有効かどうか知りたい参加者は、コンセンサスコードを読めばいい。証拠はポリシー文書にあるのではなく、ネットワークを動かすソフトウェアにある。

これは具体的な構造的差異だ。分散化についての哲学的主張ではない——保護がどう実装されているか、そしてそれを実際に取り除くには何が必要かの説明だ。

積み重なる設計としてのマイクロストラクチャー

市場マイクロストラクチャーの設計は複利で積み重なる。現在の主要取引所における注文優先度を管理するルールは、数十年の訴訟、規制監視、競争圧力によって形成されてきた。ルールは概ね合理的だ。観察された条件下で規制当局と参加者が公正と判断してきたものを反映している。条件が進化するにつれてそのままであり続けることは保証されていない。

オンチェーンのマイクロストラクチャーは、これらの選択を、一方的な変更が構造的に難しく、独立した検証が容易なレベルでエンコードする。プロトコルのマッチング動作は、ソフトウェアの監査可能な性質だ——コンプライアンス申請における主張でも、ホワイトペーパーにおける表明でもない。より多くの出来高がオンチェーン実行に移行するにつれて、マイクロストラクチャーのルールがどこに存在するかが、参加者がそれを有意義な意味で信頼できるかどうかを決定する——あるいはこれまで良く振る舞ってきたという意味でのみ信頼できるかどうかを。

BlackboardはHyperliquidの実行層上で動く。ここで説明したマッチングルールは、われわれが付加する機能ではない——すべての参加者が独立して検証できる、基礎プロトコルの性質だ。オンチェーンの市場構造が成熟し続けるにつれて、コンセンサス層の監査可能な性質が真の仕様となる。密かに変更できるルールと、公開ネットワークアップグレードを必要とするルールの差異は、まさに時間とともに複利で積み重なる種類の差異だ。