深入解读 HIP-3：以构建者为中心

Hyperliquid 改进提案 3 (HIP-3) [1] 引入了一项根本性变革，改变了 Hyperliquid 上永续合约市场的创建和扩展方式。通过向第三方构建者开放市场上市流程，HIP-3 将上市从一种由平台控制的、需要判断力的行为转变为一种基于规则的、协议层面的接口。

自部署到主网以来，构建者部署的市场在大约三个月内产生了超过 130 亿美元的交易量，证明 HIP-3 可以实质性地提高市场扩张的可扩展性和灵活性。然而，这种转变不仅仅是权力去中心化；它也重新分配了责任。之前由中心化平台运营承担或缓释的风险，现在直接由构建者承担。

因此，HIP-3 下的核心问题不再是市场能否启动，而是市场能否长期安全运行。本报告从以构建者为中心的角度分析 HIP-3，重点关注市场的定义和运营方式、构建者面临的风险以及如何缓解这些风险，特别是与预言机相关的风险。

0x0 背景

Hyperliquid 的架构 [2] 通过将执行和风险基础设施与市场定义分离，打破了这种模式。其双层设计包括：

HyperCore：一个专为衍生品交易优化的 Layer 1 区块链，提供统一的撮合、清算和结算。
HyperEVM：一个兼容 EVM 的应用程序层，支持可扩展的逻辑和构建者交互。

由于执行和清算是在协议层面统一强制执行的，新市场可以在不重新实现关键安全逻辑的情况下重用相同的核心基础设施。然而，定价无法完全标准化。预言机输入、杠杆设计和运行时操作不可避免地因市场而异，这使得定价成为去中心化与风险相遇的主要接口。

尽管有这种架构，Hyperliquid 的原生永续合约市场（也称为验证者运营的 perp）的上市流程仍然类似于传统的 CEX 方法。新合约的上市主要由核心团队驱动，而退市则通过验证者投票决定。

HIP-3 的引入旨在通过启用构建者部署的永续合约市场来实现上市流程的去中心化。它通过允许构建者定义和运营市场，同时协议强制执行严格的执行和风险边界，从而正式化了市场定义与协议强制执行之间的分离。因此，HIP-3 代表了迈向完全去中心化的 perp 上市流程的关键里程碑。

0x1 构建者责任：定义与运营

在 HIP-3 下，构建者承担市场生命周期管理的端到端责任。在本节中，我们将首先介绍市场启动流程，然后重点介绍最直接决定生产环境中市场稳定性的运营杠杆。

0x1.1 市场启动流程：定义与运营

在 HIP-3 下，启动市场并非单一操作。如完整的市场启动流程图所示，这是一个跨越两个不同阶段的过程：市场定义（步骤 1 至 4）和市场运营（步骤 5）。

在市场定义阶段，构建者首先必须在主网上质押 500,000 HYPE。满足质押要求后，构建者可以部署一个永续 DEX，它形成一个独立的交易域，拥有自己的保证金系统、订单簿和部署者控制的设置。在 DEX 层面，构建者选择一个计价资产作为该 DEX 上所有市场的抵押品。所选的计价资产必须保持无需许可的状态，因为失去此状态将禁用相应的 DEX。然后，构建者定义核心市场参数，包括预言机规格、合约参数（如符号和杠杆限制）以及保证金表。前三个市场可以直接部署，而额外的市场需要通过荷兰式拍卖获取插槽。

荷兰式拍卖：每轮持续 31 小时，每次的起拍价是上一轮最终价（最后获胜价/最低价）的 2 倍。

一旦市场上线，构建者就进入市场运营阶段。此阶段涉及通过 setOracle 接口持续更新预言机价格、维护杠杆和保证金配置、监控流动性和未平仓量，以及在必要时执行紧急操作（如暂停交易和结算头寸）。

在实践中，HIP-3 下最严重的故障通常不是发生在市场定义期间，而是发生在压力市场条件下长时间运行期间。重要的是，构建者的责任在暂停市场后不会立即结束。只有在所有市场结算后才能取消质押，并且在强制取消质押期间，质押仍可能被罚没。

0x1.2 关键关注领域：定价与偿付能力

构建者在市场定义和市场运营中面临两个耦合的关注领域：预言机配置和价格形成，以及压力下的市场偿付能力。这两个领域紧密耦合，因为定价故障会通过协议层面的风险控制迅速传播到偿付能力压力。

