Every Hyperliquid Trade Pays a Frontend: Builder Codes Explained
By @CoinMarketMan - 22-Jul-2026
每一笔 Hyperliquid 交易都在为前端付费:Builder Codes 详解
当你通过第三方钱包或交易终端在 Hyperliquid 上交易时,你使用的应用会从中抽取一份佣金。每一笔成交,自动完成,链上结算,以 USDC 计价。这就是 builder code 的运作原理。
其机制出人意料地简单:任何通过 Hyperliquid 路由订单的应用,都可以为每笔交易附加一笔小额费用,协议会将该费用直接划转至 builder 的地址。无需代币发行,无需订阅模式,无需合作谈判。费用随成交自动流向促成交易的应用。从总量来看,Hyperliquid 的 builder 生态已在 1,411 名注册 builder 中累计产生超过 $9000 万 的收入,使其成为 DeFi 领域最低调却最高效的变现体系之一。
本文将详细拆解 builder codes 的运作方式、谁在从中获益,以及如何将其集成到你自己的应用中。
机制解析:Builder Codes 究竟如何运作
Builder codes 是内置于 Hyperliquid 撮合引擎的链上费用归因机制。这里的"builder"指的是在 Hyperliquid 上构建应用的 DeFi 开发者,"code"则是他们在每笔路由订单上附加的费用参数。
整个流程分三步:
- 用户授权。 在 builder 可以从某位交易者处收取费用之前,该交易者必须从其主钱包签署一个
ApproveBuilderFee操作(代理钱包和 API 钱包无法执行此操作)。 授权操作会设定 builder 可收取的最高费率。用户可随时撤销此授权,且每个钱包最多可同时持有 10 个有效的 builder code 授权。 - 费用附加。 Builder 在每笔订单上附加一个可选参数:
{"b": builder_address, "f": fee_in_tenths_of_bps}。费率按订单设置,灵活度极高,builder 可以根据需要对不同交易收取不同费率。 - 链上结算。 交易成交后,Hyperliquid 的费用逻辑会从成交金额中扣除 builder 费用,并以 USDC 划转至 builder 账户。该费用是在协议标准 maker/taker 费用之外额外收取的。
费率上限与 f 参数
费用参数 f 以十分之一基点为单位。f: 10 对应 1 个基点(0.01%),f: 100 对应 10 个基点(0.10%),这也是永续合约的最高限额。 现货市场则允许最高 100 个基点(1%)。
以一笔 $10,000 的永续合约成交为例,按最高 10 个基点计算,builder 可获得 $10;按更常见的 5 个基点计算,同一笔成交则产生 $5。Builder codes 仅适用于以报价资产或抵押资产(USDC)收取的费用,因此不适用于现货市场的买入方向。
谁赚得最多:Builder 排行榜
以下数据截至 2026 年 7 月,来源为 HyperTracker 的 builder 排行榜。
排行榜头部呈现出清晰的规律:收入最高的 builder,都是深度嵌入用户日常工作流的钱包或交易终端。Phantom 以全时 builder 费用收入 $2360 万 高居榜首,服务用户 153,128 人,路由交易量达 $448 亿。Crypto Briefing 报道称,Phantom 自 2025 年 7 月接入 Hyperliquid 集成以来,已通过 builder code 赚取 $2000 万费用,处理了 $370 亿的交易量。 我们的数据显示,该数字此后已突破 $2300 万。
Based 以 $1520 万 的收入位居第二,路由交易量 $449 亿,交易量实际上超过了 Phantom,但收入较低,原因在于其服务的是更少但交易量更大的用户群(42,967 名用户,对比 Phantom 的 153,128 名)。MetaMask 和 PVP 各自接近 $800 万 的门槛,其中 MetaMask 入场较晚(2025 年 8 月),但已吸引了 52,534 名用户。
排名靠后的 Insilico 仅凭 3,339 名用户 便赚取了 $370 万 的收入,是一个典型的异常值,反映出一小批极度活跃的算法交易者正在通过其基础设施路由天量交易($363 亿)。其人均收入水平远超前 15 名中的所有其他 builder。
人均收入:被忽视的关键指标
总收入只是故事的一部分。对于评估这一机会的 builder 而言,更有参考价值的指标是人均收入,因为它揭示了一个 builder 的商业模型究竟依赖用户数量还是用户强度。
| Builder | 收入 | 用户数 | 人均收入 | 人均交易量 | | --- | --- | --- | --- | --- | | Insilico | $3.7M | 3,339 | $1,113 | $10.9M | | Mass | $1.5M | 1,054 | $1,395 | $2.4M | | TreadFi | $2.2M | 4,835 | $463 | $2.3M | | PVP | $8.0M | 28,223 | $284 | $607K | | Phantom | $23.6M | 153,128 | $154 | $293K |
Insilico 每用户收入超过 $1,100,Phantom 则为 $154。两者都很成功,但代表着截然不同的策略。Phantom 胜在覆盖广度,让每一位 Solana 钱包用户都能一键进入 Hyperliquid 永续合约。Insilico 胜在用户强度,服务一小批能产生巨量交易的高频交易者。Builder code 体系对两种路径都一视同仁地奖励。
Builder Codes 与 Referral Codes 的区别
Hyperliquid 有两套独立的费用分享机制,混淆两者是新手 builder 最常犯的错误之一。
Builder codes 以订单为单位,与应用绑定,属于叠加型费用。它们在协议标准交易费用之上额外附加费用,仅在用户通过 builder 应用交易时生效,且需要用户通过签名操作明确授权。
Referral codes 以用户为单位,永久生效,属于减免型机制。它们降低协议的手续费并将一部分分给推荐人,适用于被推荐用户的所有交易,不受其使用何种前端的影响,在被推荐用户累计交易量达到 $10 亿后失效。
当同一笔订单同时存在两者时,builder code 会覆盖该成交的 referral code。这意味着 builder 的收入不会因用户的 referral code 而被稀释。
接入 Builder Code:技术步骤
入门需要一个永续合约账户(至少持有 100 USDC)以及一个通过 Hyperliquid API 提交订单的应用。无需填写申请表,也没有审批委员会。
第一步:注册你的 Builder 地址
Builder 地址就是用于接收费用的钱包。确保其在永续合约账户中持有至少 100 USDC,并使用标准账户抽象模式。
第二步:引导用户授权你的费率
在你开始获取收入之前,每位用户都需要签署一个 ApproveBuilderFee 操作,且必须来自用户的主钱包。该操作设定了你被允许向该用户收取的最高费率。最佳实践:在你的 UI 中清晰展示授权界面,注明 builder 地址、最高费率、费用示例、额外于协议费用的说明,以及撤销授权的方式。
第三步:在订单中附加费用参数
在每笔提交的订单中添加 builder 参数:
{
"b": "0xYourBuilderAddress",
"f": 50
}
此示例中,f: 50 表示每次成交收取 5 个基点(0.05%)的费用。你可以按订单调整费率,例如对高交易量资产降低费率以保持竞争力,或对流动性较差但你的分析或路由有明显价值的交易对收取更高费率。
第四步:提取收入
Builder 费用累积在你的 builder 地址中,可通过 referral 奖励系统提取。所有 builder code 活动均在链上记录,并以 LZ4 压缩格式每日发布,保持完全透明。
Builder 们究竟在构建什么
Builder code 体系催生了一个多元化的生态。Phantom 和 MetaMask 等钱包将 Hyperliquid 永续合约作为原生功能集成,让用户无需访问 app.hyperliquid.xyz 即可交易。PVP 和 Insilico 等交易终端则为跟单交易、社交交易和算法执行打造了专业界面。Axiom(收入 $240 万,用户 34,093 人)和 Infinex(收入 $280 万,用户 9,283 人)等聚合器则通过 Hyperliquid 的流动性路由跨链交易。
这些 builder 的共同点在于:没有一家通过发行代币来变现。他们搭建产品,接入 builder code,从第一天起就开始赚取收入。这与传统 DeFi 的玩法形成了鲜明对比,后者通常是先引导协议冷启动,再发行治理代币,然后寄希望于代币升值。
用我们的数据追踪 Builder 表现
要在宏观层面理解 builder code 的经济模型,仅靠原始链上日志远远不够。我们的 builder 分析接口 提供完整排行榜:涵盖 Hyperliquid 上每位注册 builder 的收入、交易量、用户数和加入日期。
Builder 可以用这些数据与生态系统中的同行进行横向对比。机构和基金可以用它评估哪些前端正在获得或失去市场份额。这些原始数据也能揭示表面指标容易忽视的规律,比如 Insilico 的 3,339 名用户产生的交易量超过 MetaMask 的 52,534 名用户,或者 Based 以三分之一的用户数路由了与 Phantom 几乎相同的交易量。
我们的 cohort 分析在此基础上再增一层维度。通过将 builder code 数据与我们的 16 个行为 cohort(8 个按账户规模划分,8 个按历史 PnL 划分)交叉比对,你可以看到哪类交易者集中在哪些前端。一个主要吸引 Smart Money cohort 用户的 builder,其商业模型将与主要服务 Exit Liquidity 交易者的 builder 截然不同,即便双方交易量相当。
在 HyperTracker 上探索 Builder 分析
追踪 Hyperliquid 全生态 builder 的收入、交易量和用户增长。免费套餐即可使用。
更大的图景
Builder codes 解决了长期困扰 DeFi 前端的一个核心问题:一个将交易路由至去中心化协议的应用,究竟如何实现盈利?在 builder codes 出现之前,答案通常是"发行代币"或"收取订阅费"。两者都会带来摩擦。代币需要治理成本和承担监管风险;订阅费则会在用户尝试产品之前就将休闲用户挡在门外。
Hyperliquid 的方式则更直接地对齐了各方利益。Builder 的收益与其创造的价值成正比,衡量标准就是路由的交易量。用户明确同意该费用,清楚知道自己支付了多少,并可随时撤销。协议也从中受益,因为每个 builder 实际上都是一个分发渠道,将那些可能永远不会访问原生前端的新交易者带入 Hyperliquid 生态。
截至目前,builder 累计收入 $9070 万,注册 builder 达 1,411 家,这一体系已在相当规模上验证了其模型的可行性。下一个前沿问题不再是 builder codes 是否有效,而是在此之上还能构建出什么。