透過 Hyperliquid API 執行 TWAP 與 VWAP

2026年5月6日

TWAP VWAP Hyperliquid
Hyperliquid execution API
TWAP 算法交易
Hyperliquid 大單拆分
VWAP 鏈上永續合約

當一張訂單規模夠大，直接用市價單成交，往往會造成明顯的價格衝擊（market impact）：買單本身推高價格，令平均成交成本高過預期；賣單亦可能壓低價格。專業交易機構為了處理這個問題，發展出多種執行算法，其中 TWAP（時間加權平均價格）同 VWAP（成交量加權平均價格）是最經典的兩種。

Hyperliquid 的開放 API 令個人開發者都可以在鏈上永續合約市場實作這兩類算法。本文會逐步講解 TWAP、VWAP 的原理、基本實作方式，以及各自適合的場景。至於不想寫程式的一般用戶，OneKey Perps 提供較直接的鏈上永續合約交易入口，可以配合分批下單、限價單等方式管理執行成本，毋須自行由零開始寫算法。

甚麼是 TWAP

TWAP 的核心概念是：將大單按時間平均拆細，每隔固定時間提交一張小單，令最終成交價盡量貼近該段時間的時間加權平均價。

舉例：如果你需要在 1 小時內買入價值 100 萬美元的 BTC 永續合約，TWAP 可以將訂單拆成 60 張，每分鐘執行約 1.67 萬美元。無論期間價格如何波動，最終平均價都會較接近該小時的時間平均價，避免一次過落大單造成過大衝擊。

TWAP 的好處是實作簡單，不太依賴即時成交量數據；缺點是它不會分辨市場是否活躍——即使在流動性較低的時段，仍然會按時間下單，可能面對較高滑點。

甚麼是 VWAP

VWAP 更進一步：除了時間，亦會考慮市場成交量。算法會估計不同時段的歷史成交量分布，在成交量較大的時段安排更多執行量，在成交量較細的時段減少執行量。目標是令最終成交均價貼近市場的成交量加權平均價。

VWAP 需要即時或歷史成交量數據，實作複雜度比 TWAP 高。不過，在流動性分布不平均的市場入面，VWAP 通常更有機會降低執行成本。

為何這兩種策略在鏈上特別重要

鏈上永續合約市場在不同時段的流動性深度、價格發現效率都可能有明顯差異。鏈上撮合引擎的特性，亦令大單對訂單簿的影響同中心化交易所有少少不同。設定算法參數前，應參考 Hyperliquid 官方文檔，了解其訂單簿深度、費率結構、下單限制同 API 行為。

對於使用槓桿的加密貨幣永續合約交易者而言，執行價格偏離預期不單止影響入場成本，亦可能影響保證金水平、強平距離同整體風險。因此，大單拆分同執行控制並非只適合機構，用戶在中等規模交易時同樣值得留意。

TWAP 與 VWAP 對比

項目	TWAP	VWAP
核心依據	時間	成交量與時間
實作難度	較低	較高
數據需求	基本行情與下單 API	即時／歷史成交量數據
適合場景	交易節奏穩定、想簡單拆單	市場成交量有明顯規律
主要風險	低流動性時段仍會下單	參數估計錯誤會影響效果

簡單講，TWAP 更適合先由基本版本開始；VWAP 則適合已有數據紀錄、能夠分析成交量分布的開發者。

用 Hyperliquid REST API 實作 TWAP

基本思路

透過 Hyperliquid 的下單接口循環提交子訂單，每次提交後等待預設時間間隔：

import time


