HyperEVM为何难起势:Hyperliquid架构下的应用层困境

夜磊姑娘_4827

夜磊姑娘_4827

2026-08-12

776人浏览

原创

最近,围绕 hyperevm“是不是已经失去增长动力”、甚至“是否已死”的讨论明显多了起来。加密领域 kol katexbt 直言,hyperevm 更像一次效果有限的尝试,在其提到的 18 个项目里,有 13 个被认为缺乏实际意义。

此前,市场更多关注的是 trade.xyz 在 Hyperliquid 的 HIP-3 永续市场里接近垄断的表现。但如果把观察重点从交易端转向生态端,一个更值得讨论的问题其实是:为什么 Hyperliquid 的应用层一直没有真正跑出来。

HyperEVM是否已死

Hyperliquid 交易端很强,为什么 HyperEVM 应用层却偏弱?

先简单理解一下,Hyperliquid 是一条独立公链,它最突出的标签一直都是“链上交易能力强”。

在 2026 年加密市场整体回调的背景下,据 DeFiLlama 数据,DeFi 全行业 TVL 从约 1150 亿美元下降到 700 亿美元附近,跌幅约 39%。在多数公链锁仓规模同步收缩的情况下,Hyperliquid 仍然算是少数保持一定韧性的公链之一。

Hyperliquid 交易端持续吸金,应用层失血

不过,Hyperliquid 的链上结构并不是单层的。它实际上由两个共享验证者的引擎组成,而且分工很明确。

其中一个叫 HyperCore,主要负责交易执行。高性能订单簿交易所就是由这一层承载,永续合约和现货交易都在这里完成。需要注意的是,HyperCore 并不对外开放,外部开发者不能直接在上面部署应用,核心交易逻辑基本都封装在系统内部。

另一个是 HyperEVM。它在 2025 年 2 月上线,兼容以太坊虚拟机。对开发者来说,HyperEVM 才是能部署借贷、质押、去中心化交易所等 DeFi 应用的地方。虽然 HyperEVM 可以调用 HyperCore 的交易能力和流动性,但真正的撮合权始终还是掌握在 HyperCore 手里。

Hyperliquid 交易端持续吸金,应用层失血

图片来源:RootData

换句话说,Hyperliquid 把最核心、最能产生收益的交易业务放在一个相对封闭的系统里运转,而对开发者开放的空间,主要集中在 HyperEVM 这一层。

从结果看,这两个引擎之间的差距相当明显。

在交易端,Hyperliquid 在 2026 年大多数交易日里,占据了链上永续市场一半以上的成交量。根据 DeFiLlama 数据,截至 8 月 10 日的近 30 天内,Hyperliquid 交易所本身产生的手续费约为 4617 万美元,如果再加上排名靠后的 trade.xyz,交易相关费用合计约为 5600 万美元。

相比之下,应用端的表现就弱得多。整个 HyperEVM 上所有 DeFi 协议产生的费用总和还不到 600 万美元,和交易端相比接近差了十倍。

这种分化在资金层面也很明显。据 HRC 2026 年第二季度报告,Hyperliquid 全链锁仓规模在二季度末约为 14.4 亿美元,到 8 月初已进一步回落至约 12 亿美元,其中也包含交易端资金。而真正沉淀在 HyperEVM 应用层的资金占比并不高,并且还在继续收缩。

Hyperliquid 交易端持续吸金,应用层失血

公开数据显示,HyperEVM 的日均活跃发送地址约为 8000 个,而同期 Base 超过 25 万,Arbitrum 超过 11 万。对于一个已经在链上永续交易赛道建立主导地位、同时并不缺资金和用户的平台来说,应用层却仍停留在二线公链体量,这种反差显然很难只用“行业仍在早期”来解释。

如果继续拆开看 HyperEVM 的内部结构,问题会更直观。截至 8 月初,在剔除跨链桥转入资产后,应用层资金主要集中在两类场景:流动性质押约 9.78 亿美元,借贷约 6.71 亿美元。

其中,规模排名第一的是 HYPE 流动性质押协议 Kinetiq,体量约为 7.8 亿美元。

Hyperliquid 交易端持续吸金,应用层失血

而理论上最容易繁荣的去中心化交易所板块,实际表现却比较有限。在多数公链里,DEX 往往是 DeFi 生态的重要组成部分,头部项目规模通常可达数十亿甚至上百亿美元。但在 HyperEVM 上,44 个相关协议合计规模仅约 2.21 亿美元,最大的原生交易平台也只是数千万美元量级。