1. 预言机配置与价格形成

Hyperliquid 定义两种价格：

预言机价格：来自主要外部交易所的现货中间价的加权中位数，旨在独立于 Hyperliquid 的内部市场数据，主要用于锚定融资。
标记价格：一个内部风险价格，来源于多个输入，包括预言机价格和本地市场数据，用于未实现损益 (PnL) 和风险控制。

简而言之，预言机价格锚定融资，而标记价格驱动保证金检查、清算以及止盈 (TP) 和止损 (SL) 触发器。

在 HIP-3 下，预言机价格和标记价格的作用不变，但计算机制发生了变化：

a) setOracle 的输入

oraclePx（必需）：与 HyperCore 中的定义相同。
markPx（可选）：0-2 个外部计算的标记价格候选值。
externalPerpPx（必需）：一个参考值，用于防止标记价格突然偏离。

构建者通常部署中继器节点来提供价格：oraclePx 从多个外部来源计算，markPx 由中继器使用自定义算法计算，externalPerpPx 来自多个 CEX 的 perp 中间价的加权中位数。

b) 实际标记价格

计算本地标记价格：median(best bid, best ask, last trade)。
将本地标记价格和 markPx（0-2 个值）结合起来，取中位数得到新的标记价格。

c) setOracle 约束

更新频率：调用之间至少间隔 2.5 秒；如果 10 秒内未更新 markPx，则回退到本地标记价格。
幅度限制：markPx 每次更新最多变化 ±1%；所有价格被限制在日开始价的 10 倍以内。

为什么资产类型在 HIP-3 定价中很重要？

在 HIP-3 下，可以为任何类型的资产启动永续合约市场。这些资产通常可分为 24/7 资产（全天候可交易）和非 24/7 资产（仅在特定市场交易时段可交易，交易时段外无现货交易）。交易时间的差异决定了价格的来源和维护方式。

对于 24/7 资产（例如 BTC），可以通过聚合 CEX、DEX 或可信预言机服务的数据来持续获得相对稳定的价格。

对于非 24/7 资产（例如股票），仅在官方交易时段才能获得足够的流动性和可靠的外部市场价格。为了在 HIP-3 上保持此类资产的持续交易，必须在非市场交易时段使用单独的定价机制。

以 trade.xyz 上的股票 perp 市场为例：

市场交易时段：Pyth 等外部预言机服务提供稳定的预言机价格。
非市场交易时段：价格根据资产的最后收盘价，结合订单簿的内部买卖压力进行调整。标记价格被限制在距离最后收盘价 ±1 / max_leverage 的范围内波动（例如，特斯拉：10 倍杠杆 → ±10%）。

2. 压力下的市场偿付能力

Hyperliquid 采用两种机制，清算和 ADL（自动减杠杆），来维持市场偿付能力。在 HIP-3 下，清算和 ADL 大部分遵循 HyperCore 的设计。主要区别在于一项协议层面的限制：HLP（Hyperliquidity Provider），作为协议金库，不能在 HIP-3 市场中承担高风险头寸。因此，HyperCore 中用于吸收市场清算和 ADL 之间头寸的中间金库缓冲池在 HIP-3 中不存在。

鉴于此清算到 ADL 路径在压力市场条件下的重要性，我们将在下文详细回顾清算和 ADL。此处讨论的所有偿付能力机制都假设了隔离保证金，这是 HIP-3 市场目前唯一支持的保证金模式。

a) 清算

当头寸净值（隔离头寸价值）不足以满足维持保证金要求时，清算将被触发，该头寸将变得可清算。所有与清算相关的检查均基于标记价格，而非特定成交价。

清算价格公式定义如下：

其中：

side：多头头寸为 1，空头头寸为 -1
l 是维持保证金比例

MAINTENANCE_LEVERAGE 的值由与头寸相关的保证金层级决定。从该层级获取维持保证金比例 mmr：

在配置保证金层级时，请应用与清算价格下的头寸名义价值相关的层级的 mmr。

margin_available (isolated)：isolated_margin - maintenance_margin_required

一旦头寸变得可清算，系统将首先尝试通过订单簿上的市价单平仓。如果执行成功将风险恢复到安全范围内，剩余的保证金将退还给交易者。

然而，在订单簿深度不足或价格跳空的情况下，实际平均成交价可能远差于标记价格，从而导致**“清算亏空”**。