def execute_twap(exchange, info, coin, total_size, is_buy, duration_seconds, num_slices):
    """
    在 duration_seconds 秒內，將 total_size 拆成 num_slices 張等量訂單執行。
    """
    slice_size = total_size / num_slices
    interval = duration_seconds / num_slices

    for i in range(num_slices):
        # 取得當前標記價格，可用於風控或記錄
        ctx = info.meta_and_asset_ctxs()
        mark_px = get_mark_price(ctx, coin)

        # 使用容許一定滑點的市價單；亦可改為貼近盤口的限價單
        result = exchange.market_open(
            coin=coin,
            is_buy=is_buy,
            sz=round(slice_size, 4),
            slippage=0.005  # 0.5% 容忍滑點
        )

        print(f"[{i + 1}/{num_slices}] 成交: {result}")

        if i < num_slices - 1:
            time.sleep(interval)

    print("TWAP 執行完成")

實際生產環境需要加入更多保護，例如：

API 錯誤重試與限速處理
部分成交後的剩餘數量管理
訂單狀態查詢與記錄
價格急劇波動時自動暫停或終止
最大滑點、最大倉位、最大虧損等風控條件

改良：用限價單降低成本

將每張子訂單改為限價單，並將價格放在略優於盤口的位置，有機會降低手續費或改善成交價。不過，限價單有未成交風險。常見做法是設定超時機制：如果限價單在指定時間內未成交，就撤單並改用市價單或重新掛單。

def place_with_timeout(exchange, coin, is_buy, sz, limit_px, timeout_seconds=30):
    result = exchange.order(
        coin=coin,
        is_buy=is_buy,
        sz=sz,
        limit_px=limit_px,
        order_type={"limit": {"tif": "Gtc"}}
    )

    oid = result["response"]["data"]["statuses"][0]["resting"]["oid"]

    time.sleep(timeout_seconds)

    # 檢查訂單是否仍然掛在訂單簿
    open_orders = get_open_orders(coin)

    if any(o["oid"] == oid for o in open_orders):
        exchange.cancel(coin=coin, oid=oid)

        # 改用市價單補回剩餘數量
        remaining_size = get_remaining_size(oid)
        exchange.market_open(
            coin=coin,
            is_buy=is_buy,
            sz=remaining_size,
            slippage=0.01
        )

這類方法可以在成本同成交確定性之間取得平衡，但不應假設限價單一定較好。當市場快速移動，等待成交本身亦可能令你錯過原定執行價格。

用 WebSocket 成交數據計算即時 VWAP

VWAP 需要持續累積成交量與成交量加權價格：

class VWAPTracker:
    def __init__(self):
        self.cumulative_pv = 0.0  # price * volume 累計
        self.cumulative_v = 0.0   # volume 累計

    def on_trade(self, price, size):
        self.cumulative_pv += price * size
        self.cumulative_v += size

    @property
    def vwap(self):
        if self.cumulative_v == 0:
            return None
        return self.cumulative_pv / self.cumulative_v

透過 WebSocket 訂閱 Hyperliquid 的成交流，每筆成交都可以觸發 on_trade 回調，即時更新 VWAP。VWAP 執行算法可以再將此數值與當前市場價、盤口深度、目標剩餘執行量比較，決定下一張子訂單應否提交、提交多少、用市價單還是限價單。

完整 WebSocket 訂閱格式應以 Hyperliquid 官方文檔為準。

參數設定建議

實作 TWAP 或 VWAP 時，以下參數會直接影響結果：

總執行時間：時間太短會增加價格衝擊；時間太長會增加市場方向性風險。
切片數量：切得越細，單次衝擊越低，但 API 請求、手續費與監控成本會增加。
滑點容忍度：過低可能導致無法成交；過高可能令成本失控。
限價單超時時間：太短可能頻繁撤單；太長可能錯失行情。
價格保護閾值：例如市價偏離開始價格超過某個比例時，自動暫停。
最大倉位與槓桿限制：永續合約有強平風險，執行算法必須配合倉位風控。

一個實用做法是先用小額資金或測試環境紀錄成交結果，再逐步調整參數，而不是一開始就用大額訂單上線。

與其他 DEX 執行算法對比

