从五层金融堆栈拆解 Hyperliquid 成功的秘密

Favoritecollect
Shareshare

作者: Baheet

编译:佳欢,ChainCatcher

机构级金融基础设施的构建往往有迹可循。你不能从最具表现力的产品开始,然后再逆向推进。

你要从清算层开始,证明它能在压力下正常运作,然后再去解锁依赖于它的所有功能。

纽约证券交易所并不是在拥有运作良好的股票市场之前就增加了衍生品。芝加哥商品交易所也不是在推出期货之前就推出了期权。

这种顺序绝非随意为之。基层的顺序决定了顶层建筑的可能性。

Hyperliquid 深谙此道。

大众普遍将 Hyperliquid 视为一个不断交付产品的 DEX。一个添加了现货、代币化资产、然后是预测市场的永续合约交易所。一个行动迅速的团队。

这种说法并没错,但它完全偏离了重点。

Hyperliquid 并不是建立了一个 DEX 然后不断添加产品。他们构建的是一个清算引擎,并逐层对其进行解锁。

每一个 HIP 都是先决条件,而不是单纯的功能。

而 HIP-4,那个被所有人称为 Polymarket 杀手的提案,正是其目标从一开始就十分明确的最终证明。

在任何 HIP 出现之前,有一个设计决策决定了后续的一切。

Hyperliquid 将 HyperCore 构建为一个完全围绕市场微观结构优化的特定应用 L1。不追求通用可编程性。不追求任意智能合约的执行。

只专注市场微观结构。亚秒级确认、可预测的执行、清晰的状态管理,以及一个能够处理专业衍生品交易吞吐量需求的撮合引擎。

这是一种刻意设定的约束。通过拒绝构建通用链,Hyperliquid 放弃了以太坊Solana 竞相争夺的开发者广度。

作为回报,他们得到了一个从第一天起就能可靠支持机构级市场的清算引擎。

这种性能保证是基于 AMM 的 DEX 和通用 L1 花费多年时间试图改造却仍未完全实现的。

随后出现的每一个 HIP,都是因为 HyperCore 最先以这种方式构建才成为可能。

约束本身就是战略。

HIP-1:资产标准

第一层是最基础的,也是最少被谈论的。

HIP-1 引入了 Hyperliquid 的原生代币标准,这是该协议对 ERC-20 的回应,但存在一个关键的结构性差异。

HIP-1 下的代币不是存在于通用虚拟机上的智能合约余额。它们是 HyperCore 引擎本身的原生单位,从存在那一刻起,就可以直接在高性能撮合基础设施内进行交易。

这种区别远比听起来更重要。

以太坊上,资产和交易该资产的交易所是独立的系统,必须跨越合约边界进行通信。

在 Hyperliquid 上,资产和交易所是同一个系统。它们之间没有桥梁,没有跨合约调用引入的延迟,也没有困扰建立在通用链上的 DeFi 协议的那种执行风险空间。

HIP-1 解决了资产可用性问题。

但其更深层次的功能是,确立了 HyperCore 可以作为金融原语的原生家园,而不仅仅是任意代码的执行环境。

没有这个证明,后面的一切都将不可信。

HIP-2:引导流动性

没有流动性的资产毫无意义。这就是冷启动问题,它扼杀的有潜力的协议远多于任何技术故障。

在交易者出现之前你需要流动性,在流动性提供者出现之前你需要交易者。

大多数项目通过激励计划、代币释放时间表和做市商补贴来缓解这种矛盾。这些不是解决方案。这些是拖延。

HIP-2 引入了 Hyperliquidity,一种直接内置于协议层的原生算法做市机制。

与被动等待交易量并让流动性提供者在市场结算时面临必然无常损失的 AMM 不同,Hyperliquidity 以一种从第一个区块起就使经济模型具有可持续性的方式,自动化了现货资产的流动性提供。

在 Hyperliquid 上推出的任何资产都能立刻拥有一个功能健全的市场。不是"最终会有"。是立刻。

HIP-2 的意义不仅在于运营层面。它证明了 HyperCore 原生就能解决冷启动问题,而无需将流动性引导外包给外部做市商或激励计划。

这一证明为接下来的发展奠定了基础。无许可的永续合约将面临更大规模的相同冷启动问题。HIP-2 表明该引擎完全能够应对。

HIP-3:压力测试

正是从这里开始,这一论点变得不容置疑。

HIP-3 打破了上币垄断。在此之前,@HyperliquidX 上的每一个市场都是由核心团队部署和管理的,这种中心化模式保证了质量,但限制了多样性。

HIP-3 引入了由构建者部署的永续合约,允许外部团队在无需许可的情况下部署任何资产的永续市场。

模因币、指数、盘前代币、小众交易对。任何能质押一百万个 HYPE 的人都可以上架一个市场,并在 HyperCore 的基础设施内运营。

结果立竿见影。未平仓合约量从不到 2 亿美元增长到超过 12.6 亿美元。日交易量达到 59 亿美元。

早期参与者在各自类别中占据了高达 85% 的市场份额。无论从哪个标准来看,HIP-3 都是一次爆发。

但 HIP-3 做的最重要的事情并不是创造交易量。