Hyperliquid 交易端持续吸金,应用层失血

据 HRC 数据,2026 年第二季度 HyperEVM 的去中心化交易成交量中,PRJX 一家占比达到 92.3%,HyperSwap 占 7.5%,其余四十多个协议几乎没有形成有效交易规模。

这意味着,Hyperliquid 的交易引擎不只是持续吸走资金,也持续吸走了用户注意力,导致应用层既难以留住项目,也难以沉淀活跃用户。

Hyperliquid 交易端持续吸金,应用层失血

HyperEVM 为什么起不来?从架构、流动性和开发门槛来看

这种“交易端强、应用层弱”的格局,并不只是运营层面的结果。更深层的原因,其实就写在 Hyperliquid 的系统架构和产品设计里。

1. HyperCore 掌握撮合权,HyperEVM 上的 DEX 生存空间被压缩

HyperEVM 的一个核心卖点,是应用可以直接调用 HyperCore 的订单簿能力。表面看,这像是在给应用层加能力;但从生态演化角度看,这种设计也限制了真正能长期存在的应用类型。

原因并不复杂。交易撮合和流动性由 HyperCore 统一掌控,而这一层又不向外部开放。也就是说,第三方开发者只能在 HyperEVM 上做外围应用,再通过接口去调用 HyperCore 的流动性。

在这种框架下,更有存在价值的应用,往往会自然集中到少数和订单簿高度相关的场景,比如流动性质押、借贷、基差交易和做市等。

据 Token Terminal 数据,Hyperliquid 全链日活跃地址长期维持在 6 万到 7 万区间,而 HyperEVM 通常只占其中一到两成,绝大多数活跃用户仍集中在 HyperCore 交易端。

Audo Studio
Audo Studio

Audo Studio是一款用于自动降噪、增强语音和清理录音的 AI 音频处理工具。

下载

HyperEVM 为什么起不来

在这样的体系里,DEX 的独立存在价值会被明显削弱。因为撮合本身已经被 HyperCore 以远高于自动做市商的方式完成,再在 HyperEVM 上重复搭建一套去中心化交易所,本质上是在重复建设已有能力。

2. HyperEVM 的高度集中,不只是竞争结果,更像架构结果

据 HRC 报告,共享流动性的存在,基本消除了小平台依靠独立订单簿生存的空间。当交易者在同一界面看到同一资产出现在多个入口时,订单通常会自然流向流动性更深的池子,重复上架的结果往往是被更优流动性迅速吸走。

这也解释了为什么 HyperEVM 的去中心化交易量会高度集中到 PRJX 一家,同时也能解释交易层出现的类似现象。HIP-3 的上架层在五个月内迅速向单一运营商收敛,到 7 月,tradeXYZ 已经拿下接近全部成交量。

所以,在共享流动性的环境中,“无许可进入”和“最终高度集中”是可以同时成立的。应用层集中度高,不只是因为竞争不充分,更像是这套架构自然推导出来的结果。

3. Hyperliquid 强调“公平”,但生态分发能力也被削弱了

HyperEVM 的另一个短板,来自 Hyperliquid 长期强调的公平原则。

官方曾承认,HyperEVM 长期推进缓慢,其中一个原因在于坚持“无内部人”原则:不会提前通知特定参与者,也不会为集成或营销付费。

这个原则本身并没有问题,但它带来的现实代价也很直接——HyperEVM 上线时的开发工具、基础设施配套和生态协同程度,并不像其他公链那样成熟。

更关键的是,一个已经能够日收数百万美元手续费、同时掌握大量用户和资金的平台,其实完全有能力在不破坏公平前提下,通过资助、商务支持和市场推广去扶持应用层建设。但从结果看,团队并没有在这方面投入足够多的资源。

当 Hyperliquid 发展到现在这个体量后,“无内部人”不再只是原则表达,在某种程度上也成了缺乏生态推动动作的理由。问题未必在于没有资源,而更像是缺少相应意愿。

KOL @Ace_da_Book 就指出,这条链对建设者缺乏激励机制,也没有刻意打造“明星项目”,但仍吸引了一批相信公平竞争的高水平团队。在他看来,HyperEVM 更适合那些能够与 HyperCore 订单簿协同、能够处理代币化 RWA 和优质资产的团队,而不太适合依赖注意力叙事的项目。