dYdX 同樣支援 REST API 下單，可以實作類似 TWAP 的拆單邏輯。
GMX 採用價格預言機機制，執行算法的設計思路同訂單簿模式不同。
Hyperliquid 採用較接近中心化交易所的訂單簿模式，TWAP／VWAP 的實作經驗更容易由傳統交易系統遷移過來。

不同平台的撮合、費率、流動性來源與風控機制都有差異，不能單純將同一組參數照搬到所有市場。

不想寫程式？可以試用 OneKey Perps

並非所有用戶都需要自行實作算法。OneKey Perps 提供簡潔的永續合約交易介面，並配合 OneKey 硬件錢包作安全簽名，令一般用戶都可以在 Hyperliquid 上進行鏈上永續合約交易，而毋須自己寫 API 腳本。

對於中等規模交易，用戶可以在 OneKey Perps 內合理使用限價單、分批入場或分批減倉，手動達到類似降低衝擊成本的效果。這不是保證更好價格的方法，但有助你避免一次過用市價單打穿訂單簿。

如果你想用較安全、較直觀的方式接觸鏈上永續合約，可以下載／打開 OneKey，連接錢包後試用 OneKey Perps；開始前請先了解槓桿、保證金與強平風險，並以自己能承受的規模操作。

常見問題

Q1：TWAP 同 VWAP，哪一個較適合在 Hyperliquid 使用？

對大部分個人開發者而言，TWAP 較易上手，可靠性亦較高。VWAP 在鏈上市場成交量分布較有規律時可能更有效，但需要歷史數據分析與更複雜的參數設定。建議先掌握 TWAP，累積數據後再嘗試 VWAP。

Q2：執行算法可以完全消除市場衝擊嗎？

不可以。算法可以降低市場衝擊，但不能完全消除。衝擊成本的下限取決於訂單規模與市場流動性的比例。算法的作用是將衝擊分散到時間與流動性較佳的時段，而不是令大單變成零成本執行。

Q3：如何評估算法執行效果？

常見做法是比較實際平均成交價與執行期間的 TWAP 或 VWAP 基準價，計算偏差或 Implementation Shortfall。建議記錄每張子訂單的時間、數量、成交價、手續費與滑點，完成後再統計分析。

Q4：OneKey 硬件錢包可以同算法執行腳本整合嗎？

可以。OneKey 支援標準以太坊簽名接口，算法腳本可以透過本地簽名服務將待簽名訊息發送到硬件錢包，完成簽名後再提交到 Hyperliquid。對於 TWAP 這類較低頻的執行場景，簽名延遲通常不是主要問題。不過，實作時仍要處理簽名失敗、用戶拒絕、設備斷線等情況。

Q5：執行期間行情大幅波動應該點做？

建議預先設定價格保護。例如當市價與開始執行時的價格偏離超過預設閾值（如 2%），就自動暫停執行，等待市場穩定，或直接終止今次任務。這可以避免在行情急劇不利時繼續累積風險倉位。

結語

TWAP 與 VWAP 是降低大單執行成本的常見工具。Hyperliquid 開放 API，令這些方法可以應用到鏈上永續合約市場。無論是用程式自動執行，還是透過 OneKey Perps 手動分批操作，核心邏輯都一樣：分散時間、減少衝擊、控制平均成本與風險。

如果你正在尋找一個較安全、易用的鏈上永續合約交易流程，可以考慮下載／使用 OneKey，並透過 OneKey Perps 進行交易管理。使用前請先熟悉產品介面、合約規則與槓桿風險。

風險提示： 算法執行策略不能保證以特定價格成交。市場波動、流動性不足、網絡延遲、API 錯誤或技術故障，都可能令實際成本明顯偏離預期。永續合約及槓桿交易屬高風險活動，可能導致資金全部或部分損失。本文只作技術參考，不構成法律、稅務或投資建議。請在充分了解風險後，按自身情況審慎操作。