快速结论
以下情况 HyperMirror 更合适:你想要这套机制、但不想自己运营它,并且比起可定制性,你更看重持续评分与自动更换。
以下情况 开源 Hyperliquid 机器人 可能更合适:你想要掌控并修改逻辑本身、运行自己的基础设施,并宁愿投入精力也不愿支付费用。
开源机器人
Hyperliquid 的 API 开放且文档完善,因此存在一个健康的开源跟单机器人生态。如果你能读 Python、能运行一台服务器,这个周末就能搭出一个可以镜像某个钱包的东西。真正值得思考的问题不是它能不能跑起来——它当然能——而是接下来十二个月持续运行它,会让你付出什么代价。
要点速览
开源 Hyperliquid 机器人让你完全掌控逻辑、密钥和托管环境,没有产品费用,也没有供应商依赖。HyperMirror 是一种托管式的替代方案:评分打分、跨最多 10 位领先者的按评分加权分配、构成一个稳定篮子、每位领先者一个隔离子账户、自动的紧急移除与轻度问题 strike 触发的更换,以及对被镜像成交量收取 0.1% 的 builder 费用——你无需运维任何基础设施。
| 维度 | HyperMirror | 开源 Hyperliquid 机器人 |
|---|---|---|
| 主要交易场所 | 仅限 Hyperliquid | Hyperliquid(取决于你自己的配置) |
| 托管模式 | 非托管;资金始终留在你自己的 Hyperliquid 账户中 | 非托管:你持有自己的密钥,运行自己的代码 |
| 权限模式 | 仅交易权限的代理钱包授权,外加一份单独的 builder 费用授权 | 由你自己生成并管理 API 钱包或代理密钥 |
| 运营方能否提走你的资金? | 不能——提款与转账只能通过你自己的钱包完成 | 不存在运营方——但密钥一旦泄露,风险完全由你承担 |
| 你跟随的是什么 | 一个精选的、最多 10 位经评分筛选的 Hyperliquid 精英交易者篮子 | 由你的代码指定的目标,通常是单一钱包 |
| 组合构建方式 | 按评分加权分配;Starter 模式 1 位领先者,Full 模式最多 10 位 | 取决于你自己的实现;多数参考机器人只跟随一个钱包 |
| 仓位隔离 / 净额抵消 | 每位领先者拥有独立隔离的子账户;领先者之间不做净额抵消 | 只有你自己搭建子账户路由才能实现 |
| 领先者更换规则 | 组合保持稳定:紧急情况立即移除,其余情况以 3 个记录在案的轻度问题 strike 日为触发条件 | 没有固定规则集的公开文档——轮换与否取决于用户自己或提供商的自由裁量 |
| 费用模式 | 对跟单名义成交量收取 0.1% 的 builder 费用;不抽取利润分成 | 没有产品费用;你需要承担托管、监控与自己的时间成本 |
| 透明度 | 链上可验证:每一笔成交都在你自己的地址下完成 | 完全透明——你可以阅读每一行逻辑代码 |
| 运维负担 | 托管式自动跟单;无需自行运行或部署任何东西 | 很高:部署、可用性维护、重启、升级、密钥轮换 |
| 最适合谁 | 希望获得分散化 Hyperliquid 敞口、又不愿放弃资金托管权的人 | 想要完全控制权、且愿意亲自运营的工程师 |
以下情况 HyperMirror 更合适:你想要这套机制、但不想自己运营它,并且比起可定制性,你更看重持续评分与自动更换。
以下情况 开源 Hyperliquid 机器人 可能更合适:你想要掌控并修改逻辑本身、运行自己的基础设施,并宁愿投入精力也不愿支付费用。
自托管在一个意义上是最彻底的非托管方案,在另一个意义上却隐藏着风险。没有其他人能碰到你的资金,这正是它的意义所在。但代理或 API 密钥存放在一台由你自己管理的机器上,现实中最常见的失效模式往往不是恶意的服务商,而是环境变量文件里的密钥被放在一台开着端口的机器上,或者在某个深夜修 bug 时被误提交进了代码仓库。
托管式代理以不同的方式缩小了风险敞口。这份授权在协议层面就是仅交易的,因此即便运营方本身被攻破,也无法产生提款;资金始终留在你的 Hyperliquid 账户中,授权可随时从你的钱包撤销。你是在用密钥管理责任去交换对运营方的信任,这种取舍值得被明确说清楚,而不是想当然地认为哪一方天然更安全。
开源软件没有产品费用,这是一个真实的优势。但成本转移到了别处:服务器、监控、最初搭建所花的时间,以及后续因 API 变更、重连逻辑、订单处理中的边界情况,以及凌晨两点进程崩溃时仓位还挂在那儿的突发状况而反复投入的时间。
HyperMirror 通过 Hyperliquid 的 builder 费用机制收取被镜像名义成交量的 0.1%——没有订阅费,也不抽取利润分成。是否更划算完全取决于你如何看待自己的时间价值,以及你实际镜像了多少成交量。对于一个由能力过硬的工程师运营的低成交量账户来说,自托管很可能更便宜;但对其他人来说,运维方面的隐性成本会占据主导。
大多数参考机器人实现的是简单的那 80%:监视一个钱包,检测到成交,按比例下单。它们通常没有实现的,恰恰是决定结果的那部分——判断哪个钱包值得配置资金、配置多少、以及什么时候停止。这是一个数据与评分问题,而不是执行问题,也没有一个现成整洁的开源答案。
HyperMirror 的评分基于公开成交历史,涵盖已实现盈亏的稳定性、胜率、盈亏比、仓位纪律与账户存活能力,综合评分同时决定篮子成员资格和配置权重。子账户路由是内置的:每位领先者一个隔离子账户,因此 Hyperliquid 的净额机制无法把一位领先者的多头和另一位的空头相互抵消。搭建这套路由,再加上再平衡与更换逻辑,其难度远高于搭建一个基础的镜像循环。
自托管机器人现实中的风险大多是运维层面的:进程在持仓中崩溃、重连导致订单重复、API 发生变更而错误被静默吞掉、或者在行情快速变化时触发限流。每一种都是可以挺过去的,但都需要你随时待命。
托管式系统承担的是运营方风险,且被限定在仅交易权限的范围内,同时还加入了典型自建机器人所缺乏的治理机制:随衰退累计的轻度问题 strike、累计三个 strike 日后平掉该领先者子账户仓位并完成更换,以及针对严重事件的立即紧急移除——并刻意抵制过度轮换,因为单凭更高的评分永远不会强制触发换人,频繁更换领先者只会消耗换手成本,却不会带来新的信息。
选择 HyperMirror,如果:你想要评分、加权、隔离和更换机制,却不想自己搭建它们, 你不想为系统可用性负责, 并且你能接受把一个仅交易的代理作为信任边界。
选择 开源 Hyperliquid 机器人,如果:你想要掌控并修改逻辑本身, 你有任何现成产品都无法满足的特殊需求, 或者你宁愿投入工程时间,也不愿支付费用。
HyperMirror 的局限在于:逻辑不由你自己修改; 领先者由评分决定,而不是由你决定; 仅限 Hyperliquid; 而且你是在一个仅交易权限的边界内信任一个运营方。
开源 Hyperliquid 机器人 的局限在于:系统可用性、密钥安全与每一次故障都要你自己承担; 大多数参考实现只跟随一个钱包,没有评分或隔离机制; 而且维护负担永远不会结束——它只会变得熟悉。
上表中 HyperMirror 一侧的每一行都遵循同一套已公开的规则。精英篮子保持稳定:一位领先者会一直被镜像,直到某条规则将其移除,评分更高的其他钱包本身永远不会强制触发换人。紧急情况——账户价值低于约 1,000 美元,或 96 小时以上没有成交且近 7 天零交易——会立即移除该领先者。其余较轻的问题每个钱包、每个 UTC 自然日最多累计一次 strike,三个 strike 日触发更换,出现一个干净的评估日则计数器归零;该项测试所用的回撤基于按资金流调整后的权益计算,避免把入金与出金误判为交易亏损,ROI 则基于 PnL 计算。完整规则表见「运作方式」页面与系统文档。
结构只改变你承担哪些风险,并不改变你是否承担风险。本页内容不构成任何收益预测、推荐,也不是对其他提供商业绩的任何断言——做决定前,请务必查阅对方自己的文档。
带杠杆的永续合约存在重大亏损风险,包括所投入资金的全部损失。过往链上表现不构成任何预测。HyperMirror 为非托管产品,不保证收益,也不保证本金安全。
问题
评分与配置逻辑并未公开,但它执行的每一个动作都是你自己地址下的公开链上成交记录,因此即便代码不公开,其行为也可以对照链上数据进行验证。
技术上可以,但要小心:两个系统同时操作同一个账户,可能在保证金和仓位上产生冲突。隔离子账户会有所帮助,但你仍应清晰划分各自的职责范围。
持续的交易者评分及其背后的更换策略。镜像一个钱包只是一个周末项目;决定哪些钱包值得配置资金、以及何时停止配置,才是真正的难点。
如果你没有使用 HyperMirror,就不会产生 HyperMirror 的费用。但你仍然要支付 Hyperliquid 自身的交易成本,以及托管和自己的时间成本。
继续阅读