0xは、Solana のスワップAPIを以下で運用しています。Quicknode

Quicknode

2026年9月10日 — 読了時間5分

シェア

「お気に入り」として追加

多くのオンチェーン アプリ では、スワップルートの選択は通常、by 各スワッププロバイダーからの提示価格に基づいて決定されます。0xのルーティングエンジンは、「決済されるかどうか」、つまり取引が成立するか否か、および実際に決済される金額が約束された金額からどれだけ乖離するかを最適化します。この基準により、データへの負荷が高まります。Solana では、提示価格の妥当性は、その価格算定の基準となった口座の状態に左右されます。

2026年8月、0xはその取り組みをSolana に導入しました。 Solana 上の0x Swap APIがオープンベータ版を開始しました。これは、EVM以外のネットワークとしては初めてby に導入されたものであり、9年以上にわたるオンチェーン 取引 の実績を経て、ユーザー によるルーティング対応が整った状態で登場しました。具体的には、貸付プロトコル内のスワップに0xを採用している「Kamino」、ベータ期間中に数百万ドル規模の取引高を処理した0x独自のメタアグリゲーター「Matcha Meta」、そしてプロバイダーが決済額で競い合う仕組みを持つメタアグリゲーター「Titan」などが挙げられます。

Solana 向けのSwap APIの再構築が意味したこと

EVMチェーンでは、Swap APIは署名可能な状態のトランザクションを返します。Solana の場合、0xは異なる形式を採用しました。それは、リアルタイムのアカウント状態に基づいて価格が算出された一連の指示であり、インテグレーターがこれらを組み立ててトランザクションを作成し、送信する仕組みです。 マルチホップルートは、Solana の制限内に収まるほどコンパクトなアドレスルックアップテーブルを介してコンパイルされます。この命令セットは処理の進行に合わせてトークンアカウントを作成し、ラップ処理を必要とせずにネイティブSOLを処理します。Token-2022のルーティングは、7月のクローズドベータ版において、ステーブルコイン、トークン化された株式、およびローンチパッド トークンで導入されました。これらすべては、 Quicknodeを通じて直接提供される最新のアカウント状態に依存しています。

Solana の引用によると、そのワークロードはトランザクションの送信ではありません。0xはこれを「本質的には大規模なアカウント追跡」と説明しています。つまり、アカウント、サブスクリプション、およびプール状態を最新に保つためのダイレクトRPCフェッチです。0xのAPIは約3,000のアクティブなWebSocket接続を維持し、毎秒100件以上のアカウント更新を取り込んでいます。 フェッチパスはサブスクリプションと同等の重要性を持ち、0xはSolana において、これをSwap APIの低遅延に不可欠であると述べています。Solana のスロット時間は短縮され続けており、2026年8月には400msから350msとなり、 200msに向けて段階的に短縮される予定 。各スロットは、クォートの背後にあるプールを移動させる可能性があるため、新しいクォートが生成されるためのウィンドウは狭まり続けています。更新が遅れると、古いクォートが生成されます。サブスクリプションが切断されても、エラーは発生しませんが、同様の結果となります。

0xは、このローンチが依存していた3つの要素として、大量のアカウント更新処理下での安定性、接続が維持されるサブスクリプション、そして高いリクエスト負荷下での低遅延な応答を挙げています。 その背景には、0xが提供するすべてのサービスに課している基準、すなわち月間稼働率99.5％という目標があります。この「信頼性 」こそが、チェーンを跨ぐチーム が0xを経由する主な理由であり、この基準はプロバイダーに対しても同様に適用されています。0xによれば、これをサポートすることは「譲れない条件」であるとのことです。

Solana の起動：3つのインフラストラクチャ呼び出し

Swap APIを初の非EVMネットワークに導入するには、3つの明確な決定が必要でした。0xのSolana （equipe ）は、それぞれについて具体的に述べています。

まず検討したのは、Solana の専門業者とマルチチェーン のプロバイダーのどちらを採用するかという点でした。0xが最も重視したのは、大量のサブスクリプションおよびリクエストデータの処理能力でした。一部のプロバイダーはSolana でこれを実現できますが、0xの評価によれば、「 Solana しか対応できない」とのことで、その場合はRPCベンダースタックが複雑化するという代償を伴います。機能面では、0xはQuicknode の製品が「当社のニーズに対して十分に充実しており、高いパフォーマンスを発揮する」と判断しました。 最も困難だったテストは、多数のサブスクリプションを同時にサポートする並行処理でした。『equipe 』誌はこれを「真に困難な課題」と評し、「Quicknode がこれをクリアした」と報じています。既存のEVMパートナーシップには長年の実績とサポート があり、これにより、0xが運用するすべての製品において、単一のパートナーと単一のパッケージで済むことになり、スタック内にSolana 専用のベンダーが追加されることを回避できました。

2つ目は、どの程度の容量を確保すべきか、また何つのリージョンにまたがって確保すべきかという点でした。0xは独自の評価を行いました。初期のテストでは、Quicknode Proネットワークは、0xが測定したプロバイダーの中でp90レイテンシが最も低いものの1つでした。その後、equipe はQuicknode DedicatedClusters に移行しました。これは、2つのリージョンにまたがって容量を確保し、Proネットワークへのフォールバック機能を備えたものです。これにより、p90のレイテンシは約70%低下しました。

3つ目の選択肢は、同社の直感に反するものでした。equipe は「ビルダーファースト」を掲げるプラットフォームであり、独自のSolana ノードを運用することについても、一時的に検討されました。決定的な要因となったのは、コストと、さらに重要な点として専門知識の2つでした。 equipe によると、「 Solana には、特定の専門知識を必要とする要素が数多く存在する」とのことです。ノードの運用をQuicknode に委託したことで、0xのエンジニアたちは、0xだけが解決できる唯一の課題、すなわちSolana 向けのSwap APIの再構築に専念できるようになりました。「それ自体が決して簡単な作業ではなかった」のです。

オープンベータ開始以来

最初のシグナルは、0xのequipe による介入なしに届きました。個々のインテグレーターは、0x側で何の変更も加えることなく、1秒あたり数十件のリクエストから200 RPSへとスケールアップしました。0xは、この成長を自社のAPIのアーキテクチャと、その基盤となるRPCプロバイダーによるものと評価しています。

7月のクローズドベータ期間中、週に12～14件の異なるチーム が投稿され、これらはSolana エンドポイント。8月には、週あたり33件（2.4倍から2.8倍）に増加しました。初めてSolana への呼び出しを行うチーム は、1日1件から3件へと増加しました。 0xのゲートウェイにおけるレイテンシは安定しており、p50は約15ms、p95は約80msを維持した一方で、インテグレーターの数は2倍以上に増加しました。7月から8月にかけての同期間において、サーバーのエラー率は0.19%から0.017%へと低下し、11倍の減少となりました。503エラーはゼロになりました。

Quicknode すでにEVM側において0xのSwap APIのプロバイダーを務めていました。この提携関係により、同APIがサポートする初の非EVMネットワークも加わり、Solana の相場が算出される際の基準となるアカウントの状態も提供されることになりました。

Solana のワークロードについては、当社のequipe までお問い合わせください。