Hyperliquid 改进提案 3 (HIP-3) [1] 引入了一种根本性的变化，改变了 Hyperliquid 上永续市场的创建和扩展方式。通过向第三方构建者开放市场上市流程，HIP-3 将上市从一项由平台自行决定、平台控制的行动转变为一项协议级别的、需要授权的接口。

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

因此，HIP-3 下的核心问题不再是市场能否启动，而是它能否随着时间的推移安全运行。本报告从以构建者为中心的视角分析了 HIP-3，重点关注市场的定义和运行方式、构建者面临的风险以及如何减轻这些风险，特别是与预言机相关的风险。

0x1 背景

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

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

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

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

0x2 构建者责任：定义和运营

根据 HIP-3，构建者的职责涵盖两个阶段：市场定义和市场运营。我们首先概述端到端的启动工作流程，然后重点介绍决定市场在生产中保持稳定的关键关注领域。

0x2.1 启动市场流程：定义和运营

根据 HIP-3，启动市场不是单一动作。如下面的完整市场启动工作流程所示，这是一个跨越两个独立阶段的过程：市场定义（第 1 至 4 步）和市场运营（第 5 步）。

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

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

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

实际上，HIP-3 下最严重的失败大多数不是发生在市场定义期间，而是发生在压力市场条件下长时间运行时。重要的是，构建者的责任在停止市场后不会立即结束。只有在所有市场结算后才能取消质押，并且在强制取消质押期间，质押仍然可能被罚没。

0x2.2 关键关注领域：定价和偿付能力

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

0x2.2.1 预言机配置和价格形成

Hyperliquid 定义了两个价格：

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

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

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

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

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

2. 实际标记价格
   • 计算本地标记价格：median(best bid, best ask, last trade)。
   • 将本地标记价格和 markPx（0-2 个值）放在一起，取中位数以获得新的标记价格。
3. setOracle 限制
   • 更新频率：调用之间至少间隔 2.5 秒；如果 markPx 10 秒内未更新，则回退到本地标记价格。
   • 幅度限制：markPx 每次更新最多可更改 ±1%；所有价格都被限制在日初价格的 10 倍以内。

HIP-3 中资产类型对定价的重要性

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

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

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

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

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

0x2.2.2 压力下的市场偿付能力

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

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

1. 清算

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

清算价格公式定义如下：

其中：

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

MAINTENANCE_LEVERAGE 的值由与头寸对应的保证金级别确定。从该级别，可以获得维持保证金比例 mmr：

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

• margin_available（隔离）：isolated_margin - maintenance_margin_required

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

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

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

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 强制减少/关闭它们，将亏空转移到**“获胜方被动赚取更少”**。

0x3 构建者风险格局

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

0x3.1 罚没机制与问责

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

质押要求：在主网上，构建者必须保持质押 500k HYPE。即使构建者停止其所有市场，他们也必须继续保持 30 天（责任不会立即消失，因为交易已停止）。

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

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

• 状态无效/长时间停机：最高 100%
• 短暂停机：最高 50%
• 性能下降：最高 20%

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

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

0x3.2 内部参数配置错误带来的风险

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

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

1. setOracle

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

2. haltTrading

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

3. setMarginTableIds & InsertMarginTable

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

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

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

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

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

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

以 trade.xyz 为例，在非市场时段，价格是根据最后可用的外部预言机价格和内部市场价格的组合得出的。在周末，股票永续市场通常面临流动性严重下降——订单簿变得稀疏，做市商减少报价——而没有外部预言机价格提供锚定。即使有价格变动的硬上限（例如，1 / max_leverage），对于低波动性资产来说，这个限制仍然可能太宽松。在此范围内的价格变动仍可能触发大规模清算甚至 ADL 事件。

2025 年 12 月 14 日，trade.xyz 上的 XYZ100-USDC 市场（追踪纳斯达克 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 事件激增**。

0x4 构建者风险控制

仅配置纪律无法消除风险。最有效的缓解策略侧重于减少对预言机依赖性失败的敞口。

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

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

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

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

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

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

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

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

0x4.2 价格验证

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

1. 数据透明度

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

2. 价格证明

对于每个 setOracle 调用，生成相应的证明，其中包含：

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

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

3. 链上承诺

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

4. 验证

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

0x4.3 风险监控

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

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

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

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

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

0x4.3.1 价格端监控

1. 预言机馈送失败

指标：

• 使用链上可观察指标来判断馈送是否停止：

阈值：

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

操作：

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

2. 价格脱钩

指标：

• 信号 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。

0x4.3.2 订单簿端监控

1. 流动性撤出

指标：

• depth_band(±x%)：订单簿在中间价 ±x% 范围内的流动性。
• spread = bestAsk - bestBid：衡量价差扩大的价差。
• aggressiveVolume_Δt：Δt 内的 taker 量（按交易方聚合）。
• impact_ratio：市场脆弱性的指标（值越高表示对价格影响的脆弱性越大）。

风险模式：

• depth_band 减小，同时 spread 和 impact_ratio 增大。

操作：

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

2. 欺骗性流动性

风险模式：

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

操作：

• Level 1：调用 setOpenInterestCaps 将 OI cap = current OI。
• Level 2：如果结合严重脱钩，考虑停止市场交易。

0x4.3.3 头寸端监控

头寸端监控不试图预测价格方向。相反，它识别从平衡交易活动到单边头寸积累的过渡。当未平仓合约迅速积累、头寸高度集中以及多数方盈亏达到极端时，即使是轻微的外部冲击也可能引发清算级联或 ADL 事件。

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

1. 过度的短期未平仓合约

指标：

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

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

操作：

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

2. 多数方盈亏

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

指标：

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

多数方盈亏及其比率定义如下：

操作：

• Level 1：阈值超出时发出警报。
• Level 2：如果持续存在，考虑调用 setOpenInterestCaps 来降低未平仓合约上限。

0x5 结论

HIP-3 的核心叙述很简单。它将市场上市从由少数人控制的酌情流程转变为一个协议级别的能力，任何合格的构建者在满足要求后都可以调用。通过质押，构建者可以在 HyperCore 上部署自己的永续 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 万美元，并保护了数十亿美元的加密货币。

• 官方网站：https://blocksec.com/

• 官方 Twitter 账号：https://twitter.com/BlockSecTeam

• 🔗 BlockSec 审计服务 : 提交请求

• 🔗 Phalcon 安全 APP: 预约演示

• 🔗 Phalcon 合规