隔离头寸价值是指在当前标记价格下隔离头寸的净值，代表该头寸在考虑未实现损益后分配的保证金。

b) ADL（自动减杠杆）

在极端情况下，ADL（自动减杠杆）机制充当最后的保障。

当隔离头寸价值变为负值时，ADL 被触发。系统按损益和杠杆对盈利对手方进行排名，然后强制以上一个标记价格（ADL 触发前上一个记录的标记价格）来减少或平仓这些头寸。通过使用获利方的利润来抵消赤字，协议保持偿付能力，不产生坏账。

排序指数计算如下：

此处，notional_position 指头寸在当前标记价格下的绝对市场价值，计算方式为 |position_size| × mark_price。account_value 指账户在标记价格下的权益，即抵押品价值加上未实现损益。

示例：

在触发 ADL 之前，系统的标记价格 = 3,000。
由于 setOracle 的限制，新的标记价格只能更新到2,970（-1%）。
然而，订单簿的买方深度非常薄。在清算市价单冲击订单簿后，实际平均成交价 = 2,910（相对于 3,000 降低了 3%）。
多头头寸的损失以 2,910 结算，可能导致隔离头寸价值跌至零以下并产生亏空，从而触发 ADL。
ADL 然后选择对手方（盈利的空头）头寸，并强制以上一个标记价格 = 3,000 来减少/平仓，将亏空转移到**“获利方被动赚取更少”**。

0x2 构建者风险格局

在 HIP-3 下，风险不再是抽象或纯粹理论上的，对于构建者而言。通过质押和验证者管理的罚没，运营故障和错误配置可以直接转化为经济处罚。因此，理解罚没如何触发以及哪些类型的构建者行为会导致罚没，成为构建者风险模型的核心。因此，本节首先解释罚没机制作为问责框架，然后分析 HIP-3 下构建者风险的两个主要来源。

0x2.1 罚没机制与问责

HIP-3 通过质押和验证者管理的罚没来执行问责。罚没是严格基于结果的。Hyperliquid 不区分恶意行为、操作失误、私钥泄露或第三方依赖故障。

质押要求：在主网上，构建者必须保持质押 500k HYPE。即使构建者暂停其所有市场，他们也必须继续维持质押 30 天（交易暂停并不立即免除责任）。

如果构建者的行为导致状态无效、长时间停机或性能严重下降，可能会触发罚没。根据严重程度，罚没的范围可以从部分质押扣减到全部质押销毁。此设计使构建者在经济上对其市场的全部运行时行为负责。

罚没比例由验证者投票决定，参考上限如下：

状态无效/长时间停机：最高 100%

短暂停机：最高 50%

性能下降：最高 20%

被罚没的代币将被销毁，而不是重新分配。

在 HIP-3 下，构建者风险主要来源于两个方面：内部参数配置错误和外部预言机依赖。以下各节详细探讨了这两个来源，并解释了它们如何转化为罚没结果。

0x2.2 内部参数配置错误的风险

配置错误风险包括在低流动性市场中过度杠杆、不当的保证金表设计、导致大量头寸可清算的突然参数更改，以及不当使用紧急控制（如暂停交易）。

这些风险在很大程度上是确定性的且可预防的。通过充分的注意、审查和操作纪律，可以避免大多数内部配置错误。虽然它们很重要，但它们不是 HIP-3 下最具结构性挑战的风险。

1. setOracle

预言机价格通常来自构建者的中继器服务器，这引入了中心化风险。如果私钥泄露或中继器遭受 DDoS 攻击，市场的预言机价格可能会被恶意操纵或长时间偏离。

2. haltTrading

构建者可以通过 haltTrading 取消市场中的所有订单，并以当前标记价格平仓。此操作应谨慎使用。例如，如果检测到市场被攻击者恶意操纵，并调用 haltTrading 以标记价格平仓，则可能会直接实现攻击者的未实现利润（攻击者可能因此难以找到足够的对手方订单），并可能导致坏账。

3. setMarginTableIds & InsertMarginTable

InsertMarginTable：定义一个新的保证金表，指定一类资产的保证金要求和最大杠杆。
setMarginTableIds：将市场与指定的 marginTableId 绑定。

对于低流动性/市场做市不足的市场，设置过高的最大杠杆会增加触发 ADL 的概率。

突然切换 marginTableId 等同于修改用户头寸的维持保证金比例，这可能导致许多账户同时从安全变为可清算，从而触发级联清算。

