通过 Hyperliquid API 执行 TWAP 与 VWAP
-
twap vwap hyperliquid
-
hyperliquid execution api
-
twap 算法交易
-
hyperliquid 大单拆分
-
vwap 链上永续合约
locale: zh-CN
当一笔订单的规模足够大时，直接以市价单成交往往会造成显著的价格冲击（market impact）——你的买单本身就会推高价格，导致均成本大幅高于预期。专业机构为了解决这一问题，发展出了多种执行算法，其中 TWAP（时间加权平均价格）和 VWAP（成交量加权平均价格）是最经典的两种。Hyperliquid 的开放 API 让个人开发者也能在链上永续合约市场实现这两种算法。本文将逐步讲解它们的原理、实现方式，并对比各自的适用场景。对于不想写代码的普通用户，OneKey Perps 提供了便捷的链上永续合约交易入口，无需自行实现算法。
什么是 TWAP
TWAP 的核心思想是：将大单按时间均匀切分，每隔固定时间提交一小笔订单，最终成交价格近似于这段时间内的时间加权平均价。
举例：需要在 1 小时内买入价值 100 万美元的 BTC 永续合约，TWAP 可以将其拆成 60 笔，每分钟执行一笔约 1.67 万美元的订单。这样无论价格如何波动，最终均价都接近该小时的时间平均价，避免了单点大额交易带来的冲击。
TWAP 的优点是实现简单，不依赖实时成交量数据；缺点是它不区分市场活跃程度——在低流动性时段也会按时下单，可能面临较高滑点。
什么是 VWAP
VWAP 则更进一步：不仅考虑时间，还考虑市场成交量。算法会估计各时间段的历史成交量分布，在成交量大的时段安排更多执行量，在成交量小的时段减少执行量。目标是最终成交均价接近市场的成交量加权平均价。
VWAP 需要实时或历史成交量数据，实现复杂度高于 TWAP，但在流动性分布不均匀的市场中通常能获得更低的执行成本。
为什么这两种策略在链上很重要
链上永续合约市场的流动性深度和价格发现效率在不同时段差异明显。链上撮合引擎的特性也意味着大单对订单簿的冲击与中心化交易所略有不同。参考 Hyperliquid 官方文档 可以了解其订单簿深度和手续费结构，为算法参数设定提供依据。
TWAP 与 VWAP 对比
用 Hyperliquid REST API 实现 TWAP
基本思路
通过 Hyperliquid 的下单接口 循环提交子订单，每次提交后等待预设的时间间隔：
import time
import math
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 执行完成")
实际生产中需要增加：异常重试逻辑、部分成交处理、以及在行情极端波动时暂停执行的保护机制。
改进：使用限价单降低成本
将每笔子订单改为限价单（价格略优于盘口）可以降低手续费（享受 Maker 费率），但有未成交风险。可以设置超时机制：若限价单在规定时间内未成交，撤单并改为市价单强制执行：
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)
改用市价单补单
exchange.market_open(coin=coin, is_buy=is_buy, sz=get_remaining_size(oid), 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 订阅格式参见 官方文档。
参数设置建议
与其他 DEX 执行算法对比
dYdX 同样支持 REST API 下单，可以实现类似的 TWAP 逻辑
GMX 采用价格预言机机制，执行算法的设计逻辑略有不同
Hyperliquid 的订单簿模式更接近中心化交易所，TWAP/VWAP 的实现经验可以直接迁移
不想写代码？试试 OneKey Perps
并非所有用户都需要自行实现算法执行。OneKey Perps 提供了简洁直观的永续合约交易界面，结合 OneKey 硬件钱包的安全签名保障，让普通用户也能在 Hyperliquid 上安全地进行永续合约交易，无需编写任何代码。对于中等规模的交易，合理设置限价单并分批手动执行，同样可以达到降低冲击成本的效果。
常见问题
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 值得作为你的首选起点。
风险提示：算法执行策略不能保证以特定价格成交，市场波动、流动性不足或技术故障均可能导致实际成本显著偏离预期。永续合约交易存在高风险，可能导致资金全部或部分损失。本文仅供技术参考，不构成任何投资建议。请在充分了解风险后，依据自身实际情况审慎操作。