从另一个角度说,这其实也是一种高强度筛选。没有补贴,也缺少叙事保护,项目一上线就要直接面对成熟交易者,失败通常也会来得更快。

4. 跨引擎写入不是同步成交,开发体验本身就有门槛

HyperEVM 面临的最后一层阻力,来自开发体验本身。

HyperEVM 采用双区块设计:高频小区块负责低延迟合约交互,约一秒生成的大区块负责与 HyperCore 结算。它的优势是执行速度快,但代价是合约操作与核心撮合处在不同阶段,无法在同一笔交易里同步完成。

HyperEVM 与 HyperCore 之间设置了两条通道。读通道通过预编译实现,合约可以直接读取订单簿价格、持仓和余额,整体使用相对顺畅。写通道则通过名为 CoreWriter 的系统合约实现,并且在 2025 年年中已启用至主网,允许合约向 HyperCore 发起下单和资产划转。

问题在于,写通道并不是同步执行的。合约调用 CoreWriter 后,EVM 侧交易会立即完成,而真正的核心操作要等到后续核心区块中才会被处理;如果过程中因保证金不足、订单未能成交等原因失败,EVM 端原本的交易并不会自动回滚。

这意味着,开发者不能像在以太坊上那样默认“一步完成”。如果想让金库、借贷等复杂应用稳定运行,往往需要把流程拆成两步:先发送指令,再通过读通道确认 HyperCore 侧是否真的执行成功,同时还要为中间状态异常预留处理方案。这类跨引擎的不确定性,在普通 EVM 开发里并不常见。

因此,对于想迁移到 HyperEVM 的通用开发者来说,这是一道并不低的门槛。真正愿意进入的团队,更多还是围绕 HyperCore 的流动性来设计产品,而不是建立完全独立的应用场景。

HyperEVM 是衰退了,还是它本来就不是通用公链路线?

HRC 报告提出,这一轮 TVL 下滑更像是一种结构性调整。报告称,同期链上稳定币规模增长了数倍,gas 消耗和交易笔数也在上升,说明实际使用仍在增加,只是此前停留在杠杆和 LST 循环中的 DeFi 抵押品正在被挤出。换句话说,Hyperliquid 上的资金越来越偏向交易,而不是 farming。

这个解释并非完全没有道理,但它本身也暴露了问题:如果一个生态最终主要剩下交易与杠杆循环,那么所谓“结构优化”未必能证明应用层成功,反而可能说明它的生态广度仍然不足。

加密 KOL Cain O'Sullivan 则给出了另一种视角。他认为,外界对 HyperEVM 的判断使用了错误框架。在他看来,HyperEVM 从一开始就不是为了成为通用型公链,而是 HyperCore 流动性的代币化层,是价值进入和流出整个生态的可编程接口。没有这层 EVM 兼容,HyperCore 上就不会有原生 USDC,而团队从 Core vaults 转向 EVM 版本,也被视为这一判断的佐证。

不过,即便按这个思路理解,HyperEVM 的价值依然是附属于 HyperCore 的。它更像交易引擎的可编程外围系统,而不是一个能够独立生长的完整经济体。

如果把 HyperEVM 定位为代币化层,这个逻辑当然说得通,但也意味着团队从一开始可能就没有真正打算把它做成通用生态。那些基于“通用链”叙事进入的开发者,某种程度上反而是落差最大的群体。

从这个角度看,HyperEVM 生态里此前看似繁荣的一部分,本身就带有较强的杠杆驱动特征。当这部分热度退去,最终留下来的,主要还是围绕交易和订单簿展开的真实需求。

结语:HyperEVM 没有彻底停摆,但也没长成典型应用生态

HyperEVM 到底“死没死”,也许并不是最准确的问题。它链上依然存在真实资金流动,也仍然承载着部分高价值资产活动。但如果从应用生态的广度、独立性以及用户留存来看,它确实没有成长为一个典型通用应用层应有的样子。

Hyperliquid 几乎把最核心的资源和市场注意力都押注在交易引擎上,把撮合和流动性锁定在封闭的高性能系统里。这样的产品选择帮助它在链上永续市场建立了明显优势,也同时决定了 HyperEVM 更像附属层,而不是能够独立成长的主生态。这不只是架构限制,更是一种明确的产品取舍。