4. setMarginModes

HIP-3 目前仅允许隔离保证金，未来可能支持交叉保证金。在一个同时托管高流动性和低流动性市场的 DEX 中，交叉保证金可能导致风险传染，即非流动性市场的损失会传播到流动性市场。因此，在官方团队提供成熟的解决方案之前，不建议构建者引入交叉保证金。

0x2.3 外部预言机依赖风险

对于24/7 资产，主要风险在于外部预言机服务的准确性和稳定性，以及前面讨论的中继器服务器的中心化风险。这些外部依赖关系的任何中断、延迟或操纵都会直接影响定价的完整性和下游风险控制。

对于非 24/7 资产，风险范围显著扩大，主要集中在非交易时段如何获取或计算预言机价格。

以 trade.xyz 为例，在非市场交易时段，价格由最后一个可用的外部预言机价格和内部市场价格的组合派生。在周末，股票永续合约市场通常流动性严重下降——订单簿变得稀疏，做市商减少报价——同时没有外部预言机价格可供锚定。尽管施加了价格变动的硬上限（例如，1 / max_leverage），但对于低波动性资产而言，此限制仍然可能过于宽松。在此范围内的价格变动仍可能触发大规模清算甚至 ADL 事件。

2025 年 12 月 14 日，trade.xyz 上的 XYZ100-USDC 市场（跟踪 NASDAQ-100 的永续合约）遭到操纵。一名攻击者卖空了 398 XYZ100（名义敞口约 1000 万 USDC），导致严重的价格脱锚。大量多头头寸被清算，而清算本身进一步推低价格，最终导致多头方约 1300 万 USDC 的清算。

this is probably the first such move under the ‘growth mode’ regime on the weekend. Someone slammed the market, dropping the price of XYZ100 by more than 3% in a minute and liquidating roughly $3M worth of positions pic.twitter.com/XttBHfTB0D
— bart.hl (equity perps era) (@bartdothl) December 14, 2025

另一方面，在非交易时段，缺乏持续且外部锚定的预言机价格迫使市场依赖由“上次外部价格 + 内部订单簿”形成的受限内部定价区间（例如，trade.xyz 将最大波动幅度限制在 1/max_leverage）。

最关键的风险出现在市场重新开放过渡期。外部市场可以突然提供一个清晰且权威的参考价格。如果此价格与内部非市场交易时段的定价存在显著差距，系统将面临两种不利局面：要么价格保持锁定，导致外部公允价值与可交易价格之间出现严重分歧，要么系统快速切换回外部锚定，触发突然的重新定价。这两种情况都可能在短时间内集中清算压力，在极端情况下，可能导致** ADL 事件激增**。

0x3 构建者风险控制

仅靠配置纪律无法消除风险。最有效的缓解策略侧重于减少对预言机依赖故障的暴露。

0x3.1 选择稳定的预言机

对于非 24/7 交易资产（如股票），主要挑战在于非市场交易时段的定价。在此期间，稳定且外部锚定的价格参考稀少，使得市场更容易受到操纵或在薄流动性下出现内生漂移。

目前，行业方法通常分为两个方向：

暂停预言机更新，并在非市场交易时段限制交易。例如，Lighter 协议在标的资产市场关闭时仅接受减仓订单。Ostium 等协议在非市场交易时段进一步降低最大杠杆，并强制清算超出新限制的头寸。
采用“内部定价”机制，如 trade.xyz 所示，其中协议在外部数据不可用时，通过依赖内部流动性和定价算法在非市场交易时段继续运行。

这两种方法反映了安全性和用户体验之间的基本权衡。第一种方法优先考虑严格的风险控制，但会显著降低交易连续性和用户体验。第二种方法保留了连续交易，但由于缺乏外部参考，增加了内部价格偏离资产基本价值的风险。

在非市场交易时段，协议定价应避免完全退化为纯粹的内部价格。相反，引入外部参考锚定可以减少脱锚和跳空风险。可能的参考包括：

Blue Ocean ATS。作为一个盘后/隔夜交易场所，它可以在关闭期间提供一定程度的持续价格参考（比“最后收盘价”更及时），有助于生成收盘期间的预言机价格或作为脱锚的监控基准。
IG Weekend CFD Quotes。周末 CFD 报价可以提供反映“周末市场预期”的替代价格信号，适合作为关闭期间的外部锚定或监控比较，以帮助提前检测到“开盘跳空”的可能方向和幅度。

