已通過 SOC 2 Type II 認證 · ISO 27001

在許多鏈上應用程式中，交易路由的選擇通常取決於其交易提供商所報的價格。0x 的路由引擎則著重於「結算結果」的優化：即交易是否能成功執行，以及實際結算金額與承諾金額之間的偏差程度。這項標準對數據提出了更高要求。在Solana 上，報價的準確性完全取決於其定價所依據的帳戶狀態。

2026 年 8 月，0x 將這項技術引入Solana 。 Solana 上的 0x Swap API 進入公開測試階段，這是首個非 EVM 網路，其設計融合了長達九年以上的鏈上交易經驗，上線之際便已吸引眾多準備進行交易路由的用戶：Kamino 透過 0x 在其借貸協議內進行交換；Matcha Meta 作為 0x 自家的元聚合器，在測試期間已完成數百萬美元的交易量；以及 Titan，這是一款讓服務提供商根據已結算金額相互競爭的元聚合器。

重建Solana 的 Swap API 代表什麼意義

在 EVM 鏈上，Swap API 會回傳一筆已準備好待簽署的交易。至於Solana ，0x 則採用了不同的架構：一系列指令，每項指令的定價皆依據即時帳戶狀態而定，由整合者將這些指令彙整成一筆交易並提交。 多跳路由是透過「位址查表」（Address Lookup Tables）編譯而成的，其體積足夠精簡，足以符合Solana 的限制。這套指令集會在執行過程中即時建立代幣帳戶，並能直接處理原生 SOL，無需經過包裝步驟。Token-2022 路由機制已於七月的封閉測試中應用於穩定幣、代幣化股票及發射台代幣。所有這些功能皆仰賴最新的帳戶狀態，該狀態是透過 Quicknode傳遞。

Solana 報價下的工作負載並非交易發送。0x 將其描述為「本質上是大規模的帳戶追蹤」：帳戶、訂閱以及直接 RPC 擷取，皆用於維持池狀態的即時更新。0x 的 API 維持著約3,000 個活躍的 WebSocket 連線，並每秒處理超過 100 次帳戶更新。 資料擷取路徑的重要性不亞於訂閱機制；0x 在Solana 中指出，這對 Swap API 的低延遲至關重要。Solana 的時槽時間正逐漸縮短，將於 2026 年 8 月從 400 毫秒縮短至 350 毫秒，並 並將分階段縮短至 200 毫秒 。每個時段都可能移動報價背後的流動性池，因此產生新報價的時窗持續縮小。更新速度過慢會產生過期的報價；訂閱中斷也會導致相同結果，且不會觸發錯誤。

0x 列出了此次上線所依賴的三項關鍵因素：在高帳戶更新吞吐量下的穩定性、能維持穩定的訂閱連線，以及在高請求負載下的低延遲回應。 這三項要件背後，是 0x 為所有發布產品所設定的標準：每月 99.5% 的正常運作時間。正是這份可靠性，讓跨鏈團隊紛紛選擇透過 0x 進行路由，而相同的標準也適用於其服務提供商。0x 表示，維持這項標準是「不可妥協的」。

建置Solana ：三項基礎架構呼叫

將 Swap API 引入其首個非 EVM 網路，意味著必須做出三項不同的決策。0x 的《Solana 》（equipe ）針對每項決策都有具體說明。

首先是該選用Solana 的專業服務商，還是多鏈服務供應商。0x 最重視的是如何處理高流量的訂閱與請求資料。部分供應商雖能在Solana 上實現此功能，但在 0x 的評估中，「他們只能做到Solana 」，這將導致其 RPC 供應商堆疊變得更加複雜。就功能而言，0x 認為Quicknode 的產品「功能完善，且在我們所需的範疇內表現出色」。 最艱鉅的考驗在於並發性，即同時支援如此大量的訂閱。equipe 稱此為「一項真正艱鉅的挑戰，而Quicknode 成功達成了這項要求。」現有的 EVM 合作關係帶來了多年的實績與技術支援，這意味著 0x 所運行的每項產品都能採用同一家合作夥伴與同一個套件，而非在技術堆疊中再增加一家僅支援Solana 的供應商。

第二個問題是應預留多少容量，以及涵蓋多少個區域。0x 進行了自身的評估。在初期測試中，Quicknode Pro 網路在 0x 測量的服務供應商中，其 p90 延遲屬於最低水準之一。隨後，equipe 轉而採用Quicknode DedicatedClusters ：在兩個區域預留容量，並以 Pro 網路作為備用方案。p90 延遲降低了約 70%。

第三個方案與該公司的直覺背道而馳。這是一家「開發者優先」的equipe ，因此曾短暫考慮過自行運作Solana 節點。最終有兩點決定了結果：成本，以及更重要的是專業知識。根據equipe 的說法，「 Solana 有許多方面需要特定的專業知識。」將節點交由Quicknode 負責後，0x 的工程師便能專注於唯一只有 0x 能解決的問題——為Solana 重建 Swap API，「這本身就絕非易事。」

自公開測試以來

第一個訊號來自 0x 的equipe ，且未經任何干預。各獨立整合者的請求量從每秒數十次擴增至 200 RPS，而 0x 方面則未作任何變更。0x 將此成長歸功於其 API 的架構，以及底層的 RPC 提供者。

7 月，在封閉測試期間，每週有 12 至 14 支不同的團隊呼叫Solana endpoint 。8 月時，每週則增至 33 支（增幅為 2.4 倍至 2.8 倍）。 首次呼叫Solana 的團隊數量，從每天一個增加到三個。儘管整合商數量增加了一倍以上，0x 閘道的延遲仍保持穩定：p50 約為 15 毫秒，p95 約為 80 毫秒。在同一段七月至八月的期間內，伺服器錯誤率從 0.19% 降至 0.017%，降幅達 11 倍。503 錯誤則降至零。

Quicknode 此前已是 0x Swap API 在 EVM 側的服務提供商。如今，這項合作關係更延伸至該 API 所支援的首個非 EVM 網路，以及其「Solana 」報價所依據的帳戶狀態。

請與我們的equipe 聯繫，討論您的Solana 工作負載。