它证明了在 HyperCore 上创建无许可市场可以在真实条件下大规模运作,并能承受真实的资金风险。

撮合引擎挺住了。状态管理挺住了。费用机制挺住了。

HyperCore 现在已经通过了跨数十种资产同时进行无许可衍生品交易的压力测试。

HIP-3 是考试。HIP-4 才是考试的意义所在。

HIP-4:终极目标

结果合约看似预测市场产品。实则是整个架构的闭环。

HIP-4 引入了全额抵押、二元结算的合约,这些合约在 0 和 1 之间交易,并根据可验证的事件结果结算为其中一个值。

没有清算,入场即固定风险敞口,以 USDH 进行现金结算。

表面上看,这使 Hyperliquid 与 Polymarket 和 Kalshi 形成了直接竞争。这种框架没有错,但它低估了正在发生的实质性变革。

HIP-4 更深层次的功能是将 HyperCore 的定价能力从资产和杠杆扩展到了概率本身。

在 HIP-4 之前,HyperCore 可以为一个资产的价值以及市场能够支持多少杠杆定价。在 HIP-4 之后,它可以为某件事是否会发生定价。

这一步补上了金融操作系统的最后一环。

价格方向、杠杆和概率是金融风险的三个基本维度。HyperCore 现在可以在统一的保证金环境中,在同一个清算引擎上,原生表达这三个维度。

这才是使得全仓保证金能力成为 HIP-4 最重要功能的原因,而不仅仅是表面的预测市场。

交易者可以使用相同的抵押品,同时持有一个杠杆永续合约头寸和购买一份结果合约。

预测市场层面的闲置资金变成了永续合约层面的活跃资本。

这两个系统不是共享资产负债表的相邻产品。它们是同一个系统,针对同一个清算基础设施表达不同维度的风险。

现有的任何预测市场都无法提供这一点,因为没有任何现有的预测市场是建立在经过验证的衍生品清算引擎之上的。

Polymarket 和 Kalshi 是二元投注的结算层。而 HyperCore 是一个金融操作系统,现在恰好支持二元投注作为其众多原语之一。

当你观察更广泛的生态系统如何处理同样的问题时,Hyperliquid 做出的顺序选择就变得更加清晰。

大多数区块链基础设施都是围绕一个核心信念设计的:首先赋予开发者最大的可编程空间,性能随后就会跟上。

这并非错误。考虑到该行业早年的需求,这是一个理性的赌注。

以太坊的可编程性解锁了整整一类原本不可能实现的金融实验。Solana 的吞吐量证明了链上系统可以接近真实金融应用的速度需求。

这两条链都取得了真正的突破,并继续承载着加密领域一些最重要的应用。

但是,可编程空间优先于性能会产生一种特定的技术债务。

当建立在通用链上的应用发展得足够复杂,需要机构级别的执行力时,该链就必须去改造它在打基础时没有优先考虑的性能保证。

这种改造是困难的、昂贵的,而且永远无法完全干净利落。

执行环境并非围绕市场微观结构设计,再多的 Layer 2 扩容或验证者优化也无法完全弥补最初的设计选择。

Hyperliquid 打了相反的赌。在基础层将设计空间完全限制在市场微观结构上,然后再在一个已经在真实条件下被验证的清算引擎之上解锁可编程空间。

代价是早期开发者接触面较窄。回报则是建立在 HyperCore 之上的每一个产品,都继承了底层清算层的可靠性。

这不是对通用链的批评。这是一种观察:当金融基础设施从第一性原理出发,围绕市场而不是可编程性进行设计时,会产生怎样的可能性。

两个不同的起点,两个不同的终点。

这个团队要建的从来不是更好的币安。那种格局始终太小了。

Hyperliquid 实际构建的是一个金融操作系统的最小可行技术栈,并且是以唯一在结构上合理的顺序组装起来的。

清算第一。资产第二。流动性第三。杠杆第四。概率第五。

每一层都是对下一层的概念验证。每一个 HIP 都是先决条件,而不是功能。

证据就在这个顺序本身。

HIP-3 不是因为团队对无许可永续合约有了一个好主意才接在 HIP-2 后面。它之所以紧随其后,是因为 HIP-2 已经证明了 HyperCore 原生就能解决冷启动问题。

HIP-4 不是因为预测市场正流行才接在 HIP-3 后面。它之所以紧随其后,是因为 HIP-3 已经让清算引擎在真实资金下,跨越数十种资产同时进行了大规模的压力测试。

这种顺序本身就是最佳论据。

HyperCore 现在可以为资产定价、维持流动性、表达杠杆以及结算概率。

这不是一个行动迅速的团队随着时间推移拼凑出的功能清单。这是一个有着明确目标的架构。

终点一直都是 HIP-4。只是需要四个先决条件才能到达。

就到这里!

Disclaimer: This article is copyrighted by the original author and does not represent MyToken’s views and positions. If you have any questions regarding content or copyright, please contact us.(www.mytokencap.com)contact
More exciting content is available on
X(https://x.com/MyTokencap)
or join the community to learn more:MyToken-English Telegram Group
https://t.me/mytokenGroup