这些来源的共同特点是它们能够在非市场交易时段提供价格信号。然而，它们不具备与标的现货市场相同的市场结构，因此更适合作为锚定、参考或早期预警信号，而不是无条件的替代品。

0x3.2 价格验证

在 HIP-3 下，预言机价格来源于构建者运营的中继器服务器，这引起了关于中心化的担忧。为了缓解这一问题，鼓励构建者实施一个价格验证框架，允许任何用户或机构在链下验证定价的正确性和公平性——类似于 RedStone，它将价格与数据源和加密证明打包在一起。

1. 数据透明度

算法规范：公开披露定价算法和计算逻辑。
数据源列表：所有来源都应该是公开的、不受构建者操纵的，并附有详细的接口和参数文档。
价格提交规则：setOracle 的权限、触发条件、更新频率和波动性限制。

2. 价格证明

对于每次 setOracle 调用，生成一个包含以下内容的相应证明：

输入：采样时间戳的每个数据源的原始（或标准化）响应。
计算：每个计算步骤的可重现中间值。
输出：在链上提交的预言机价格。

每个证明被序列化为 proofHash，然后由 oracleUpdater 签名。

3. 链上承诺

在 Merkle 树中维护 proofHash 条目的顺序列表。
定期（例如，每小时或每天）将 MerkleRoot 发布到链上。

4. 验证

提供开源工具或网页，用户可以在其中输入时间范围或 setOracle 交易哈希
验证签名、时间戳和 MerkleRoot 等。
使用公共算法重新计算预言机价格进行比较。

0x3.3 风险监控

价格验证使 setOracle 变得可重算和可审计，确立了价格供源是否可信。然而，它无法防止实时市场恶化。供源中断、价格偏离和流动性下降——与大量未平仓量 (OI) 结合时——很容易将局部异常升级为系统性风险，如级联清算甚至 ADL 事件。

因此，必须尽早检测市场异常并将其转化为可观察的信号，并在一个时间窗口内解决，以将风险控制在可管理范围内。

为了使监控可操作而非碎片化，我们将信号组织成三个层级，每个层级对应一个不同的故障模式和响应优先级。

价格端监控检测预言机供源故障和脱锚，这些可能从源头上使风险控制失效，因此被视为最高优先级，通常通过中继器故障转移、未平仓量上限和杠杆降低来解决。
订单簿端监控捕获流动性撤出和欺骗性深度，这些会加剧清算滑点和亏空风险，因此干预措施侧重于限制增量敞口，并在脆弱性增加时强制减杠杆。
头寸端监控跟踪快速的未平仓量积累和单边集中，这使得市场容易受到级联效应的影响，通常优先级低于价格和流动性信号，主要作为早期预警层，用于收紧上限和加强警报。

以下各节将依次详细介绍每个层级，以及相应的监控点和建议操作。

1. 价格端监控

a) 预言机供源故障

指标：

使用链上可观察指标判断供源是否停滞：

阈值：

Level 1：( ∆t > 5s ) — 中继器进程可能停滞或被阻塞
Level 2：( ∆t > 15s ) — 链上价格可能严重脱锚且越来越受市场驱动

操作：

Level 1：执行中继器健康检查，切换到备用中继器，并发出带有健康诊断的警报。
Level 2：调用 setOpenInterestCaps 以降低未平仓量上限。

b) 价格脱锚

指标：

信号 A (d1)：标记价格与预言机价格之间的偏差。

信号 B (d2)：订单簿中间价与预言机价格之间的偏差。

信号 C (d3)：标记价格与中间价之间的偏差。

信号 D (ext_diff)：预言机价格与外部参考价格之间的偏差。

阈值逻辑：

Level 1：A、B、D 中至少有 2 个超过阈值。
Level 2：A、B、C、D 中至少有 3 个连续 X 秒超过阈值。

操作：

Level 1：通过 setOpenInterestCaps 降低未平仓量上限。
Level 2：逐步更新保证金表以按层级降低最大杠杆，并启用中继器上的锁定机制。
Level 3：在 Level 2 条件下持续发出警报。然后构建者评估是否调用 haltTrading。

2. 订单簿端监控

a) 流动性撤出

指标：

depth_band(±x%)：距离中间价 ±x% 范围内的订单簿流动性。
spread = bestAsk - bestBid：用于衡量价差扩大的价差。
aggressiveVolume_Δt：Δt 内的 taker 量（按交易方汇总）。
impact_ratio：市场脆弱性的指标（值越高表示价格冲击脆弱性越大）。