一年多时间过去,这种取舍带来的结果已经比较清楚:交易端持续吸纳资金,应用层难以留住项目,也难以沉淀用户。最终存活下来的,多数仍是围绕订单簿展开的金融应用,而真正独立、通用的需求并没有大规模形成。

与其继续争论 HyperEVM 是否已经“死亡”,不如先回答一个更基础的问题:市场究竟期待 Hyperliquid 成为一条怎样的链?

以上内容围绕 HyperEVM 为什么难以起势,以及 Hyperliquid 是否在结构上压制了 HyperEVM 的发展进行了梳理。加密资产与链上生态具有较高波动性和不确定性,相关项目后续表现仍需结合公开数据与实际使用情况持续观察,不宜将单一阶段表现简单等同于长期结论。

相关文章

PHP速学视频免费教程(入门到精通)
PHP速学视频免费教程(入门到精通)

PHP怎么学习?PHP怎么入门?PHP在哪学?PHP怎么学才快?不用担心,这里为大家提供了PHP速学教程(入门到精通),有需要的小伙伴保存下载就能学习啦!

下载

相关标签:

本站声明:本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn

相关专题

更多
LLVM自定义Pass怎么写
LLVM自定义Pass怎么写

本专题聚焦LLVM自定义Pass开发,整理Pass类结构、run()方法、PreservedAnalyses、CMake构建、插件注册、-load-pass-plugin加载和测试用例编写流程。

2026.09.30

120

10

LLVM RISC-V参数配置教程
LLVM RISC-V参数配置教程

本专题介绍LLVM对RISC-V基础ISA和扩展的支持方式,涵盖RV32、RV64、标准扩展、实验性扩展、厂商扩展、-menable-experimental-extensions和版本差异。

2026.09.30

100

14

LLVM IR中间表示入门指南
LLVM IR中间表示入门指南

本专题整理LLVM IR的核心概念,包括中间表示作用、模块结构、函数、基本块、SSA形式、类型系统和常见语法,帮助新手理解LLVM编译流程中的关键层。

2026.09.30

80

12

PDF转图片方法
PDF转图片方法

需要把 PDF 页面用于上传、预览、分享或图片归档时,PDF 转图片方法专题整理 JPG/PNG 格式选择、逐页导出、清晰度设置、批量下载和结果检查等流程,帮助用户稳定完成 PDF 图片化处理。

2026.09.30

60

26

PixTV AI视频生成与无限画布创作
PixTV AI视频生成与无限画布创作

PixTV专题整理AI视频与视觉内容创作相关功能使用教程,涵盖AI生图、视频生成、无限画布、多模型创作、素材管理、声音音乐及视频剪辑等功能,帮助用户快速掌握PixTV从创意到成片的完整制作方法。

2026.09.29

80

15

Buffalo框架数据库开发全教程
Buffalo框架数据库开发全教程

本专题围绕Buffalo框架数据库开发,讲解database.yml多环境配置、soda与fizz迁移生成回滚、模型结构体标签、增删改查与条件查询、一对多与多对多关联、数据校验、回调钩子、事务处理及原生SQL执行能力。

2026.09.23

280

15

Buffalo框架路由与请求处理实操指南
Buffalo框架路由与请求处理实操指南

本专题讲解Buffalo框架路由与请求处理机制,涵盖路由注册与分组、资源路由、Handler编写规范、Context上下文方法、参数绑定、中间件编写挂载、Session与Cookie读写、Flash消息及错误页面定制方法。

2026.09.23

180

15

Buffalo框架零基础入门教程
Buffalo框架零基础入门教程

本专题整理Buffalo框架入门内容,涵盖Go环境准备、buffalo CLI安装、新项目生成、目录结构说明、dev热加载启动、数据库连接配置与常见报错排查,帮助新手按约定优于配置的思路跑通第一个Buffalo框架应用。

2026.09.23

140

15

Conan创建软件包配方指南
Conan创建软件包配方指南

本专题介绍通过conanfile.py创建软件包的方法,讲解包名、版本、依赖和构建设置等基础信息,以及source、build、package、package_info等常用方法的作用及编写思路。

2026.09.22

80

12

热门下载

更多
网站特效
/
网站源码
/
网站素材
/
前端模板

精品课程

更多
相关推荐
/
热门推荐
/
最新课程