4.在缺乏动态风控机制的情况下，高风险资产与主流资产是否应严格区分对待？未实现利润的超大额提取是否应该触发风控？
5.Hyperliquid最终会成为Bitget CEO口中的“FTX2.0”吗？
三、Hyperliquid的内患
带着上文所述的第5个问题，我们再往下展开。从流动性的角度来看，Hyperliquid虽是Dex中的佼佼者，但其巨鲸存款在常态下可能占据平台TVL的近20%。这也就意味着更大规模的相似事件若再次发生，可能会触发大量巨鲸出逃，而Hyperliquid会瞬间陷入流动性枯竭的死循环。此时能做的只有再次拔网线，所以流动性的厚度与组成成分对于Perp Dex至关重要，Hyperliquid在今天虽然能与第二梯队的Cex直接掰手腕，但显然在缺乏动态杠杆限制的情况下，其链上流动性还不足以支撑这种固定超高杠杆。
从架构而言，Hyperliquid是一个自带Layer1的Dex，整条链的构成颇具新意但也并不复杂，简单来说即EVM+撮合引擎。依照官方技术文档中的描述则是HyperEVM+HyperCore，Hyperliquid L1也不是一条单独的链，而是由与HyperCore相同的HyperBFT共识保护的。这使得EVM可以直接与HyperCore交互，例如现货和永续合约Perp。
我们在这里可能还要详细解释一下HyperCore：
如上文所诉，HyperCore相当于中心化交易所的撮合引擎，它与HyperEVM共享同一共识层（HyperBFT），因此两者并非独立的链，而是同一区块链网络中的不同执行环境。源自阿里系的公链Artela其实也具有类似的思路。HyperCore的定位是专注于运行交易所的核心业务逻辑（如订单簿匹配、衍生品清算、资产托管），其底层基于RustVM（专为高频交易优化的虚拟机），并采用许可制设计，仅支持官方认可的功能（如USDC资产和通过HIP-1协议生成的代币）。通过预编译合约实现与HyperEVM的协同，举一个常见操作，例如：用户通过HyperEVM上的合约发起永续合约平仓操作→操作通过预编译合约写入HyperCore的订单簿→由HyperCore执行清算和结算。
这种同一共识层下的双链设计，其实也存在潜在风险：1.交易状态不一致。2.同步延迟。3.跨链清算延迟等各种交互风险。4.并非无许可制。对于一条Layer1而言，去中心化需要时间沉淀，我们不能强求。但其架构似乎也存在着大量潜在风险。
HLP（HyperliquidPool）金库是Hyperliquid生态中的核心，其设计逻辑是通过聚合社区用户的USDC等资产，构建去中心化做市商资金池，这点与AMM中的LP有点相似，但却更为高效。该金库的底层采用"链上订单簿+策略池"双轨制：
- 订单簿模式：由HLP主动挂单提供深度，支持限价单、止损单等专业交易功能；