风险模式：

depth_band 减少，同时 spread 和 impact_ratio 增加。

操作：

Level 1：通过 setOpenInterestCaps 设置 OI cap = current OI，限制增量头寸。
Level 2：通过 setMarginTableIds 强制减杠杆，同时清算高杠杆、高风险头寸。

b) 欺骗性流动性

风险模式：

depth_band 突然飙升，然后在短时间内崩溃。

操作：

Level 1：调用 setOpenInterestCaps 将 OI cap = current OI。
Level 2：如果结合严重脱锚，则考虑暂停市场。

3. 头寸端监控

头寸端监控不试图预测价格方向。相反，它识别从平衡交易活动到单边头寸积累的转变。当未平仓量快速积累，头寸高度集中，并且多数方损益达到极端水平时，即使微小的外部冲击也可能触发清算级联或 ADL 事件。

因此，头寸端操作的优先级通常低于价格端和订单簿端的干预。

a) 过度的短期未平仓量

指标：

OI_notional：未平仓名义价值。
Volume_24h_notional：24 小时名义交易量。

快速增长的比率表明从活跃周转转向投机性头寸累积，并且通常预示着剧烈波动。

操作：

Level 1：在超过阈值时触发警报。

b) 多数方损益

多数方是指观察窗口内拥有更多头寸持有者的方（多头或空头）。

指标：

avgEntry_major：多数方头寸的平均入场价。
size_major：多数方的总头寸规模。
equity_major：多数方的总权益。

多数方损益及其比率定义如下：

操作：

Level 1：在阈值被突破时发出警报。
Level 2：如果持续存在，则考虑调用 setOpenInterestCaps 来降低未平仓量上限。

0x4 结论

HIP-3 的核心叙事很简单。它将市场上市从由少数人控制的判断性流程转变为一个协议层面的能力，任何合格的构建者在满足要求后都可以调用。通过质押，构建者可以在 HyperCore 上部署自己的 perp DEX，免费上市初始市场，并通过拍卖获取额外插槽。这使得市场扩张从等待批准转变为基于规则的、无需许可的扩展。

同样清晰的是，HIP-3 并未消除风险。它重新定位并重塑了风险。以前由平台级风险控制承担的责任，现在主要由构建者通过其输入和运营质量来承担。这包括通过 setOracle 进行的预言机定价和更新周期、markPx 的选择和约束、通过保证金表的逐级杠杆设计、非 24/7 资产的非市场交易时段定价范围，以及像 haltTrading 这样的强大控制，它可以控制损失或放大损失。在薄流动性下，配置错误或运营失败可能被放大为清算级联、跳空损失，最终导致 ADL 事件。问题不再是**“市场能否上市？”，而是“上市后它能否保持稳定？”**

在协议层面，Hyperliquid 通过将权限转化为可问责的权限来应对这种风险再分配。质押结合验证者管理的罚没，对构建者的错误操作产生了明确的经济后果。定价和杠杆的约束，包括锁定、更新间隔、波动性限制和隔离保证金要求，旨在将最危险的尾部风险保持在可控范围内。在此框架下，HIP-3 的价值主张变得清晰：通过开放实现扩展，通过约束实现安全，以及通过可验证性和问责制实现长期可持续性。

HIP-3 并未使上市更自由。它使它们更加标准化，可部署，可操作，可罚没。这种标准化能否大规模运行，最终取决于预言机设计、杠杆和风险参数以及运行时监控的实际质量。如果您正在 HIP-3 之上设计市场准入规则、参数模板、警报系统或紧急工作流程，或者需要审计和持续安全支持，请随时通过 [email protected] 联系 BlockSec。

参考

[1] https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals [2] https://hyperliquid.gitbook.io/hyperliquid-docs

关于 BlockSec

BlockSec 是一家全栈区块链安全和加密合规提供商。我们构建产品和服务，帮助客户执行代码审计（包括智能合约、区块链和钱包）、实时拦截攻击、分析事件、追踪非法资金，并在协议和平台的全生命周期内履行 AML/CFT 义务。

BlockSec 在顶级会议上发表了多篇区块链安全论文，报告了 DeFi 应用的多次零日攻击，成功阻止了多次黑客攻击，挽救了超过 2000 万美元，并保护了数十亿美元的加密货币。