一个所承载信息比人们想象的要少的词 “非托管”已经变成了一种信任信号,而不是一句技术性的陈述,这很可惜,因为那句技术性的陈述其实非常有用,而信任信号却并不然。按营销语言解读,它暗示的是一种笼统的安全感。而精确地解读,它只提出了一个具体主张:从未有第三方持有你的资金,因此没有任何第三方能够提走它们、冻结它们、把它们借出去,或在破产中损失它们。
这个主张是值得拥有的。它消除了整整一类失败模式——正是这类失败模式导致了那些中心化平台的倒塌,用户的余额最终被证明是别人资产负债表上的负债,而不是自己账户里的资产。但它同样被严格地限定了边界。“非托管”并没有说明一种策略是否稳健、仓位是否可能被爆仓、执行是否会与领跑者一致,或者你是否可能亏钱。在一个完全非托管的系统里,你完全可能亏掉全部余额。托管与风险是两个不同的维度,把它们混为一谈是这个领域最常见的错误。
因此,对任何跟单交易产品真正值得问的问题,不是它是否自称非托管。而是:这个系统究竟被允许对我的账户做什么,以及我如何撤回这项许可。
托管与仅限交易的权限 托管意味着别人控制着能够转移你资金的密钥。你把钱存入他们拥有的地址,你的余额变成他们账本上的一条记录,你所采取的每一个动作都是一个由他们选择是否兑现的请求。提现是他们授予的一种许可。如果他们被攻破、资不抵债,或者干脆决定暂停提现,你的救济手段是法律层面的,而不是技术层面的。
仅限交易的权限是一种不同的结构。资金留在一个由你持有所有权密钥的账户中。你委托出去的不是对资产的控制权,而是在这些资产上执行某一类特定动作的权限——在这里就是交易。被委托方可以改变你的资本所暴露的敞口。它无法改变你的资本所在的位置。
这种区别在失败情形中带来了一个具体后果。如果一个拥有仅限交易权限的系统被攻破,攻击者继承的是能够拙劣地交易你账户的能力。这是一个真实的损失来源,不应被淡化——一个拥有交易权限的恶意行为者可以开出鲁莽的仓位,并通过市场亏掉资金。但他们做不到的是,把你的余额发送到一个他们控制的地址。最坏的情形被限定在市场结果之内,而不是被限定在盗窃之内,并且它不取决于任何人的偿付能力,只取决于你自己的。
一个 Hyperliquid 代理批准究竟授予了什么 Hyperliquid 通过其代理系统(有时也称为 API 钱包)原生地实现了这种委托。你用自己的钱包签署一次性的批准,授权一个指定的代理地址代表你的账户提交签署过的动作。这项批准本身就是 Hyperliquid 上的一个动作,由账户所有者签署,并且精确地标明了哪一个地址正在被授予权限。
一旦获得批准,该代理就可以签署 Hyperliquid 向代理开放的交易动作:下单、撤单、修改订单、开仓与平仓,以及调整其所管理仓位的杠杆或保证金设置。在我们的场景中,正是这项权限使得镜像交易能够在每个隔离子账户中执行,而无需你为每一笔单独的订单签名——这是让跟单交易系统得以运行的唯一方式,因为领跑者持续不断地交易,逐笔手动批准会导致敞口永远无法匹配。
关于这项批准,有两个特性值得明确指出。它是地址范围限定的:权限属于你所批准的那个特定代理地址,没有任何其他地址会继承它。并且它与所有权是分离的:代理密钥不是你的账户密钥,无法推导出账户密钥,并且除了 Hyperliquid 允许代理签署的动作集之外,对该账户没有任何其他索取权。批准一个代理,并不是把你的钱包交出去——而是登记了第二个刻意被设计得更弱的签署者。
此外还有一个大多数用户会一同遇到的独立批准:构建者费用。它授权的是一笔按镜像名义价值收取的 0.1% 费用,这是一项具有独立上限的独立权限,而不是交易权限的一部分。两项批准,两个目的,都由你本人明确签署。
该代理无法做什么 这个安全性的论证依赖于被排除的事项,因此值得明确陈述,而不是含糊带过。
留在该代理权限范围内的,恰恰是一个跟单交易系统所需要的,仅此而已:下单和平仓的能力。这不是一项微不足道的权限——通过市场产生亏损完全是可能的——但它是实现这一功能所需的最小可行权限,而这正是评判一个系统所应采用的正确标准。
它无法提现。从 Hyperliquid 提现到外部链地址需要账户所有者的签名。代理权限不延伸到提现动作,因此没有任何代理——无论是我们的,还是一个被攻破的代理——能够把资金转出该账户。 它无法将资金转移到另一个地址。将你的余额发送给第三方不在代理动作集之内。资金可以作为配置的一部分在你自己的账户与你自己的子账户之间移动,但无法跨出你所控制的所有权边界。 它无法更改所有权或接管账户。账户密钥始终留在你手中。代理无法轮换它、替换它,也无法把你锁在外面。 它无法批准更多的代理。委托不会自我叠加。只有账户所有者才能批准代理,因此一个代理无法扩大自己的权限或创建第二个签署者。 它无法阻止你自己采取行动。你自己的密钥在整个过程中始终保有完整权限。你可以随时自己交易该账户、手动平掉镜像仓位,或者提现——无需征求我们的同意,也不需要等待我们。 为什么可撤销性很重要 一项你无法单方面撤回的许可,其实并不是许可,而是一种转移。可撤销性是让这种委托保持可逆的关键,也是这种模式在实践中而非仅在原则上最能区别于托管的属性。
由于批准是你自己账户上的一个链上动作,撤销它同样也是。你用自己的密钥撤销代理权限。你不需要我们的配合、我们的正常运行,或我们的同意——而且至关重要的是,你不需要转移资金才能退出。在托管模式下,离开意味着提交一次提现请求,然后等待别人处理它,而这恰恰是当平台出现问题时最容易失效的那一步。在这里,撤销会立即终止未来的交易权限,而你的余额则完全停留在原来的位置。
有两点值得坦诚说明。撤销并不会平掉仓位:任何已开立的镜像仓位仍会保持开放,带着它们自己的保证金和爆仓价格,直到你或系统将其平仓——所以如果你的意图是清空仓位,应该先撤销再平仓,或先平仓再撤销。并且撤销不具有溯及力。它只终止未来的权限,不会撤销已经执行过的交易。可撤销性限定的是暴露于被委托签署者之下的时长,而不是该签署者已经造成的后果。
这与其他替代方案相比如何 交易所 API 密钥是最接近的类比,这个比较也很有启发性。一个禁用了提现权限的仅限交易 API 密钥能实现类似的权限分离,这也是一种合理的模式。区别在于执行方式和可验证性:API 密钥的权限范围是一个中心化交易所系统内的设置项,作用于该交易所已经托管的资金,你只能通过信任他们的界面来验证它。而一个 Hyperliquid 代理批准是针对你自己拥有的账户的链上动作,其动作集由协议本身而非某个权限表来强制执行。如果一个采用 API 密钥系统的运营方被攻破,你的密钥暴露了,但你的资金本来就已经放在一个托管方那里;而在这里,整个流程中根本不存在托管方。
托管式跟单交易平台则完全属于另一种不同的风险类别。你存入,他们持有,他们交易,你持有的是一份索取权。这在你已经承担的所有市场风险之上,又叠加了交易对手风险、破产风险和提现暂停风险,而这些额外的风险没有任何东西可以补偿。它们的存在纯粹是这种架构本身造成的。
而资金池和基金式的结构则更进一步:你的资本与其他用户的资本在一个共享账户或载体中被混同在一起。除了交易对手风险之外,这还剥夺了你仓位的独立性——你的入场价格、你的爆仓风险和你已实现的结果,都与其他参与者的资金流动纠缠在一起,在一个轧差账户中,还与他们的反向仓位纠缠在一起。我们的模式在设计上恰恰是相反的结构:资本留在你自己的账户中,被镜像到你自己的隔离子账户中,每位领跑者一个子账户,各自拥有独立的保证金和独立的爆仓价格。你的仓位属于你自己,可以逐一归因,且不受任何其他人行为的影响。
权限设计是一项风险决策 每一个自动化交易系统都要求你委托出一些东西,因为没有委托的自动化本身就是自相矛盾的。真正值得问的问题只是:委托了多少、由什么来强制执行,以及你能多快把它收回。这是一项设计决策,理应和杠杆限制、仓位规模一样被严肃对待,而不是被放进一段营销文案里。
这里的模式被刻意设计得很狭窄:仅限交易权限,限定于一个被批准的代理地址,由 Hyperliquid 而非由我们的承诺来强制执行,可由你随时撤销,资金始终不会离开你自己拥有的账户。它从图景中消除了托管风险和交易对手风险。它并不消除市场风险、爆仓风险、执行滑点,或者某位领跑者表现不佳的可能性——一个暗示相反情况的系统,就是在错误地表述一个权限模型所能做到的事情。
如果你想了解完整的全貌,文档详细列出了批准步骤和隔离模型,风险披露则明确说明了这种架构无法保护你免受哪些风险。